Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
XcodeBuildMCP exposes 3 tools with varying quality. Tool naming follows verb_noun convention and is reasonably clear. However, critical issues emerge: (1) Tool descriptions are severely underdeveloped, xcode_ide_list_tools has a confusing description that reads like a parameter note rather than explaining what the tool does; xcode_ide_call_tool's description is minimal; xcode_tools_bridge_disconnect lacks depth. (2) Input schemas are present but sparse, xcode_ide_list_tools has only a boolean 'refresh' parameter with minimal context; xcode_ide_call_tool has three parameters but descriptions are terse and lack guidance on what arguments the remote tool expects; xcode_tools_bridge_disconnect has an empty input schema. (3) Output schemas are not documented, the source code does not show what each tool returns, making it impossible for LLMs to plan downstream actions or extract chaining IDs. (4) Error handling is not visible, no recovery guidance, no categorization of retryable vs fatal errors, no validation error messages. (5) The architecture relies on a remote 'Xcode bridge' tool, but no description explains when to call list_tools first vs when to call_tool directly, creating ambiguous selection logic for LLMs. This is a domain-specific integration server that prioritizes connectivity over user-facing tool quality.
Tools (3)
xcode_ide_call_toolwrite47/100
Call a remote Xcode MCP tool with arguments
xcode_ide_list_toolsread only45/100
When true, forces a refresh from Xcode bridge. When omitted, uses cached tools if available and refreshes only when the cache is empty.
Output schemas not documented. None of the three tools document what fields they return. LLMs cannot plan multi-step workflows or extract IDs for chaining.
Tool descriptions are under-specified and fail to answer core questions: What does this tool do? When should I call it? What do I get back? Descriptions average ~50 chars vs baseline 194 chars.
xcode_ide_call_tool has an 'arguments' parameter with type 'object' but no schema, validation rules, or guidance on what structure LLMs should pass. This invites malformed calls.
No error handling documentation. No guidance on recovery scenarios: What happens if a remote tool fails? If the bridge disconnects mid-call? If arguments are invalid? LLMs have no recovery path.
Recommendations
Rewrite xcode_ide_list_tools description to: 'Discovers available Xcode build tools and actions. Returns a list of tool names, descriptions, and input signatures. Call this before xcode_ide_call_tool to see what is available. The refresh parameter controls whether to fetch fresh data from the Xcode bridge or use cached results.' (Target: 150-200 chars, answers what/when/why/what-returns.)
Rewrite xcode_ide_call_tool description to: 'Invokes a discovered Xcode tool with provided arguments. Returns the tool's result object. Note: Call xcode_ide_list_tools first to confirm the tool exists and see its expected arguments schema. On timeout, the operation may be incomplete, check Xcode build status before retrying.' (Target: 180-220 chars, includes dependency hint and recovery guidance.)
For xcode_ide_call_tool, replace the bare 'arguments' parameter (type: object) with either: (A) a string-typed 'arguments_json' accepting a JSON string with validation; or (B) document the exact schema the arguments object must conform to, with an example. State: 'arguments: JSON object matching the schema returned by xcode_ide_list_tools for this tool. Validate against the tool's input schema before calling.'
Add an 'Optional output schema' section to each tool's documentation (even if verbose): For xcode_ide_list_tools, document that it returns { tools: [{ name: string, description: string, inputSchema: object }] }. For xcode_ide_call_tool, document that it returns tool-specific output (structure depends on the remote tool; see list_tools for tool signatures). For disconnect, return { status: 'disconnected' }.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Tool composition ambiguity. No description explains the workflow: Is list_tools mandatory before call_tool? What if list_tools cache is stale? Can call_tool work without prior list_tools? This forces LLMs to guess.
xcode_ide_list_tools description is misleading: it describes the 'refresh' parameter ('When true, forces a refresh...') rather than explaining what the tool does. This is parameter documentation placed at tool level.
No guidance on idempotency or retry safety. Are these tools safe to retry on timeout? Does calling list_tools twice with refresh=true cause side effects? This affects agent retry logic.
xcode_ide_list_toolsxcode_ide_call_tool
Add an 'Error handling' section to xcode_ide_call_tool: 'If remoteTool is not found, the error message will list available tools. If arguments fail validation, error includes the expected schema, fetch it from xcode_ide_list_tools and retry. If the bridge is disconnected, error suggests reconnecting (see xcode_tools_bridge_disconnect behavior).'
Rewrite xcode_tools_bridge_disconnect description to: 'Closes the connection to the Xcode Tools bridge. All subsequent calls to xcode_ide_call_tool will fail until the bridge reconnects. Idempotent, safe to call multiple times. Returns { status: "disconnected", timestamp: string }. This is typically used for cleanup at the end of a session.'
Add a top-level server description (if not present) explaining the Xcode integration architecture: 'This server bridges to an Xcode build environment. Start by calling xcode_ide_list_tools to discover available actions. Then use xcode_ide_call_tool to invoke them. Use xcode_tools_bridge_disconnect to cleanly close the session.' This guides overall workflow.
Document parameter constraints for timeoutMs: 'Optional timeout in milliseconds (100 - 60000; default behavior uses bridge timeout). Override the default only if you expect a specific tool to be slower or faster than usual.'
Add 'When to call this tool' guidance to each tool's description, as a bullet: (list_tools) 'Call at the start of a session, or after a previous call timed out'; (call_tool) 'Call after list_tools confirms the tool exists and you have valid arguments'; (disconnect) 'Call at the end of the session or if you need to reset the bridge connection.'
If supported, define and document output pagination or limits: If xcode_ide_list_tools can return 100+ tools, document that it returns (e.g.) the first 50 and supports a 'filter' parameter to narrow the list.