Bump agents from 0.14.4 to 0.17.4 in /worker

[dependabot]

Bumps agents from 0.14.4 to 0.17.4.

Release notes

Sourced from agents's releases.

[email protected]

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.

[email protected]

Patch Changes

... (truncated)

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.

0.17.3

... (truncated)

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)
• 2e50e66 Version Packages (#1843)
• 27bb642 Version Packages (#1828)
• 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 this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #33.