List tools reachable through the gateway

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is already known. The description adds valuable context about the tool's side effects: it starts each server, reads list_tools output, and shuts it down, which is a behavioral trait (temporary server startup) not captured by annotations. This is useful beyond annotations, though it doesn't detail performance implications or specific error handling beyond fail-closed semantics.

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 three sentences, front-loads the core purpose and side effect (starting servers), then details fail-closed behavior and scope. Every sentence adds unique information, and the guidance on controlcenter_invoke is placed at the end for depth. No waste.

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 has 6 parameters, but 0 are required/resolved, and schema coverage is 100%. Given no output schema, the description doesn't detail the return format, which could be a gap for an agent needing to parse results. However, the description explains fallback behavior and scope, which is helpful, but it lacks pagination or return structure for the list. This is a moderate gap given complexity.

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?

Schema coverage is 100%, so the schema describes all parameters, including the note that schemas dominate output for includeSchemas. The description references 'profile' and 'local MCP root' but doesn't add deeper semantics beyond what the schema already provides (e.g., how 'server' matches multiple identifiers is described in schema). As with the calibration example, baseline 3 is appropriate when the schema covers all parameters.

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 'lists' and the resource 'tools of MCP servers that this host has NOT loaded', and explicitly distinguishes itself from controlcenter_list_tools (which presumably lists loaded tools) and controlcenter_invoke. It also specifies the fail-closed behavior for unreachable servers, making the tool's scope and purpose unambiguous.

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 description explicitly states when to use this tool ('when the tool name is already known') and says it is not required before controlcenter_invoke, directing the agent to call controlcenter_invoke directly in that case. This provides clear guidance on when to avoid this tool, which is more than basic usage context.

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