Trust Does Not Transfer - Change-of-Control Re-Attestation

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, and it discloses only one trait: that a Bearer token is required. It does not say whether the operation is read-only or mutating, whether re-attestation changes state, whether it is idempotent, or what happens on failure.

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?

It is a single short line with no filler, which is structurally efficient, but the front-loaded content is a vague noun phrase rather than an action statement. Brevity here reflects under-specification as much as conciseness.

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 parameters and no output schema, the description does not need to document returns. However, for a tool whose name implies a 'reattest' action, it never explains what that action does or what 'fleets, watch and plan status' refers to, leaving the agent under-informed about the operation itself.

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 of 4 applies per the rubric. There is no parameter semantics for the description to clarify or omit.

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 fragment ('Your fleets, watch and plan status') with no verb stating what operation is performed. An agent cannot tell whether this reads, refreshes, or re-verifies account data, and nothing distinguishes it from siblings like reattest_floors or reattest_trust_state. It hints at a resource area but stops short of a clear purpose.

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 use this tool versus the five sibling reattest_* tools, nor any prerequisites or exclusions. The only conditional cue is the auth note in parentheses. The agent is left to infer all routing decisions.

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, and it discloses nothing: no read vs. write semantics, no prerequisites, no side effects, no return shape. 'Ladder shape' hints at structure but explains nothing actionable.

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?

It is short, but the brevity reflects under-specification rather than efficient structure. The single cryptic fragment is not front-loaded around any actionable 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?

With no annotations and no output schema, the description is the only source of information about what this tool produces, and it explains neither the returned data nor its relationship to the other reattest_* tools. It is far too thin for an agent to select or invoke it 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?

The input schema has zero parameters, so there is nothing for the description to document; the baseline for a no-parameter tool applies. No parameter meaning is lost.

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 fragment ('Per-class freeze floors and the ladder shape') with no verb, so an agent cannot tell whether the tool returns, sets, or simulates these floors. It gestures at a resource but does not distinguish it from siblings like reattest_limits or reattest_pricing. This reads as a restatement of the tool name rather than a statement of purpose.

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 call this tool, when not to, or which sibling is the alternative. With six similarly named reattest_* tools, the absence of any routing guidance is a serious gap.

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 and no output schema, the description carries the full behavioral burden and does not meet it. 'Reattest' implies some re-verification/attestation semantics, but the description never says whether this is a read, a re-attestation write, what permissions it needs, or what it returns. It only lists topics.

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?

It is a single short fragment with no wasted words, but it is a sentence fragment rather than a structured statement, and its brevity is closer to under-specification than intentional concision. The parenthetical list is front-loaded, which is the one structural strength.

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 and no annotations, the description is the only source of information about what an agent gets back, and 'documented limits (…)' does not describe the return shape, units, or format. For a tool whose only job is to surface limits, that leaves a significant 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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param tool is 4. No schema detail is duplicated or contradicted.

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 resource ('documented limits') and hints at content areas (signal-bound detection, latency, receipt acceptance, WTP), which is more than the bare name provides. But it is a noun fragment with no verb, and the cryptic 'reattest' prefix plus unexplained acronyms (WTP) leave the actual operation ambiguous. It offers no differentiation from the five sibling reattest_* tools.

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, no prerequisites, and no mention of any alternative sibling tool. An agent has no basis for choosing this over reattest_floors, reattest_pricing, or the others.

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?

There are no annotations, so the description must carry the full behavioral burden. It lists the data domains but does not explicitly state that this is a read-only retrieval, whether the pricing is account-scoped, whether it requires authentication, or what the response 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?

It is a single compact sentence with no wasted words. The structure is a bare noun phrase rather than a front-loaded action statement, but it remains extremely concise.

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, the description gives a useful outline of returned content. It is still incomplete because it does not clarify how pricing relates to plan caps in reattest_limits or whether the pricing is global or account-specific.

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 are no parameter semantics for the description to clarify. The baseline score of 4 applies because no input documentation is needed.

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 'Exact prices, plan caps and the one-time trial rule' identifies the resource as pricing information and adds specific content categories. However, it is a noun fragment with no verb and does not explicitly state that it retrieves or returns pricing data, nor does it clearly distinguish itself from the overlapping sibling reattest_limits.

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 no guidance on when to use this tool versus reattest_limits or other siblings, no prerequisites, and no exclusions. A reader must infer usage entirely from the tool name and the listed data categories.

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 behavioral burden. It usefully discloses that paid verdicts are refused over MCP and must be fetched via x402 on GET /trust-state, which is a key operational constraint. Yet it omits authentication, rate-limit, error, and return-shape behavior for the call itself.

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 tight sentence with no filler and front-loads the paid path context. It is appropriately sized for a one-parameter tool, though its density borders on cryptic.

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 no annotations, no output schema, and an undocumented required parameter, the description should cover more ground. It discloses the paid-verdict refusal but leaves the agent without enough context about what the tool returns or how to use the 'fleet' input, so it is incomplete for correct invocation.

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 single required 'fleet' parameter has 0% schema description coverage and is never mentioned in the description. The description provides no meaning, format, or example for this parameter, so it fails to compensate for the schema gap, though the small parameter count limits the severity.

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 action ('Explains') and resource ('the paid trust-state path'), but it is ambiguous whether the tool returns an explanation or is merely a notice about paid verdicts. It does not clearly distinguish itself from the other reattest_* siblings, so an agent cannot confidently infer its core function from the text alone.

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 when not to use the tool ('paid verdicts are refused over MCP') and points to an external alternative (x402 on GET /trust-state), which is useful routing information. However, it names no sibling MCP tools and gives no explicit when-to-use guidance for this tool versus them.

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. 'Verify' implies a read-only, non-mutating check, but the description never confirms that, nor does it say what happens on hash/signature mismatch, whether external trust data is required, or what the result looks like. With no output schema either, key behavior is left to inference.

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 zero filler; nothing is redundant. It is efficient, though the brevity comes at the cost of the information an agent actually 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?

For a cryptographic verification tool with no annotations, no output schema, and a completely undocumented required parameter, a one-line description is insufficient. The agent lacks the input format, the trust/prerequisite context, and any notion of the outcome, so it cannot reliably invoke this 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 0% and the sole required parameter is an untyped array named 'receipts' with no element structure. The description hints that the array is a 'receipt chain copy' containing hashes and signatures, but it never states the expected item shape or ordering, so the agent cannot construct a valid call from the docs alone.

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?

States a specific verb (verify) and resource (receipt chain copy's hashes and signatures), so an agent can tell this is a cryptographic verification operation. It does not differentiate from siblings, but none of the sibling names (account, floors, limits, pricing, trust_state) overlap with chain verification, so the ambiguity is low. The term 'receipt chain copy' is jargon that assumes domain familiarity.

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 call this versus other reattest_* tools, no prerequisite context (e.g., does it require a previously fetched chain copy or trust state?), and no statement about what a failure means. The single sentence names an action but gives the agent nothing to route on.

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