get_mcp_server

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating operation. The description adds only marginal context by stating what the response covers (configuration and capabilities), but says nothing about error behavior for unknown IDs or response shape. Given that annotations carry the safety profile, a 3 is appropriate.

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?

A single, front-loaded sentence with zero filler. It states the action and the scope of the returned data compactly. Nothing could be trimmed without losing meaning, and it is correctly sized for a one-parameter read tool.

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?

For a low-complexity, single-parameter read with strong annotation coverage (readOnly, idempotent, non-destructive), the description is nearly complete: it identifies the target, the parameter, and the scope of returned details. The absence of a return-format description is a minor gap given there is no output schema, but it does not obstruct correct invocation.

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 description coverage is 100% — the schema already documents mcp_server_id as 'UUID do MCP server' with a uuid format. The description adds nothing about the parameter beyond the schema, so the baseline 3 applies. Since the single parameter is fully documented in the schema, no compensation is needed.

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 states a specific verb ('Retorna' – returns) and resource (complete details of an MCP server), naming the returned content (configuration and capabilities). It is clearly distinguished from CRUD siblings like create/update/delete_mcp_server and from test_mcp_server. It does not explicitly differentiate from list_mcp_servers, but the get-vs-list distinction is easily inferred.

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?

No guidance is given on when to use this tool versus alternatives such as list_mcp_servers (for enumeration) or test_mcp_server (for connectivity checks). The description implies usage only by restating the function; there are no exclusions, prerequisites, or selection criteria to help an agent choose correctly among the many mcp_server siblings.

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