list_pending_approvals

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

No annotations are provided, so the description carries the transparency burden. It says 'Show' and 'Renders', implying a read-only operation, and includes the behavioral detail of 'newest first' ordering. Yet it does not explicitly state that no changes are made, nor does it clarify what 'interactive approval console' entails (e.g., whether it requires user input or has side effects). This is moderate disclosure for a list tool.

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 short sentences totaling 23 words, with no redundant phrases. The first sentence states the core function and ordering, the second adds the output format ('interactive approval console'). Every word earns its place, making it appropriately sized and front-loaded.

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 simple tool with one optional parameter and no output schema, the description covers the main purpose and ordering but lacks detail on the exact return format or any prerequisites/permissions. Given no annotations, it could mention that it is a safe, read-only operation. The phrase 'interactive approval console' is vague and could be expanded, but the tool is straightforward enough that this is adequate yet not fully 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 schema has one parameter, serverId, with the description 'Limit to one server; omit for all', giving 100% schema description coverage. The tool description adds no additional parameter semantics, which is acceptable since the schema fully explains the parameter. Baseline 3 is appropriate because the description doesn't need to compensate for schema gaps.

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 tool 'Show every action currently blocked and waiting on a human decision, newest first.' This identifies a specific verb ('Show') and a clear resource (actions blocked on human decisions), which distinguishes it from sibling tools like approve_action, deny_action, and request_action that modify or request approvals rather than listing them.

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 to use the tool: to view all pending approvals. It doesn't explicitly exclude alternatives, but the role is evident from the sibling set. However, it does not mention specific scenarios where a different tool should be used, such as filtering by server or taking action on an approval.

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