Two tools with minimal descriptions and incomplete schemas. imcp_list_tools has a 47-char description (below 50-char baseline for clarity) and empty input schema ({}), which is acceptable for a no-arg tool. imcp_call has a 56-char description and two parameters with types but lacks depth on what 'arguments' should contain or how errors are handled. Neither tool documents output schemas, pagination, or error recovery paths. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles. Naming is verb-forward but generic ('call' is vague, does it execute, invoke, or dispatch?). No parameter constraints, enums, or format guidance. This server acts as a bridge/proxy to other MCP tools rather than exposing domain-specific functionality, which limits the applicability of standard tool patterns.

• Add output schema documentation for imcp_list_tools: return an array of tool objects with {name: string, description: string, inputSchema: object}. Include pagination if >50 tools.
• Expand imcp_call description to 100-150 chars: explain it forwards calls to remote MCP servers, when to use it vs direct tools, and that it may fail if the tool name is invalid or arguments don't match the tool's schema.
• Document the 'arguments' parameter schema as 'object with tool-specific fields; structure depends on the target tool's inputSchema. Validate against the tool's schema before calling.'
• Add error handling guidance: 'If tool not found, call imcp_list_tools first. If arguments invalid, review the tool's inputSchema and retry with corrected fields.'
• Annotate imcp_list_tools with readOnlyHint=true and imcp_call with destructiveHint=true (since it can modify remote state) to help LLMs reason about side effects.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry