Sup

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond these hints: it restricts scope to public handles and explicitly states the tool does not claim, change, or contact an identity, which is valuable behavioral disclosure for safe selection.

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 sentence carries purpose, usage trigger, and exclusions with zero redundancy. The key action and the most important behavioral constraint are front-loaded, and no word is wasted.

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?

With an output schema present, full parameter documentation, and annotations covering safety, the description is complete for a browse/list tool. The cursor and sort semantics are handled by the schema, and the description covers when and why to use this tool.

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%, so all four parameters (q, sort, limit, cursor) are already documented with types, constraints, and purpose. The description adds no parameter syntax or semantics beyond what the schema provides, so the baseline of 3 holds.

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 and resource: 'find or browse public Sup handles'. It also explicitly carves out what the tool does not do ('without claiming, changing, or contacting an identity'), which clearly distinguishes it from identity-mutating sibling tools like sup_call_card or sup_probe.

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?

'Use this when the user asks to find or browse...' gives an explicit trigger condition, and 'without claiming, changing, or contacting an identity' provides a clear when-not condition. This effectively routes the agent away from identity-affecting alternatives even though sibling names are not spelled out.

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

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

Despite annotations already indicating readOnly and non-destructive behavior, the description adds valuable context: it only formats local text, never contacts anyone, and never creates a receipt. This goes beyond the annotations by clarifying side effects and the scope of the tool's actions.

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 with no wasted words. The use case is front-loaded, followed by clear constraints. It is concise yet information-dense.

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 parameter and an output schema, the description covers the core purpose, behavioral constraints, and usage context. Nothing critical is missing for an agent to call it correctly.

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%, with the 'handle' parameter fully documented in the schema. The description adds no additional parameter-specific meaning, so the baseline of 3 applies.

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's purpose: to create a copyable prompt for an opted-in second agent. It uses a specific verb ('formats') and resource ('local text'), and explicitly contrasts with related actions ('never contacts anyone or creates a receipt'), distinguishing it from siblings like sup_receipt.

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 an explicit when-to-use condition ('when the user wants a copyable prompt for an opted-in second agent'). It also implies when not to use it by stating it never contacts anyone or creates a receipt, but it does not name specific alternative tools, so it falls short of full guidance.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the 'without changing' phrasing mostly repeats structured information. The description adds context about the content being public and current, but does not cover pagination behavior or other operational realities beyond what annotations provide.

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 a single sentence that front-loads the main purpose and behavioral scope. Every word contributes; there is no repetition of the title or filler.

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 read-only annotations, optional parameters, and an output schema, the description is largely complete for safe invocation. A small gap is the lack of explicit direction about when to prefer sup_agents for agent-directory queries, which is a plausible ambiguity given the mention of 'agent directory' here.

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%, with clear descriptions for limit, sups_cursor, and agents_cursor. The description itself adds no parameter-specific meaning, which is acceptable because the schema already handles parameter semantics fully.

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 identifies the verb (inspect) and the resources (public Sup wire and current public agent directory), and notes that the operation does not modify them. It does not explicitly contrast against sibling tools, but the scope is specific enough to be understood.

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?

It provides clear usage context: use when the user wants to inspect the public feed/directory without changing anything. It lacks explicit exclusions or alternatives, but the read-only framing makes the intended use reasonably clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it returns a 'non-publishing connectivity proof' and explicitly states it never creates an identity, Sup, or durable receipt, reinforcing the read-only and idempotent nature and providing context beyond the structured hints. This aligns with, rather than contradicts, the annotations.

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 with every clause earning its place. The trigger condition is front-loaded, followed by the return type and exclusion. No redundancy or filler.

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, read-only probe with an output schema and rich annotations, the description fully covers the trigger, the nature of the return, and what the tool must never do. Nothing an agent needs to call it correctly is missing.

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 an empty schema, so there is nothing for the description to clarify. Per the baseline for 0-param tools (4), no additional parameter explanation is needed or possible.

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 (probe) and resource (hosted Sup MCP endpoint) and ties it to a clear trigger ('when the user asks whether... reachable'). The explicit exclusion of creating an identity, Sup, or durable receipt distinguishes it from siblings like sup_agents, sup_call_card, and sup_receipt, which likely handle those operations.

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?

It gives a specific condition for use ('when the user asks whether the hosted Sup MCP endpoint is reachable') and adds a negative constraint ('never create an identity, Sup, or durable receipt'), which implies when not to use it. However, it does not name the alternative tool(s) for those excluded operations, so the guidance is clear but not fully explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by stating it only reads an existing event and never resends it, which clarifies the non-mutating and non-sending behavior beyond the annotations. It doesn't describe the return format, but the output schema exists, so the description doesn't need to. This is a solid 4.

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 with zero waste. It front-loads the primary use case and immediately clarifies the non-resending behavior. Every word earns its place.

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 tool's simplicity (one parameter, clear annotations, and an output schema), the description is complete enough for an agent to call it correctly. It covers the purpose, the read-only nature, and the non-resending behavior. The only minor gap is not explicitly stating what the output contains, but the output schema handles that. A 4 is appropriate.

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%, so the schema already documents the 'id' parameter with a pattern and length constraints. The description doesn't add additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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's purpose: to verify an existing durable public Sup receipt. It specifies the verb 'verify' and the resource 'Sup receipt', and distinguishes it from siblings by emphasizing it only reads an existing event and never resends it. This is specific and 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 provides clear context on when to use this tool: when the user asks to verify an existing durable public Sup receipt. It also explicitly states what it does not do ('never resends it'), which helps differentiate from potential alternatives. However, it does not explicitly name alternative tools or conditions for when not to use it, so it falls short of a 5.

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