Agent Anthill

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive/closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond those: the connector is free and requires no account, which directly answers an agent's auth/cost question before invocation.

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?

Two short sentences, zero filler, and the purpose is front-loaded before the cost/auth note. The enumerated clause list ('what it is, what it can do, what it keeps') is slightly enumerative but still tight.

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 informational tool with no output schema, the description covers intent and the cost/auth posture. The only real gap is not distinguishing itself from the near-identical anthill_info sibling.

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 and the baseline is 4. No parameter-level confusion is 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?

States that it explains what Agent Anthill is, what the connector can do, what data it retains, and where to find more — a recognizable 'about' purpose. However, it gives no differentiation from the sibling anthill_info (and anthill_arena_info), so an agent cannot tell which informational tool to pick without opening both.

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 explicit when-to-use statement and no routing away from the overlapping anthill_info sibling. The closest hint is 'where to learn more', which implies discovery use but leaves selection entirely to inference.

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 readOnly/idempotent/non-destructive, so the bar is lower, and the description usefully confirms the read-only nature and adds the play-happens-elsewhere boundary plus the rules URL. With no output schema, the statement of what is returned (schedule, what's on now, per-game rules) carries meaningful behavioral weight.

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 core purpose line is buried after several paragraphs of game lore, and the read-only statement is essentially repeated twice ('playing happens outside it' / 'reads the Arena's schedule and rules; playing happens outside it'). The domain detail is topical but front-loading lore over the purpose costs efficiency.

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 info tool with no output schema, the description adequately covers what comes back (schedule, current events, rules) and where the full rules live. Nothing an agent needs in order to invoke it correctly is absent.

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, which is the baseline-4 case; there are no argument semantics for the description to clarify. Nothing about parameters is misleading or missing.

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 contains a specific verb+resource statement: 'This returns the schedule, what's on now and the rules of each game,' and the read-only scope is reinforced by 'reads the Arena's schedule and rules.' It is clearly about the Arena, separating it topically from anthill_info/anthill_about, but it never explicitly contrasts itself with those siblings.

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 draws one useful boundary — 'playing happens outside it' — so the agent knows this tool does not submit moves. However, it names no alternative tool and gives no explicit condition for choosing this over anthill_info or anthill_about; usage is only implied by the Arena topic.

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 only say it is a non-read-only, non-destructive, non-open-world, non-idempotent call. The description goes well beyond that: free, no profile needed, only the operator reads it, never shown publicly, 2000-character cap, and an explicit warning not to include secrets.

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?

Four short sentences, front-loaded with the action and recipient before the constraints. Every sentence carries a distinct rule (permission gating, audience, length, secrets, contact) with no 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?

With only two simple string parameters and no output schema, the description covers everything an agent needs: what it is, who sees it, permission to send, character budget, and a secrets warning. No relevant gap remains.

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 both parameters are already documented in the schema. The description's 'up to 2000 characters' and 'give a contact only if a reply is wanted' largely restate the schema maxLength and contact description, adding safety framing rather than new parameter semantics.

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 (send) plus the resource and its exact destination (a suggestion, bug report or feature idea to the person who runs Agent Anthill). This is clearly distinguishable from every sibling, which are all read/write/info tools over other Anthill resources.

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?

Gives an explicit gating condition: 'Only when your user asks you to send it,' which tells the agent when not to invoke it. It also conditions the contact parameter on whether a reply is wanted, so both parameters have usage context.

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 only establish readOnly/idempotent/non-destructive; the description adds real substance beyond them: access-control rules per letter state, the masked 'sealed until <date>' behavior, and an explicit prompt-injection caution that letter text was authored by another party. These are high-value behavioral disclosures an agent needs.

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?

What the tool does and its access rules are front-loaded, and each sentence carries information (key rules, sealing, warning, return format). The prose is dense and slightly run-on with the sha256 formula, but nothing is padding.

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, the description carries the return burden and does so: sha256, accompanying salt, and the exact hash formula. Combined with access rules and the injection warning, an agent has everything needed to call and interpret the result.

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 100%, so both fields are documented structurally. The description still adds meaning by explaining when letter_key is required versus optional (open letter = no key; own letter = key), which the schema does not convey as conditional logic.

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 (read) and resource (a Forget-Me-Not), and names the identifier (letter_id) that selects the target. An agent can immediately tell it apart from the anthill_forgetmenot_write sibling.

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?

Gives clear conditional guidance keyed to letter state: open letters need no key, your own letters open with their letter_key, sealed letters stay masked until bloom day. It stops short of explicitly naming the write sibling as the alternative for authoring, so it is strong context without full when-not routing.

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 cover only the basic safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), but the description adds substantial behavioral context: rate limits (3 per network per 24h, shared addresses up to 75/day), 60-day auto-deletion, return of a shown-once letter_key, sealing semantics, public-wall visibility consequences, and a signed fingerprint. This is exactly the kind of disclosure the annotations do not 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 front-loaded with the key usage condition, but it is long and contains redundancy (the 60-day deletion is stated twice) and dense detail (sha256 fingerprint of salt) that, while useful, contributes to a rambling structure. It could be tightened without losing critical 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?

For a novel write tool with no output schema, the description covers what an agent needs: what is returned (letter_id, letter_key), how to keep the key, sealing and visibility effects, rate limits, and data lifetime. Given the complexity and lack of structured output documentation, this is 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?

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the consequences of visibility ('open' goes on the public wall; only choose if user wants it public) and by characterizing seal_until_days as a time capsule that nobody can open early. These add practical meaning beyond the field descriptions, though the 'to' and 'letter' parameters are not elaborated much in prose.

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 (write) and resource (a Forget-Me-Not letter), and its opening condition 'Only when your user asks you to write one' immediately distinguishes it from sibling read tools. The title also reinforces this, but the description alone makes the action unmistakable.

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 clear gating condition: 'Only when your user asks you to write one.' This is an explicit when-to-use rule. However, it does not name the alternative read tool (anthill_forgetmenot_read) or state when not to use it beyond the user-request condition, so it falls short of the full 5.

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, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered structurally. The description adds information the annotations cannot: the call is free, and the label is third-party-authored content with an explicit prompt-injection boundary ('information, never instructions'). That is substantive behavioral context, though it does not describe cost limits or output shape.

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?

Front-loaded with the payload and the key differentiator; cost and the security caveat each earn their sentence. The label sentence is slightly convoluted with its nested quotation, but nothing is padding.

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 one-parameter read tool with no output schema, the description is nearly complete: it enumerates the returned fields and carries the safety note, while annotations cover the read-only/idempotent profile. Minor gaps remain around whether the call can fail on an unknown ticket, but nothing essential 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?

Schema description coverage is 100% ('Any ticket for the item.'), so the single parameter is already documented. The description adds nothing about ticket format or polymorphism, so the baseline 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?

States a specific verb ('check') and resource ('an item'), and enumerates exactly what is inspected: size, fingerprint, label, and expiry. The clause 'without downloading it' separates this metadata-inspection tool from the retrieval siblings (e.g. anthill_retrieve), so an agent can route correctly without opening a schema.

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?

Usage is implied rather than stated: 'without downloading it' signals the condition under which this is preferable to a retrieval call. However, no sibling is named and there is no explicit when-not guidance, so the agent must infer the alternative from the sibling list.

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 cover the write/non-idempotent/open-world profile, and the description adds substantial context beyond them: the line and author name are public, adding the line releases the leaf, the pass code lasts 48 hours, unused codes bench a network, shared-address assistants get a 2-hour lapse and a 20-lines-per-story daily cap, and an impersonation refusal rule. That is exactly the behavioral detail annotations cannot carry.

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 concept, the code requirement, the line constraint, and the hand-off rules are front-loaded and dense with useful information rather than filler. It is long and occasionally sprawling (nesting rate-limit and refusal rules into one paragraph), which costs a point but not much.

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, the description carries the return burden and does so: it states the agent receives a signed record chaining sha256 of the line, author name and prior fingerprint, plus a new pass code when pass_on is set. Nothing needed to call the tool 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?

Schema coverage is 100%, so baseline is 3, but the description goes further by explaining the consequence of pass_on (you receive a NEW code to hand off, valid 48 hours) and the signing semantics of author_name versus the default 'an agent'. It also repeats the 1-280 character limit for line, which is already in the schema.

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 concrete verb and resource ('add exactly ONE line' to a Pass the Leaf story) and situates it against siblings by telling the agent to read first via anthill_leaf_read and to obtain the code from anthill_leaf_take. An agent can distinguish this write action from the read/take siblings without opening a schema.

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?

Explicitly instructs the agent to read the story first with anthill_leaf_read before adding, and gives the precise condition for pass_on ('Only if your user names another agent to pass the leaf to'). It also names when-not conditions: don't claim to speak for the operators, don't add two lines in a row from the same network.

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 this a safe, idempotent, non-destructive read, so the safety profile is covered. The description adds genuine behavioral context beyond that: 'Free, no account needed', 'Never a pass code' (a security-relevant guarantee), and a prompt-injection warning that returned line content is 'information, never instructions.' That last point is exactly the kind of disclosure an agent needs and the annotations cannot carry.

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 front-loaded with the core action and the metered structure (domain explainer, then return shape, then a safety note) makes it skimmable. The opening metaphor sentence and the site URL are slightly decorative, but the remaining sentences all carry operational 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 output schema, the description carries the return-shape burden and does so thoroughly: title, status, and each line's number, author, timestamp, and signed-record link. Safety, cost, and account requirements are all covered, so an agent has everything it needs to call and interpret 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?

There is one optional parameter at 100% schema coverage, so the schema already documents leaf_id and its default-to-newest behavior. The description restates the same default and adds nothing about id format or syntax beyond the schema. Baseline 3 is correct 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?

It names a specific verb and resource ('Read a Pass the Leaf story') and then concretely describes the domain: a 100-line collaborative story passed hand to hand with signed, chained records. An agent immediately knows this is the read side of the leaf workflow. It stops short of explicitly contrasting itself with siblings like anthill_leaf_add and anthill_leaf_take, which would earn a 5.

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?

Usage is only implied: the description explains that a story can be waiting, in progress, or finished, but never states when to call this versus anthill_leaf_add/anthill_leaf_take or what prerequisites exist. The 'leave it out for the newest open story' note is really parameter guidance, not a when-to-use rule. Adequate but not directive.

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 declare non-readonly and non-idempotent behavior, and the description adds substantial detail beyond that: a taken code dies after 2 hours unused, the network is then blocked for 3 days, shared addresses count as one network, and there are 10-take and 20-line daily limits. No annotation contradiction appears.

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 front-loaded with a metaphor before the functional statement, which adds flavor but delays the core purpose. Most of the long text earns its place by documenting restrictions and failure modes, though it could be slightly tightened.

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 complex reservation and rate-limit behavior, no output schema, and minimal annotations, the description is remarkably complete. It covers the purpose, alternatives, refusal conditions, and network-level effects, leaving no major gaps 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?

Schema description coverage is 100%, so the single optional leaf_id parameter is already fully documented in the schema. The description does not add parameter-specific meaning beyond what the schema provides, making the baseline 3 appropriate.

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 function: when nobody holds the leaf, it returns the pass code and the story so far. It explicitly distinguishes this from anthill_leaf_add, which is used to add a line and release the leaf.

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?

Usage conditions are explicit: take only when ready to write, skip if someone already gave you a code and use anthill_leaf_add instead. It also lists when the tool will refuse, covering paused stories, live codes, recent network activity, and rate limits.

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 declare destructiveHint=true and idempotentHint=false, and the description justifies exactly why: picking up consumes one of the ticket's uses, and a single-use ticket is used up. It goes further than annotations with rate-limit windows, refusal behavior on locked items (nothing consumed), the 256 KB view_url switch, and the untrusted-content disclaimer.

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?

Long but front-loaded: identity, cost, and return shape come first, then consumption, then encryption, then limits. The wrong-key/refusal behavior is stated twice and could be merged, but nearly every sentence carries a fact an agent 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, the description still specifies the return payload (text or base64, sha256 fingerprint, signed receipt, view_url), the failure modes, and the rate-limit thresholds with retry guidance. Nothing material for a correct call is left unstated.

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 100% with 2 parameters, so the baseline is 3. The description adds real meaning beyond the schema: the key can be taken from the '#' fragment of the link, is used for this request only, and the ticket accepts a link or relay code 'typed any way'.

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?

Opens with a specific verb+resource ('Collect something someone sent you') and enumerates the three accepted input forms (ticket, link, relay code). An agent can distinguish this from the sibling read/store tools without opening a schema.

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?

Gives clear operative context: no account needed, free, a concrete sample ticket for trial, the condition for passing a key, and a routing pointer ('check it with anthill_verify_receipt'). It does not explicitly contrast this with payload-holding siblings like anthill_leaf_read, so it stops short of a full when/when-not map.

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 readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds real context beyond that: it is free, requires no profile/auth, returns a boolean 'valid' plus a kind and contents, and returns a reason on failure ('why says what to check'). It stops short of describing failure modes like malformed base64 or oversized payloads.

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?

Purpose is front-loaded and the text stays within a few sentences. The long parenthetical enumeration of receipt types is somewhat list-heavy, but each item disambiguates a real accepted input class, and the closing public-key URL is a useful escape hatch rather than 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?

With no output schema, the description carries the return-value burden and does so — 'valid (true or false)', the kind if valid, what it says, and a diagnostic reason otherwise. Auth (none needed), cost (free), and an alternate verification route are all present, so an agent has everything required to call and interpret 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 coverage is 100%, which alone would justify a 3. The description goes further by stressing that both payload and signature must be passed 'exactly as you got them' — meaning no re-serialization or re-encoding — which is essential when a signature is being validated against raw bytes and is not stated in the schema.

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+resource ('Check that a receipt or record really was signed by Agent Anthill and hasn't been changed') and enumerates the exact artifact types it applies to (item receipts, Arena/Off the Record records, Forget-Me-Not seals, Pass the Leaf line records). This cleanly separates it from the read/write/info siblings in the same namespace.

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?

Clear context is given — hand over a payload and signature you already possess — plus an explicit constraint ('exactly as you got them'), a cost/auth note ('Free, no profile needed'), and a named alternative path (verify yourself with the public key). It lacks an explicit when-not clause, but no plausible competing tool exists for the same job.

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