Agent Anthill

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

Annotations cover the safety profile (idempotent, non-destructive, open-world), and the description adds real operational context: verification happens on Base, requires 3 confirmations, and may return a 'pending' state requiring a re-call. That pending/retry behavior is not inferable from 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?

Three short sentences, front-loaded with the trigger action and followed by verification and retry guidance. No filler sentences.

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?

No output schema exists, and the description usefully warns about the possible 'pending' response. Auth handling is covered by the schema. For a 2-param confirmation tool this is nearly complete, though it could note whether failed verification errors or returns a status.

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 tx_hash and profile_key are fully documented in the schema. The description adds only that the hash is a Base transaction, which is marginal value beyond what the schema already states.

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 (confirm) and resource (deposit) plus the exact input action: submit the transaction hash after sending USDC. It implicitly separates itself from the sibling anthill_deposit, which initiates rather than confirms.

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 context for when to call it ('After sending USDC') and an explicit retry condition for the 'pending' case. It does not name an alternative tool for edge cases, but the usage window is unambiguous.

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 declare non-read-only, non-idempotent, non-destructive. The description adds the critical behavioral facts the annotations cannot express: the secret_key IS the profile, anyone holding it can spend the balance, and there is no recovery. It also discloses the return payload (profile_id + secret_key) and that creation constitutes acceptance of Terms and Abuse policy.

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 purpose and the security warning are front-loaded, and the follow-on actions and policy links are placed last where they belong. It is slightly dense, with the Terms/Abuse URLs taking a full sentence, but every sentence carries 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?

There is no output schema, and the description compensates by naming exactly what is returned (public profile_id and secret_key). For a zero-required-parameter creation tool, the security model, follow-on funding step, and pricing reference cover everything an agent needs.

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 a single optional 'name' parameter already documented as an optional display name with an example. The description adds no further parameter detail, 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?

The first sentence states a specific verb and resource ('Create your Agent Anthill profile') and immediately scopes it as free. This is unambiguously distinguishable from sibling operations like anthill_delete or anthill_rotate_key.

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 explicitly routes the agent forward with 'Next step: fund it with anthill_deposit' and 'Prices: see anthill_pricing', naming the alternatives for the follow-on actions. It does not state when NOT to create a profile (e.g. that an existing profile_id/secret_key should be reused instead), which keeps it 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.

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

Annotations declare destructive and non-readOnly, but the description adds substance beyond them: the cascade invalidation of all tickets, the zero cost, the mandatory owner_ticket credential, irreversibility, and a signed deletion receipt return. This is the kind of side-effect and output disclosure annotations cannot carry, and it is consistent with them (idempotentHint=true is not contradicted by permanent deletion).

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?

Five short clauses, front-loaded with the action and effect, then guards (cost, precondition, irreversibility) and finally the return. Every clause carries information; 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 destructive tool with no output schema, the description covers side effects, cost, credential requirement, irreversibility, and the return artifact — enough to call it safely. The one gap is how the agent acquires a valid owner_ticket, which matters for a mandatory credential.

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%, but the schema's own description is a tautology ('The owner_ticket.'), so the baseline applies. The description only reconfirms that owner_ticket is required and does not explain what the ticket is or where the agent obtains it, adding little beyond 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 specific verb and resource ('permanently delete an item') plus its cascade effect ('invalidate all its tickets'), so the agent knows exactly what this does and what collateral change it causes. No sibling overlaps the delete role, so differentiation is implicit but 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?

Gives the precondition ('Requires the owner_ticket'), the cost ('Free'), and the irreversibility warning ('Cannot be undone') — solid context for deciding to call it. It stops short of naming when to prefer an alternative path, though no sibling offers a competing delete capability.

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 declare the generic write/non-idempotent/non-destructive profile; the description adds substantial non-structured behavior — it returns a wallet address plus an exact tail-bearing amount, the request expires in 60 minutes, and bonus/founding-profile incentives apply. These are the traits an agent needs and cannot get from the annotation flags.

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 in the first sentence, followed by mechanics, then eligibility/bonus rules. Every sentence carries actionable content — no filler, no repetition of the name or title.

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 names the returned wallet address and exact amount. Combined with expiry and the required follow-up call, nothing needed to invoke and complete the flow 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%, so the baseline is 3. The description adds real meaning beyond the schema by clarifying that amount_usd is only 'roughly' what will be sent — the actual transfer amount includes a unique identifying tail, which materially changes how the value is used. That nuance is not 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 specific verb and resource — 'Add credit to your profile with USDC on Base' — and distinguishes itself from siblings by naming anthill_confirm_deposit as the mandatory follow-up step. An agent can tell this is the initiation half of a two-step deposit flow 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 narrates the workflow: call this, send the exact amount, then 'call anthill_confirm_deposit with the transaction hash.' It also gives the conditions that govern use (minimum $1, 60-minute expiry, bonus threshold at $5+). Nothing about when or where to route is left 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?

Beyond the annotations (readOnly=false, idempotent=false, destructive=false), the description discloses that the extension is billed as storage to the owner and capped at 720 hours from now. These are meaningful operational facts an agent needs; reversibility and stacking behavior remain unstated.

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?

Three short sentences, zero waste, with the core action front-loaded. Everything stated earns its place except the mild restatement that owner_ticket is required, which is trivial.

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 two-param mutation tool with annotations covering the safety profile and no output schema, the definition covers billing, prerequisites, and the cap. Edge cases such as failure behavior or whether extensions stack are omitted but not critical.

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, but the description adds a real constraint not in the schema: the 720-hour maximum on add_hours. It also reinforces that owner_ticket is mandatory, adding modest value over the schema text.

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?

"Push an item's expiry later" gives a specific verb and resource, and the billing clause distinguishes it from sibling storage tools. It does not explicitly name an alternative sibling, but the core action is 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 implies you use it to extend storage and states the owner_ticket is required, but gives no explicit when/when-not guidance or named alternatives among the many storage siblings. Usage is inferable but 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the 'without downloading it' efficiency guarantee and the 'Free' cost signal — neither of which appears in structured fields. It stops short of describing rate limits or response shape, but the added cost/bandwidth context is genuinely useful.

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, with the operation and its returned fields front-loaded before the cost qualifier. Every clause 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?

For a read-only metadata tool with rich annotations and a fully documented single parameter, the description is nearly sufficient, and it usefully enumerates the returned fields in lieu of an output schema. Minor gaps remain around ticket sourcing and error behavior, but nothing critical for correct invocation 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?

There is a single 'ticket' parameter with 100% schema description coverage ('Any ticket for the item.'), so the schema already carries the semantics. The description adds nothing about ticket format or sourcing, which is the expected baseline 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 states a specific verb ('Check') and resource ('an item') and enumerates the metadata returned — size, fingerprint, label, expiry — so the agent knows exactly what this tool yields. It doesn't explicitly contrast itself with siblings like anthill_retrieve or anthill_store, but the 'without downloading it' phrasing implicitly separates it from retrieval.

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 this is the cheap metadata-only path versus anthill_retrieve, but no sibling is named and no explicit when/when-not condition is given. An agent can infer the intent but must do the routing work itself.

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, non-destructive, and closed-world behavior. The description adds cost and authentication context ('Free, no profile needed') that is not present in annotations, which is valuable. It stops short of describing return format, freshness, or the level of detail in deposit rules.

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, front-loaded with the resource content and followed by the access condition. Every phrase contributes and 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, read-only pricing lookup with annotations already covering safety and idempotency, the description's content outline is largely sufficient. It could be slightly more complete by hinting at the form of the deposit rules or pricing freshness, but no output schema exists to require return-value documentation.

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?

This tool takes zero parameters, so there are no parameter semantics for the description to supplement. The baseline score of 4 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 names a specific resource (pricing) and enumerates the exact content it covers: current prices, launch discount, founding-profile tiers, and deposit rules. Together with the title 'Get prices' and tool name, an agent can distinguish it from generic siblings like anthill_info.

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?

'Free, no profile needed' gives a useful access condition, but the description does not state when to use this tool versus alternatives such as anthill_info or anthill_deposit, nor does it mention any exclusions. Usage is implied rather than explicitly guided.

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, openWorldHint=false, and destructiveHint=false, so the full safety profile is covered without the description. The description adds nothing behavioral (no auth/key requirement, no caching or refresh semantics), so it neither helps nor misleads.

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 well-formed sentence that front-loads the action and lists the return contents with zero filler. Nothing to trim.

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 usefully enumerates what the caller gets back (balance, founding status, discount), which is exactly the compensation needed. Auth is covered by the schema's parameter description, leaving only alternative-selection guidance 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% and the single profile_key parameter is fully documented in the schema, including the 'anthill_sk_' prefix and the Authorization-header alternative. The description adds no parameter meaning, 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 (see) plus the resource (your profile) and enumerates the three data points returned: balance, founding status, and applied discount. That enumeration lets an agent distinguish it from generic siblings like anthill_info or anthill_pricing, though it never names those siblings explicitly.

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: you call this when you want to see your own balance/status/discount. There is no explicit when-to-use or when-not-to-use guidance, and no routing against anthill_info, which sounds adjacent.

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?

Goes well beyond the readOnly/idempotent annotations by disclosing the 90-day post-deletion retention window, the cost (free), the authentication requirement, and the privacy model — receipts contain fingerprints and times, never content. It also documents how to verify signatures via a public key endpoint, which is material behavior the annotations cannot express.

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 what receipts are and what they contain, then retention/cost/auth, then verification. Three compact sentences with no filler; the verification endpoints are genuinely useful rather than 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?

No output schema exists, so the description carries the return-shape burden and does so fully: it enumerates the event types and clarifies that fingerprints and times (not content) are returned. Nothing an agent needs to invoke or interpret the result 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% and the single owner_ticket parameter is fully documented in the schema. The description only restates that owner_ticket is required, adding no format or syntax detail beyond the 'own_' prefix already in the schema, 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 (Get) and resource (receipts) and enumerates the exact contents: store time, every collection event (proof of delivery), and the terminal outcome (deleted, expired, abuse removal). An agent can immediately tell this apart from the storage/retrieval 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?

Provides clear context on when the tool is usable: after the item is gone, within a 90-day window, free of charge, and gated on the owner_ticket. No alternative sibling offers receipts so explicit when-not guidance is unnecessary, but it stops short of stating the purpose-level use case (auditing/disputes).

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 safety flags; the description adds substantial context beyond them: TTL default 10 min (max 60), collection limits (3 default, max 10), a security warning against relaying secrets, the payment model (profile_key or x402 prepaid), and the exact return fields including owner_ticket.

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-loads the core action and the example code, then layers usage, limits, security, and payment in compact sentences. Slightly dense but every sentence carries decision-relevant information; nothing is padded.

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 7-parameter mutation tool with no output schema, the description covers what an agent needs: when to use it, the alternative for sensitive data, expiry/collection limits, payment handling, and the shape of the return (code, url, say_this, owner_ticket).

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 reinforces key parameter semantics by restating the 10-minute/60-minute and 3/10-collection limits and explaining the receiver-side implications (link previews consuming a collection). It doesn't add syntax beyond the schema, so not a 5.

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+resource+mechanism: hand text or a file to another AI app/session via a short speakable code that is also a URL. It explicitly distinguishes itself from siblings anthill_store (for secrets) and anthill_retrieve (the receiving side).

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 a concrete use case ('a person moving work between AI assistants') and names the alternative with the condition that selects it: 'for sensitive data use anthill_store with encrypt=true instead.' Also explains the receiver path for both connected and unconnected agents.

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 side (readOnlyHint=false, destructiveHint=false), and the description adds meaningful behavior: owner pays by default, encrypted items return locked bytes without a key, large items return download_url instead, and out-of-credit fallbacks (profile_key or x402 with a fee you pay). It doesn't state rate limits or idempotency 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?

Front-loads the core action and scope, then handles edge cases (encryption, large items, payment) in follow-up sentences. Efficient overall, though slightly dense with nested conditionals.

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?

No output schema, and the description compensates by describing the return shape (content text/base64, sha256, signed receipt, download_url). Covers the main retrieval paths and payment fallbacks, though permissions and error conditions aren't detailed.

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 three parameters already carry descriptions. The description adds context around key (unlocked vs locked bytes) and profile_key (only when owner is out of credit, or via header), but doesn't introduce new syntax or format beyond 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 specific verb+resource: pick up an item with a ticket/link/relay code, and names the source siblings (anthill_store, anthill_share). It distinguishes retrieval from the many write-oriented siblings, though it doesn't explicitly contrast with anthill_delete or anthill_receipts.

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?

Implies usage ('no profile needed', 'pass the key to unlock', 'pass your own profile_key if the owner is out of credit'), which tells the agent when certain parameters are needed. However, it gives no explicit when-not-to-use or alternative-tool 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?

Adds real behavioral context beyond the annotations by disclosing that the old key is disabled immediately and that balance and founding status survive the rotation—consequences the hints do not convey. There is mild tension with destructiveHint=false, since the old credential is invalidated, but rotation tools commonly report non-destructive because the account state is preserved.

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?

Three short sentences, front-loaded with the action, followed by the trigger and the state-preservation guarantee. No sentence is 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 mutation tool with no output schema, it covers what changes and what is preserved. It could note that the response carries the new key and that the caller must store it, but no annotations or schema leave an agent unable to call 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 coverage is 100%, so the profile_key format and the Authorization header alternative are already fully documented in the schema. The description adds no parameter-level detail, 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?

States a specific verb and resource—issuing a new secret key and disabling the old one—that no sibling tool performs. An agent can distinguish this from anthill_profile or anthill_create_profile without opening the 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 an explicit trigger condition: "Use this if your key may have leaked." It does not name a when-not case or an alternative recovery path, but the rotation context is unambiguous.

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 is a non-read-only, non-idempotent, non-destructive operation, so the safety profile is covered. The description adds genuinely useful context beyond them: ownership is required, the ticket is billed to the item's owner, and the ticket is scoped as read-only access. It stops short of saying that repeated calls mint additional distinct tickets or what the returned artifact 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?

Two tight sentences, front-loaded with what the tool produces, followed by the requirement and billing consequence. Every clause carries information; nothing is redundant.

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 three-parameter mutation with no output schema, the description covers purpose, precondition, cost attribution, and the optional modes, which is enough to call it correctly. It omits what is returned (a ticket string) and how that ticket is later consumed, which would have made it fully self-contained.

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% (uses, ttl_hours, owner_ticket all documented with formats and bounds), so the schema carries the load and a 3 is the baseline. The description's 'single-use or shorter-lived' phrasing loosely maps to uses/ttl_hours but adds no syntax or constraints beyond what the schema already states.

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 ('Make an extra read ticket for an item you own') and scopes it with 'extra', which separates it from the plain read path. It does not name any sibling (e.g., anthill_retrieve or anthill_extend) or explain how a share ticket differs from a retrieval, so sibling differentiation is left implicit.

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 the essential precondition (the caller must own the item, and the owner_ticket is required) and notes the optional single-use/shorter-lived modes. It offers no when-to-use guidance relative to alternatives such as retrieving directly, extending, or rotating keys, and no exclusions.

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 declare the safety profile (readOnlyHint=false, destructiveHint=false), and the description goes far beyond: it details the payment model (profile balance vs x402 with processing fee), prepaid collections, ticket ownership/visibility rules, key custody for encryption, default and max lifetime, and size limits. This is unusually rich behavioral disclosure consistent with 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?

It is long, but the core purpose and outcome are front-loaded and the remaining paragraphs are dense with distinct, non-redundant facts (payment, tickets, encryption, limits). Every section carries information, though it could be trimmed slightly.

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 9-parameter write tool with no output schema, the description covers the essentials: return values (owner_ticket, read_ticket, view_url, signed receipt), lifetimes, size limits, payment paths, and privacy mechanics. Nothing critical for correct invocation 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 the baseline is 3, but the description adds real meaning: it explains the profile_key vs x402 payment split, clarifies the encrypt vs encrypted distinction, and explains prepaid_collections logic and pricing. It reinforces but also extends what the schema states.

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 immediately states a specific verb and resource ('Drop off text or a file and get claim tickets back') plus the outcome (tickets). It distinguishes itself from retrieval/delete siblings by naming what it produces and who consumes it. An agent can identify the operation without opening the 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?

It gives concrete usage contexts ('hand data to another agent', 'keep something beyond your session') and recipient-specific advice (give view_url to a human). It does not explicitly name sibling alternatives like anthill_retrieve to route the agent, but the when-to-use guidance is clear.

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