map_get_all_connections

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 does add useful context: the tool includes auto-generated connections and marks them with an 'auto:true' flag. However, it does not explicitly state that the operation is read-only, nor does it mention any side effects, performance implications, or permission requirements. The verb 'return' implies read-only, but the description could be more transparent about safety and return behavior.

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 core purpose and the key distinction (auto-generated connections). Every sentence adds value: the first defines the action, the second explains the flag, and the third gives usage guidance. No filler or redundant information.

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 zero-parameter, no-output-schema tool, the description covers the essential aspects: what it returns, the special auto-generated feature, and how it differs from map_get_state. The main gap is that it does not describe the return structure (e.g., whether it returns an array, or what fields each connection has beyond 'auto'). However, given the tool's simplicity, this is a minor omission and the description is largely complete.

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 tool has zero parameters, and the schema is empty, so there is nothing to document. Per the rubric, a baseline of 4 applies. The description does not need to add parameter syntax or semantics since there are none.

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 explicitly states the tool's purpose: 'Return all connections including auto-generated ones.' It also names the specific resource and scope, and distinguishes itself from the sibling tool map_get_state by noting that map_get_state.connections lacks the full topology picture. This is a specific verb+resource+scope that clearly differentiates from alternatives.

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 gives explicit guidance on when to use this tool: 'Use this instead of map_get_state.connections when you need the full topology picture.' It names the alternative tool and provides a clear condition, satisfying the 'when-to-use vs alternatives' requirement fully.

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