Annotation-survival conformance

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

With no annotations, the description carries the full behavioral burden. It does disclose one useful trait — 'Bearer token required' — but says nothing about read-only behavior, rate limits, pagination, or what the returned status actually contains, leaving most behavioral questions unanswered.

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 short sentence with no filler, and the auth requirement is tucked at the end rather than buried. It is arguably too terse for a tool whose scope overlaps several siblings, but nothing 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?

For a zero-parameter tool with no output schema and no annotations, the description establishes roughly what data is returned and the auth requirement, which is the minimum viable. It stops short of describing the return shape or how the 'plan/trial status' fields should be interpreted.

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 takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly does not invent arguments.

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 names the resources it surfaces ('servers, plan and trial status') and implies a read of account data, but it has no verb and never says it retrieves/fetches anything. It also does nothing to distinguish it from siblings like annsurv_check, annsurv_limits or annsurv_pricing, which plausibly overlap with 'servers' and 'plan'.

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?

There is no when-to-use guidance whatsoever: no condition for choosing this over annsurv_check, annsurv_pricing, or annsurv_paths. The only context is the parenthetical auth note, which is a prerequisite, not usage 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?

With no annotations, the description carries the full burden, and it does disclose one genuinely important behavior: paid work is refused over MCP and delivered only via x402. It says nothing about response content, whether any auth is needed to read the explanation, or what happens on the public path.

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 dense sentence with the subject front-loaded and the payment constraint following it; nothing is redundant. The semicolon construction packs two ideas efficiently, though it is slightly clipped.

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-param, no-output-schema informational tool, the description should indicate what the explanation contains (e.g., pricing, endpoint, or requirements), and it only supplies the endpoint shape. It is adequate to identify the tool but thin on what the agent gets back.

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 takes zero parameters, so per the rubric the baseline is 4. There is no parameter behavior left to clarify and the description does not misrepresent the empty input.

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 subject (the paid full-matrix check path) and implicitly disambiguates from the name's suggestion that this tool performs a check -- it explains one instead. That distinction is useful against siblings like annsurv_paths, though the verb 'explains' stays generic about what the tool actually returns.

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 implies usage by routing paid work away from MCP to x402 on POST /check, so an agent can infer this tool is for understanding the paid path. However, there is no explicit 'use this when' clause and no named alternative tool within the annsurv_* family.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It names the limit topics but does not state whether the tool is read-only, whether it returns static documentation, what the response contains, or whether any permissions are needed.

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 definition is a single compact sentence with the main topic front-loaded. The parenthetical examples are somewhat cryptic, but there is no unnecessary 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 informational tool with no output schema, the description gives enough topical scope to identify the content area. It still does not explain the return format or clarify how an agent should use the documented limits, leaving a meaningful gap.

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, so there is no parameter semantics to explain. Per the baseline for zero-parameter tools, a 4 is appropriate; the description does not need to add parameter details.

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 identifies the resource as documented limits and lists four limit categories, which gives a topical sense of the tool. However, it is a noun phrase without a verb or explicit statement of what the tool does (e.g., retrieve, list, display), and it does not distinguish the tool from sibling endpoints.

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?

There is no guidance on when to call this tool versus alternatives such as annsurv_check or annsurv_verify_receipt. The parenthetical list implies content but does not state the conditions or questions the tool is meant to answer.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what data is returned (the 6 paths and their corpus versions) but says nothing about read-only behavior, side effects, authentication needs, or rate limits.

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 definition is a single, efficient sentence with no wasted words. It is front-loaded with the resource, though it lacks an explicit action verb that would improve structure.

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 tool with no output schema and no annotations, the description is the sole source of information. It names the returned entities but does not state the operation performed or how the result should be used, leaving clear gaps for an agent.

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 takes zero parameters, so the baseline score of 4 applies. There are no parameter semantics to clarify in the description.

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 is a noun phrase that identifies the resource (the 6 tracked conversion paths and the corpus version each is graded under) but does not name an action verb, so an agent cannot tell whether this lists, fetches, or returns data. It adds specificity beyond the name by mentioning '6 tracked' and grading context, but it does not distinguish the tool from siblings like annsurv_check or annsurv_verify_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 provides no when-to-use guidance, no exclusions, and no mention of alternative sibling tools. An agent must infer entirely from the name and the description's content alone.

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?

No annotations are provided, so the description carries the full behavioral burden. It states what information is covered but not whether the call is read-only, whether auth is required, how results are returned, or whether pricing is live/cached.

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?

One short, front-loaded sentence fragment with no wasted words. It could be slightly clearer as a full action statement, but concision is strong.

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 no-parameter informational tool, the description broadly covers the topics returned. However, with no output schema and no annotations, it should better explain return format/scope (e.g., currencies, plan tiers) and how it differs from annsurv_limits.

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?

There are zero parameters, so the empty schema leaves nothing for the description to compensate for. Baseline 4 applies for a no-parameter tool.

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 phrase identifies the content (pricing, plan caps, trial rule) but is a noun fragment with no action verb. It does not differentiate from sibling annsurv_limits, which likely also covers plan caps.

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?

There is no statement of when to call this tool versus annsurv_limits, annsurv_account, or annsurv_check. The agent must infer usage from the name and content alone.

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?

With no annotations, the description carries the full burden and discloses one important behavior: paid verdicts are refused over MCP and must be retrieved via x402 on GET /receipt. However, it omits other relevant traits such as whether the tool is read-only, what it returns for non-paid receipts, and any authentication or rate-limit 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 a single, short sentence with two clauses and no filler. The purpose clause is front-loaded, though the second clause is cryptic and could have been clearer.

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 tool with no annotations, no output schema, and zero schema description coverage, the description is too thin. It mentions an x402/MCP payment constraint but does not fully explain the tool's behavior, return values, or parameter semantics.

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 0%, so the description must compensate for the undocumented receipt_id parameter. It never explains the format, source, or meaning of receipt_id, adding no semantic value beyond the parameter name.

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 says it 'Explains the paid receipt-query path,' which suggests documentation rather than a query operation, yet the input schema requires a receipt_id. It does not clearly state what the tool returns or distinguish it from sibling tools such as annsurv_verify_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?

It notes that paid verdicts are refused over MCP and deliver over x402 on GET /receipt, which is a usage constraint, but it gives no explicit guidance on when to use this tool versus alternatives like annsurv_verify_receipt or annsurv_check.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the verification method (Ed25519) and that a gate decision is produced, but says nothing about failure semantics, error behavior, permissions, or what a valid/invalid verdict looks like.

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 no wasted words. Its brevity is appropriate, though it sacrifices detail that this tool arguably needs.

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 no output schema, no annotations, and a nested parameter at 0% coverage, the description should explain the receipt structure and what 'gate decision' means. It does neither, leaving an agent unable to construct the input or interpret the result confidently.

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 coverage is 0% and the single 'receipt' parameter is an opaque nested object. The description hints that the receipt contains a signature and id, which adds some meaning, but it does not document the object's expected shape or required fields.

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 names a specific verb (Verify) and a precise resource (a survival receipt's Ed25519 signature and id), plus an extra output (gate decision), which clearly separates it from generic siblings like annsurv_check. It is not a tautology, though it never explicitly contrasts itself with annsurv_receipt_query.

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?

There is no indication of when to reach for this tool versus annsurv_check or annsurv_receipt_query, no prerequisites (e.g., a receipt must already be fetched), and no exclusions. The agent is left to infer the workflow entirely.

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