Repository navigation
Conversation
listToolDefs dropped the annotations a server reports per tool, so a consumer could not read readOnlyHint or destructiveHint after discovery. Carry them on the tool definition, expose them on the MCP-branded tool, and store and restore them in cache snapshots. Linear: DEV-1374
…hots for annotations Also copies a snapshot's annotations on rehydrate so tools do not share the snapshot's object, and documents the five kept fields with an isMcpTool example. Linear: DEV-1374
Contributor
Author
|
AGENT-WRITTEN: Perry reviewed head
|
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Linear: DEV-1374
Problem
An MCP server reports behaviour hints per tool in
tools/list(annotations:readOnlyHint,destructiveHint,idempotentHint,openWorldHint,title).listToolDefscopies onlyname,description,inputSchema,outputSchemaand the loop key, so the hints are gone after discovery and the handle offers no other way to read them.OpenRouter's MCP loop needs them for two things:
mcp_list_toolsitem lists every tool withannotations: { read_only }. The loop cannot fill that field.require_approvalandallowed_toolsselectors that useread_only, because it cannot tell which tools are read-only.Change
McpToolDefandSerializedMCPToolDefgain an optionalannotations.listToolDefscopies the hints the server defined. A tool with no annotations gets no field.markMcpacceptsannotationsnext toloopKey, andMcpBrandedexposes it astool.annotations.McpToolAnnotationsis exported from the package root.isSerializedMCPServerrejects a snapshot whoseannotationsis not an object, or holds a hint that is not a boolean, or a title that is not a string. A consumer may gate approval on a hint, so a wrong type must not read as truthy.Nothing reaches the model: annotations are not part of the wire tool definition.
Behaviour to review
annotations. Older versions ignore the extra field when they read such a snapshot. Snapshots written by older versions have no annotations, so tools rehydrated from them have none until the nextrefresh().Tests
tests/unit/mcp/annotations.test.ts:createMCPToolsexposes each tool with the hints its server reported, and none for a tool without annotations.serialize(), after a JSON round trip, restores the same hints throughrehydrateMCPToolswithout callingtools/list.isSerializedMCPServerrejects malformed annotations and accepts well-formed ones.I checked that the first two fail when the
listToolDefschange is removed, and the second fails when therehydratechange is removed.Overlap
#146 also adds an option to
markMcp(wireInputSchema) and edits the same lines intool-wrapper.ts. Whichever lands second needs a small merge there.