mcp_call_server

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that Rocket+ routes calls but does not disclose side effects, permissions, rate limits, or error behavior, which is significant for a tool that can invoke arbitrary server actions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the tool's purpose and free of fluff. The second sentence adds useful context about the hub role without unnecessary length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool involves a nested serverArgs object and has no output schema, yet the description does not explain how to construct arguments or discover available tools. It also fails to point to sibling tools like mcp_list_servers or ghl_mcp_tools for necessary context, leaving the agent under-informed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides descriptions for all three parameters, achieving 100% coverage, so the baseline is 3. The description adds no parameter-specific information beyond what the schema already includes.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Call' and the resource 'tool on any connected MCP server', establishing it as a generic routing tool. It distinguishes from siblings like ghl_mcp_call, which targets a specific server.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'any connected MCP server' implies generic usage, but it does not explicitly state when to prefer this over dedicated tools like ghl_mcp_call. No alternatives or exclusion criteria are mentioned, leaving usage to be inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.