Overview

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
main
3ba9c8b4 feat(ai-mcp): forward MCP tool annotations and titles (#1031) * feat(ai-mcp): forward MCP tool annotations and titles Discovery previously stamped only serverToolName/serverId/uiResourceUri onto `metadata.mcp`, dropping the server's `annotations` hints and `title` from tools/list — so a host could only ever see a tool's name and description. Forward both, on the auto-discovery AND explicit `tools([...defs])` paths, via a shared `toolMcpMetadata()` so the two cannot drift: - `annotations` — the server's object verbatim (readOnlyHint, destructiveHint, idempotentHint, openWorldHint, annotations.title), omitted when absent so the explicit path's merge can't blank out caller-supplied metadata. - `title` — display name resolved with the spec's precedence: `title` -> `annotations.title` -> `name`. Titles are display-only: the model-facing tool name and prefixing are unchanged, and nothing new is sent to providers. Also exports `McpToolMetadata` (the full `metadata.mcp` shape — `metadata` is `Record<string, any>`, so this is what makes reads typed without a cast) and re-exports the SDK's `ToolAnnotations`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(ai-mcp): don't let a tool annotation waive approval The approval-gating sample keyed `needsApproval` off `readOnlyHint` alone, so a single server-supplied boolean could waive the confirmation step — a compromised server can claim `readOnlyHint: true` on a destructive tool. It also contradicted the warning directly beneath it. Gate on `!(serverIsTrusted && advertisedReadOnly)`, where trust comes from a caller-configured allowlist rather than anything on the wire, and rewrite the warning to say annotations are advisory and must never be the security boundary for an untrusted server — hints may relax a confirmation only on independently trusted servers, and are display labels everywhere else. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(ai-mcp): type metadata.mcp on the tools() return type `ServerTool.metadata` is `Record<string, any> | undefined`, so `tool.metadata.mcp` did not compile and its fields were `any` — reading the forwarded MCP title/annotations needed a hand-written annotation that TS could not check. Every `tools()` path (single client, explicit `tools([...defs])`, and the `createMCPClients` pool) now returns `McpServerTool`s: structurally still `ServerTool`s, but with `metadata.mcp` statically present and typed as `McpToolMetadata`. So `tool.metadata.mcp.annotations?.readOnlyHint` infers on its own and a misspelled field is a compile error. - `McpToolMetadata.serverToolName` / `.title` are now required, since both are always stamped — no more fallback for a value that is never missing. - The explicit path rebuilds the bound tool instead of mutating it, because assigning `metadata` cannot narrow the declared type. - Docs, tests, and the e2e route drop their annotations and read straight through; new type-level tests cover all four paths plus the typo case. --------- Co-authored-by: Surya Ashish <258175523+suryaashish-kubesense@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Alem Tuzlak <t.zlak@hotmail.com>
by Surya Ashish
Succeeded
main
3ba9c8b4 feat(ai-mcp): forward MCP tool annotations and titles (#1031) * feat(ai-mcp): forward MCP tool annotations and titles Discovery previously stamped only serverToolName/serverId/uiResourceUri onto `metadata.mcp`, dropping the server's `annotations` hints and `title` from tools/list — so a host could only ever see a tool's name and description. Forward both, on the auto-discovery AND explicit `tools([...defs])` paths, via a shared `toolMcpMetadata()` so the two cannot drift: - `annotations` — the server's object verbatim (readOnlyHint, destructiveHint, idempotentHint, openWorldHint, annotations.title), omitted when absent so the explicit path's merge can't blank out caller-supplied metadata. - `title` — display name resolved with the spec's precedence: `title` -> `annotations.title` -> `name`. Titles are display-only: the model-facing tool name and prefixing are unchanged, and nothing new is sent to providers. Also exports `McpToolMetadata` (the full `metadata.mcp` shape — `metadata` is `Record<string, any>`, so this is what makes reads typed without a cast) and re-exports the SDK's `ToolAnnotations`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(ai-mcp): don't let a tool annotation waive approval The approval-gating sample keyed `needsApproval` off `readOnlyHint` alone, so a single server-supplied boolean could waive the confirmation step — a compromised server can claim `readOnlyHint: true` on a destructive tool. It also contradicted the warning directly beneath it. Gate on `!(serverIsTrusted && advertisedReadOnly)`, where trust comes from a caller-configured allowlist rather than anything on the wire, and rewrite the warning to say annotations are advisory and must never be the security boundary for an untrusted server — hints may relax a confirmation only on independently trusted servers, and are display labels everywhere else. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(ai-mcp): type metadata.mcp on the tools() return type `ServerTool.metadata` is `Record<string, any> | undefined`, so `tool.metadata.mcp` did not compile and its fields were `any` — reading the forwarded MCP title/annotations needed a hand-written annotation that TS could not check. Every `tools()` path (single client, explicit `tools([...defs])`, and the `createMCPClients` pool) now returns `McpServerTool`s: structurally still `ServerTool`s, but with `metadata.mcp` statically present and typed as `McpToolMetadata`. So `tool.metadata.mcp.annotations?.readOnlyHint` infers on its own and a misspelled field is a compile error. - `McpToolMetadata.serverToolName` / `.title` are now required, since both are always stamped — no more fallback for a value that is never missing. - The explicit path rebuilds the bound tool instead of mutating it, because assigning `metadata` cannot narrow the declared type. - Docs, tests, and the e2e route drop their annotations and read straight through; new type-level tests cover all four paths plus the typo case. --------- Co-authored-by: Surya Ashish <258175523+suryaashish-kubesense@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Alem Tuzlak <t.zlak@hotmail.com>
by Surya Ashish
Succeeded
feat/mcp-tool-annotations
ae411b7c Merge fdc175495e230e22e0658d54c830fbb0056f89e9 into 59aa8b5049549246227c8f2cf736ce50d05205a5
by Surya Ashish