Skip to content

Fix retrieve_tools annotations/call_with defaulting to call_tool_read#307

Merged
Dumbris merged 1 commit intomainfrom
fix/retrieve-tools-annotations-306
Feb 18, 2026
Merged

Fix retrieve_tools annotations/call_with defaulting to call_tool_read#307
Dumbris merged 1 commit intomainfrom
fix/retrieve-tools-annotations-306

Conversation

@Dumbris
Copy link
Contributor

@Dumbris Dumbris commented Feb 18, 2026

Summary

Fixes #306retrieve_tools always returned call_with: "call_tool_read" regardless of tool annotations (destructiveHint, readOnlyHint).

Root cause: Two bugs in the annotation lookup path:

  1. handleRetrieveTools split result.Tool.Name on : expecting "server:tool" format, but tool names from upstream discovery are bare (e.g. "delete_records" not "server:delete_records"). The split always produced 1 part, falling through to the call_tool_read default.

  2. lookupToolAnnotations compared StateView tool names (which may include server prefix) against bare tool names, causing lookups to fail even when the split worked.

Fix:

  • Use result.Tool.ServerName directly instead of parsing from Name
  • Handle both "tool" and "server:tool" name formats in lookupToolAnnotations

Test plan

  • Unit test: TestAnnotationLookupNameMatching — verifies name matching with both formats
  • Unit test: TestRetrieveToolsCallWithAnnotations — verifies split + DeriveCallWith logic
  • E2E test: TestE2E_RetrieveToolsAnnotationsAndCallWith — full round-trip with mock upstream server providing destructive/write/read-only tools, verifies correct call_with and annotations in search results
  • All existing unit tests pass
  • Build succeeds

🤖 Generated with Claude Code

…ol_read (#306)

Root cause: handleRetrieveTools split result.Tool.Name on ":" expecting
"server:tool" format, but tool names from upstream discovery are bare
(e.g. "delete_records" not "server:delete_records"). The split always
produced 1 part, falling through to the default call_tool_read.

Additionally, lookupToolAnnotations compared StateView tool names
(which may be in "server:tool" format) against bare tool names,
causing annotation lookups to always fail even when the split worked.

Fix: Use result.Tool.ServerName directly instead of parsing from Name,
and handle both name formats in lookupToolAnnotations.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@cloudflare-workers-and-pages
Copy link

Deploying mcpproxy-docs with  Cloudflare Pages  Cloudflare Pages

Latest commit: 66e823d
Status: ✅  Deploy successful!
Preview URL: https://1f43fb5c.mcpproxy-docs.pages.dev
Branch Preview URL: https://fix-retrieve-tools-annotatio.mcpproxy-docs.pages.dev

View logs

@github-actions
Copy link

📦 Build Artifacts

Workflow Run: View Run
Branch: fix/retrieve-tools-annotations-306

Available Artifacts

  • archive-darwin-amd64 (23 MB)
  • archive-darwin-arm64 (21 MB)
  • archive-linux-amd64 (12 MB)
  • archive-linux-arm64 (11 MB)
  • archive-windows-amd64 (23 MB)
  • archive-windows-arm64 (21 MB)
  • frontend-dist-pr (0 MB)
  • installer-dmg-darwin-amd64 (26 MB)
  • installer-dmg-darwin-arm64 (23 MB)

How to Download

Option 1: GitHub Web UI (easiest)

  1. Go to the workflow run page linked above
  2. Scroll to the bottom "Artifacts" section
  3. Click on the artifact you want to download

Option 2: GitHub CLI

gh run download 22152817793 --repo smart-mcp-proxy/mcpproxy-go

Note: Artifacts expire in 14 days.

@Dumbris Dumbris merged commit be39fd6 into main Feb 18, 2026
23 checks passed
@Dumbris Dumbris deleted the fix/retrieve-tools-annotations-306 branch February 18, 2026 19:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

retrieve_tools: annotations/call_with always defaults to call_tool_read due to tool name parsing bug

2 participants

Comments