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

With no annotations, the description carries the behavioral burden. The verbs 'List' and 'show' imply a read-only inspection operation, and 'local allow decisions' indicates local policy state is consulted. However, it does not disclose whether the tool contacts the upstream server live, whether any state is modified, or how invalid server_id values are handled.

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 one concise sentence with no filler. It front-loads the primary action ('List tools exposed...') and follows with the secondary result ('show local allow decisions'), making it easy to scan.

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?

Given the single required parameter, the presence of an output schema, and the simple list-like nature of the operation, the description is largely complete. It states what the tool returns conceptually, though it leaves minor gaps around error behavior and whether the upstream server is queried dynamically.

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 schema only defines server_id as a string with no description, so the tool description must compensate. The phrase 'configured upstream MCP server' ties server_id to an existing configured server, which is the core semantic missing from the schema. It does not explain valid identifier formats or how to discover server IDs, but for a single self-evident parameter this is adequate.

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 uses specific action verbs ('List', 'show') and names the exact resources: tools exposed by a configured upstream MCP server and local allow decisions. This clearly differentiates it from siblings like recipes_mcp_upstream_servers, which presumably lists servers, and recipes_mcp_upstream_call, which presumably invokes a tool.

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 provides clear context for when this tool applies: when the agent needs to enumerate the tools an upstream MCP server exposes and see local allow decisions. It does not explicitly name alternatives or state when not to use it, but the operation is distinctive enough that no exclusions are needed.

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