deps(mcp): bump the npm-minor group in /apps/mcp with 4 updates

[dependabot]

Bumps the npm-minor group in /apps/mcp with 4 updates: agents, @cloudflare/vitest-pool-workers, @cloudflare/workers-types and wrangler.

Updates agents from 0.17.3 to 0.17.4

Release notes

Sourced from agents's releases.

agents@0.17.4

Patch Changes

• #1902 a9d78c0 Thanks @​mattzcarey! - Always apply the Worker-safe CfWorkerJsonSchemaValidator to MCP client connections by default.

  MCPClientConnection now owns the default (merged in its constructor), so every construction path uses the Worker-safe validator unless the caller supplies their own — including the RPC addMcpServer(name, namespace) path via MCPClientManager.connect(), which previously skipped it. Without the default, the MCP SDK fell back to its AJV validator when a server exposed tools with outputSchema; AJV compiles schemas with new Function, which Workers disallows, failing discovery with "Code generation from strings disallowed for this context".

  connect() now builds connections through createConnection() instead of duplicating construction, so the two paths can no longer drift. Caller-supplied client.jsonSchemaValidator overrides are respected on the live connection; because validator instances cannot survive JSON serialization, they are no longer persisted, and a previously persisted, serialization-degraded validator is ignored on restore — after hibernation the connection falls back to the Worker-safe default instead of failing discovery.

• #1903 3ba6a78 Thanks @​mattzcarey! - MCP client: url-mode elicitation support with a real elicitation handler

  • Agents can now respond to server-initiated elicitation/create requests by calling this.mcp.configureElicitationHandlers({ form, url }), typically in onStart(). The advertised modes are persisted with each MCP server, so connections restored after Durable Object hibernation re-advertise them at the handshake and the handlers re-attach when onStart runs.
  • Connections advertise elicitation modes based on what can actually be handled: they advertise exactly the modes with configured handlers at the initialize handshake; without handlers they advertise no elicitation capability. An explicit client.capabilities.elicitation (e.g. via addMcpServer) always wins, is persisted with the server options, and survives hibernation — it is no longer clobbered by a hardcoded value.

• #1925 762998d Thanks @​mattzcarey! - MCP client: consume the persisted capability seed at first use instead of at restore-time read

  The capability stamp persisted on each MCP server row (used to re-advertise elicitation modes at the handshake after Durable Object hibernation) was read-and-cleared when the connection object was created, before any connection attempt. Wakes that never reached a handshake burned it: a restore that parked on a pending OAuth flow, or a wake interrupted between restore and onStart re-stamping the rows, left the next wake's connections negotiating without the elicitation capability until some later reconnect.

  The stamp is now read without clearing and only cleared once a seeded handshake actually completes in a session that has not configured handlers, preserving the one-successful-restore semantics: after the seed is used in a completed handshake it no longer re-advertises stale modes, and any configureElicitationHandlers call still re-stamps every row. Sessions with handlers configured own their row stamps, so a handshake there (e.g. re-adding a server under a stable id) keeps the fresh stamp in place for the next wake.

• #1910 9e1b733 Thanks @​mattzcarey! - MCP client: advertise no elicitation capability when no handler is configured

  Connections without an elicitation handler previously advertised form-mode elicitation while rejecting every elicitation request that arrived, so spec-compliant servers chose elicitation over their fallback flows and the tool call failed mid-flight. Connections now advertise the elicitation capability only when it can be handled: form mode, URL mode, or both, based on handlers configured via this.mcp.configureElicitationHandlers({ form, url }). Connections without handlers advertise no elicitation capability, letting servers fall back gracefully.

  An explicit client.capabilities.elicitation declaration remains authoritative. Only advertise modes your Agent can handle.

• #1869 f274903 Thanks @​mattzcarey! - Fix addMcpServer() reporting ready for an HTTP MCP connection that was restored while OAuth is still in progress.

  For an existing AUTHENTICATING connection, addMcpServer() now prefers the live authorization URL, otherwise returns a persisted absolute HTTP(S) authorization URL. If neither is available, it reconnects the existing connection without re-registering it: a new authorization URL is returned and persisted, a connected result is discovered before returning ready, and failed or incomplete OAuth results throw instead of falling through to ready.

Changelog

Sourced from agents's changelog.

0.17.4

Patch Changes

• #1902 a9d78c0 Thanks @​mattzcarey! - Always apply the Worker-safe CfWorkerJsonSchemaValidator to MCP client connections by default.

  MCPClientConnection now owns the default (merged in its constructor), so every construction path uses the Worker-safe validator unless the caller supplies their own — including the RPC addMcpServer(name, namespace) path via MCPClientManager.connect(), which previously skipped it. Without the default, the MCP SDK fell back to its AJV validator when a server exposed tools with outputSchema; AJV compiles schemas with new Function, which Workers disallows, failing discovery with "Code generation from strings disallowed for this context".

  connect() now builds connections through createConnection() instead of duplicating construction, so the two paths can no longer drift. Caller-supplied client.jsonSchemaValidator overrides are respected on the live connection; because validator instances cannot survive JSON serialization, they are no longer persisted, and a previously persisted, serialization-degraded validator is ignored on restore — after hibernation the connection falls back to the Worker-safe default instead of failing discovery.

• #1903 3ba6a78 Thanks @​mattzcarey! - MCP client: url-mode elicitation support with a real elicitation handler

  • Agents can now respond to server-initiated elicitation/create requests by calling this.mcp.configureElicitationHandlers({ form, url }), typically in onStart(). The advertised modes are persisted with each MCP server, so connections restored after Durable Object hibernation re-advertise them at the handshake and the handlers re-attach when onStart runs.
  • Connections advertise elicitation modes based on what can actually be handled: they advertise exactly the modes with configured handlers at the initialize handshake; without handlers they advertise no elicitation capability. An explicit client.capabilities.elicitation (e.g. via addMcpServer) always wins, is persisted with the server options, and survives hibernation — it is no longer clobbered by a hardcoded value.

• #1925 762998d Thanks @​mattzcarey! - MCP client: consume the persisted capability seed at first use instead of at restore-time read

  The capability stamp persisted on each MCP server row (used to re-advertise elicitation modes at the handshake after Durable Object hibernation) was read-and-cleared when the connection object was created, before any connection attempt. Wakes that never reached a handshake burned it: a restore that parked on a pending OAuth flow, or a wake interrupted between restore and onStart re-stamping the rows, left the next wake's connections negotiating without the elicitation capability until some later reconnect.

  The stamp is now read without clearing and only cleared once a seeded handshake actually completes in a session that has not configured handlers, preserving the one-successful-restore semantics: after the seed is used in a completed handshake it no longer re-advertises stale modes, and any configureElicitationHandlers call still re-stamps every row. Sessions with handlers configured own their row stamps, so a handshake there (e.g. re-adding a server under a stable id) keeps the fresh stamp in place for the next wake.

• #1910 9e1b733 Thanks @​mattzcarey! - MCP client: advertise no elicitation capability when no handler is configured

  Connections without an elicitation handler previously advertised form-mode elicitation while rejecting every elicitation request that arrived, so spec-compliant servers chose elicitation over their fallback flows and the tool call failed mid-flight. Connections now advertise the elicitation capability only when it can be handled: form mode, URL mode, or both, based on handlers configured via this.mcp.configureElicitationHandlers({ form, url }). Connections without handlers advertise no elicitation capability, letting servers fall back gracefully.

  An explicit client.capabilities.elicitation declaration remains authoritative. Only advertise modes your Agent can handle.

• #1869 f274903 Thanks @​mattzcarey! - Fix addMcpServer() reporting ready for an HTTP MCP connection that was restored while OAuth is still in progress.

  For an existing AUTHENTICATING connection, addMcpServer() now prefers the live authorization URL, otherwise returns a persisted absolute HTTP(S) authorization URL. If neither is available, it reconnects the existing connection without re-registering it: a new authorization URL is returned and persisted, a connected result is discovered before returning ready, and failed or incomplete OAuth results throw instead of falling through to ready.

Commits

• 03cdc82 Version Packages (#1899)
• 762998d fix(mcp): defer capability seed clearing (#1925)
• 8fff5d8 rename configureElicitationHandler to configureElicitationHandlers (#1917)
• 0f47d61 fix(mcp): configure client elicitation handler (#1911)
• 9e1b733 fix(mcp): advertise no elicitation capability when no handler is configured (...
• 3ba6a78 feat(mcp): allow declaring url-mode elicitation capability and handling elici...
• a9d78c0 fix: always apply the Worker-safe JSON Schema validator to MCP client connect...
• f274903 fix: prevent addMcpServer from reporting restored OAuth as ready (#1869)
• See full diff in compare view

Updates @cloudflare/vitest-pool-workers from 0.18.4 to 0.18.6

Release notes

Sourced from @​cloudflare/vitest-pool-workers's releases.

@​cloudflare/vitest-pool-workers@​0.18.6

Patch Changes

• #14678 4e62bba Thanks @​apeacock1991! - Fix test runs hanging after a Durable Object logs and rejects blockConcurrencyWhile()

  Console messages emitted from another Durable Object are now buffered until execution returns to the test runner, avoiding I/O that cannot complete after the object's input gate breaks.

• Updated dependencies [34e696d, d39ae01, 3de70df, c79504f, 9f04a7e, 9f04a7e, cb30df3, cb6c3f9, c7dbe1a, 3f3afbb, e6fbc4e, 4e1a7a7, 9f04a7e]:

  • miniflare@4.20260714.0
  • wrangler@4.112.0

@​cloudflare/vitest-pool-workers@​0.18.5

Patch Changes

• Updated dependencies [7692a61, ed33326, 018574b, eb99ab1, cdf3148, 7692a61, 7692a61, 3015320, 899c297, 9da77ac, 317ce1f]:
  • miniflare@4.20260710.0
  • wrangler@4.111.0

Changelog

Sourced from @​cloudflare/vitest-pool-workers's changelog.

0.18.6

Patch Changes

• #14678 4e62bba Thanks @​apeacock1991! - Fix test runs hanging after a Durable Object logs and rejects blockConcurrencyWhile()

  Console messages emitted from another Durable Object are now buffered until execution returns to the test runner, avoiding I/O that cannot complete after the object's input gate breaks.

• Updated dependencies [34e696d, d39ae01, 3de70df, c79504f, 9f04a7e, 9f04a7e, cb30df3, cb6c3f9, c7dbe1a, 3f3afbb, e6fbc4e, 4e1a7a7, 9f04a7e]:

  • miniflare@4.20260714.0
  • wrangler@4.112.0

0.18.5

Patch Changes

• Updated dependencies [7692a61, ed33326, 018574b, eb99ab1, cdf3148, 7692a61, 7692a61, 3015320, 899c297, 9da77ac, 317ce1f]:
  • miniflare@4.20260710.0
  • wrangler@4.111.0

Commits

• 82918ad Version Packages (#14699)
• 4e62bba fix(vitest-pool-workers): avoid hanging on broken DO logs (#14678)
• b449bb0 Version Packages (#14644)
• See full diff in compare view

Updates @cloudflare/workers-types from 5.20260713.1 to 5.20260719.1

Commits

• See full diff in compare view

Updates wrangler from 4.110.0 to 4.112.0

Release notes

Sourced from wrangler's releases.

wrangler@4.112.0

Minor Changes

• #14470 3de70df Thanks @​DiogoSantoss! - Add a top-level addresses field to Wrangler configuration for Email Routing

  You can now declare the inbound email addresses handled by your Worker directly in wrangler.json:

  {
    "name": "my-worker",
    "main": "src/index.ts",
    "compatibility_date": "2026-05-21",
    "addresses": ["support@example.com", "*@example.com"]
  }

• #14706 cb6c3f9 Thanks @​edmundhung! - Add Durable Object storage access to createTestHarness()

  You can now execute SQL against a SQLite-backed Durable Object to seed or assert the storage state.

  const server = createTestHarness({
    workers: [{ configPath: "./wrangler.json" }],
  });
  await server.listen();
  const worker = server.getWorker();
  const storage = await worker.getDurableObjectStorage("COUNTER", {
  name: "user-123",
  });
  await worker.fetch("/counter/user-123");
  const rows = await storage.exec(
  "SELECT value FROM counters WHERE id = ?",
  "user-123"
  );
  expect(rows).toEqual([{ value: 1 }]);

• #14562 9f04a7e Thanks @​martijnwalraven! - Emit a typed runtimeError event on the unstable_startWorker DevEnv for uncaught Worker exceptions

  Uncaught Worker exceptions were only source-mapped and printed, so programmatic consumers had to scrape terminal output to observe them. The DevEnv now re-emits a RuntimeErrorEvent (like reloadComplete) carrying the exception text and source-mapped stack — fed from Miniflare's pretty-error seam via the new handleUncaughtError option for exceptions the runtime catches, and from the inspector for those it does not.

Patch Changes

• #14682 d39ae01 Thanks @​dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

... (truncated)

Commits

• 82918ad Version Packages (#14699)
• 24731b5 [wrangler] Wait for workerd cleanup in port conflict E2E (#14730)
• 028ce1f [wrangler] Wait for workers.dev propagation in E2Es (#14728)
• c79504f fix(wrangler): support containers in test harness (#14725)
• 4c1309e [wrangler] Use default readiness timeout in local dev E2Es (#14729)
• b38f494 chore: consolidate most packages on zod 4.4.3 in pnpm catalog (#14707)
• cb6c3f9 feat(wrangler): access do storage with test harness (#14706)
• c7dbe1a fix(wrangler): type the public startWorker input as WranglerStartDevWorkerInp...
• 9f04a7e feat: surface uncaught Worker exceptions as a typed runtimeError event in loc...
• 3de70df [wrangler] Add top-level addresses config field for Email Routing (#14470)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[dependabot]

Labels

The following labels could not be found: mcp. Please create it before Dependabot can add it to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	mkit-mcp	28882da	Jul 20 2026, 07:16 AM