Aura

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

Beyond the annotations, the description discloses important behavior: the call blocks, returns the instant a trigger fires, is refunded on timeout, and charges a flat fee while burning zero tokens during the wait. The openWorldHint is consistent with waiting on external events, and readOnlyHint=false is not contradicted given the billing/blocking side effects.

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 well-structured and front-loaded with the core behavior, followed by usage guidance and pricing. Minor redundancy exists between 'burns zero tokens,' the refund statement, and the explicit flat fee line, but overall every section 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?

The description covers triggers, cost, timeout refunds, and when to use the tool. However, there is no output schema and the description does not explain what the tool returns beyond 'returns the instant it happens,' leaving the response payload and timeout outcome ambiguous.

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 schema already documents two of three parameters well, and the description reinforces the trigger categories but adds little semantic detail about timeout_seconds or how extraction works. The pricing/refund context is useful, but parameter-level meaning is mostly left to 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 opens with a concrete action—blocking on an open HTTP connection—and names all four trigger types (email, webhook, signal, deadline). It clearly differentiates await from sibling tools like inbox_read or signal by framing it as a blocking wait rather than a fetch or send operation.

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 an explicit 'When to use' section telling the agent to call this instead of polling in a loop, with concrete scenarios like verification codes, callbacks, and approvals. It does not name sibling alternatives directly or state when not to use it, but the guidance is clear and actionable.

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 needs to convey side effects and cost. It correctly says 'Return' (implying read-only) and labels the call 'Free,' but it does not explicitly state that no state is changed, nor does it mention authentication requirements. The behavioral disclosure is adequate but thin.

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 short and front-loaded with its core purpose. The only inefficiency is repeating 'Free' twice (in the first line and again as 'Price: Free'), which costs a little clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-argument informational tool with no output schema, the description covers what is returned, when to call it, and what it costs. Nothing essential is missing for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The schema is empty and the description adds no parameter meaning, which is appropriate here because there is nothing to describe.

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 ('Return') and a concrete resource ('the full machine-readable manifest of Aura'), listing the manifest contents. It is clear and distinct from other tools, though it never directly names a sibling or contrasts itself with one, so it stops short of the top score.

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 includes an explicit 'When to use' line that tells agents to call this first if they are new to Aura and want to know capabilities and costs. It does not provide when-not-to-use conditions or name alternative tools, which keeps it from 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?

The description adds meaningful behavioral context beyond the annotations: it explains that Aura debits each call off-chain after a one-time deposit, and that the tool is free. It does not contradict the readOnlyHint=false or openWorldHint=false flags, and it provides enough behavioral detail for a payment/deposit tool.

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 well-structured with clear sections: core behavior, when to use, and price. It is slightly repetitive between 'Pay USDC once' and 'you deposit once,' but every section earns its place and the most important guidance is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description is adequately complete: it covers purpose, trigger conditions, mechanics, and cost implications. Some details like refunds or deposit confirmation are absent, but they are not essential for selecting and invoking this tool 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?

The schema already fully documents the single parameter with an enum, default, and description, so the baseline is 3. The description adds practical context with 'A US$1 deposit covers hundreds of operations,' but does not describe the amount_usd parameter itself beyond that.

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 opens with a specific verb and resource: 'Pay USDC once and receive spendable Aura credit.' It clearly distinguishes the deposit action from related operations like memory or inbox tools, and the title 'Top up balance' reinforces the purpose without ambiguity.

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 explicitly states when to call the tool: 'Call when your balance is low, or when a paid call returns 402.' It also provides rationale for the deposit model, explaining that individual calls are 'far too cheap to settle on-chain one at a time,' which guides the agent away from overusing it.

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 indicate a mutating, open-world operation, and the description adds meaningful context beyond them: the URL is public, anyone can POST to it, deliveries become await-able events, and there is a per-call cost. This is useful behavioral disclosure without contradicting 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?

Every sentence earns its place: a clear opening statement of what the tool does, a practical usage condition, and a pricing note. The description is short and front-loaded, with no redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with no output schema, the description conveys the core behavior, the return concept (a public URL), the use case, and cost. It could add retention or deletion behavior, but the essentials an agent needs to call it correctly are present.

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 slug parameter is documented in the schema, but the optional 'description' parameter has no schema description and the tool description does not mention it either. With only 50% schema coverage, the description should compensate for the undocumented parameter, and it does not.

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 ('Mint') and resource ('a public URL'), immediately distinguishing it from reading/list tools and other creation tools. It also explains what happens to deliveries ('become events you can await on'), connecting it to the sibling 'await' tool and making its purpose 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?

The description gives an explicit 'When to use' context: when a third-party service offers a callback and the caller has nowhere to receive it. It does not name alternatives or explicit when-not-to-use conditions, but the guidance is clear enough for an agent to select this tool appropriately.

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?

Since no annotations are provided, the description must disclose behavior itself. It mentions the tool is free, grants a trial credit, and creates a 'permanent' identity, which implies a mutating, persistent operation. However, it does not cover failure modes (e.g., duplicate calls), token expiration or revocation, or the exact nature of the returned token. These gaps are significant for a first-time setup tool, though the permanent nature is stated.

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 concise, with two short paragraphs. It front-loads the core purpose, then adds a 'When to use' section with critical sequencing information, and closes with the price. Every sentence adds value, with no filler or repetition. The structure is clear and scannable.

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 an onboarding tool with no output schema, the description must communicate what the tool returns and how to proceed. It states that a token is returned and needed for other calls, and that an email address is provided. It does not describe the exact response format or error conditions, but given its role as the first call in a workflow, the essential next steps are covered. The absence of an output schema is partially compensated by mentioning the key outputs.

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 each parameter is already well-documented (wallet pattern, message constraints, signature format). The tool description adds no parameter-specific information—it only references the output token and email. Thus, it relies entirely on the schema for parameter meaning, which is adequate but not enhanced.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: converting a wallet address into a permanent agent identity that includes a handle, email, webhook, and API token. The verb 'Turn' and the specific outputs distinguish it from all sibling tools, none of which handle identity creation. The title 'Claim an identity' reinforces the 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?

The description provides explicit usage guidance: 'Call this once, before anything else.' It explains that the returned token is required for every other call and that the email address enables third-party signups. This clearly sets expectations for when to use the tool relative to all siblings, even without naming alternatives.

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 readOnly and openWorld annotations already signal safety and external changes. The description adds value by stating newest-first ordering and the per-call price, plus the hint that polling is more expensive than using await. There is no contradiction 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?

The description is tight and front-loaded: one sentence for the operation, one for when-to-use and alternatives, and one line for price. Every sentence 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 low-complexity read-only list with no output schema, it covers the operation, use case, alternative, and cost. The only real gap is the undocumented return shape and the unaddressed 'from' filter, but the overall description is still sufficient for basic 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 0%, and the description compensates poorly: it never explains 'from', 'limit', or 'unread_only' behavior. While 'limit' and 'unread_only' are fairly self-explanatory from their names/defaults, 'from' is ambiguous and no clarification is provided.

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 opens with a concrete action and scope: 'List messages delivered to your Aura email address, newest first.' The verb 'List' and the target 'messages' make the operation unmistakable and differentiate it from the sibling 'inbox_read'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a specific trigger ('Call after signing up somewhere, to see what arrived') and explicitly steers blocking use cases to a named sibling: 'use await instead — it is far cheaper than polling this.' This is clear when-to-use and alternative guidance.

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

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

With readOnlyHint and openWorldHint already present, the description adds value by specifying the return content (parsed body, verification codes, confirmation links) and disclosing the per-call price. It does not contradict the annotations, and its additional details are honest and 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?

Three short sentences, with the operative behavior first, usage guidance second, and cost last. There is no filler or redundant restatement of the 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?

For a one-parameter read operation with read-only annotations and no output schema, the description covers the id source, return value, usage context, and cost. It could mention behavior for nonexistent ids, but that is a minor omission for this level of complexity.

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 schema exposes only a generic id string, and schema description coverage is 0%. The description compensates by stating that the id comes from inbox.list, which gives the parameter concrete origin and meaning. A sample or format would strengthen it further, but the essential semantic is present.

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 opens with 'Return the full parsed body of one message, plus any verification code or confirmation link found in it,' a specific verb-resource pair that clearly distinguishes reading a single message from listing the inbox. It also references the sibling inbox.list, reinforcing the conceptual separation.

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?

An explicit 'When to use' section tells the agent to call with an id from inbox.list whenever full text or a link is needed. It gives clear contextual conditions, though it does not spell out when not to use the tool or name alternatives.

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=false, so the mutation behavior is known. The description adds 'Free' and 'keeping your own state tidy', which are motivational rather than behavioral. It doesn't contradict annotations but adds little beyond what the schema and annotations already convey.

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 short and action-oriented, front-loading the core purpose. However, the 'Free' aspect is mentioned twice ('Free — keeping...' and 'Price: Free'), which is redundant. The structure is clean with clear sections, but the redundancy detracts 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 simple one-parameter delete tool, the description covers the action, usage, and pricing. It doesn't describe return values or side effects, but given the simplicity and annotations, nothing critical is missing. It is complete enough for an agent to use 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%, so the description must compensate. It only mentions 'key' implicitly as the stored item to delete, providing minimal meaning about what the key represents. It doesn't explain format, constraints, or how to identify a valid key. The description adds little beyond the schema's type definition.

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 the verb 'Delete' and the resource 'a stored key', making the tool's purpose immediately clear. It distinguishes from siblings like memory_get, memory_set, and memory_search by specifying the delete action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear usage condition: 'Call when a stored fact is stale or wrong.' It does not explicitly mention when not to use it or name alternatives, but the context is clear enough to guide an agent. This meets the 'clear context, no exclusions' level.

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 and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: exact match only (no partial lookup), the requirement that the key must have been previously written, and an explicit price per call. No contradiction with 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 sections with zero filler: purpose first, then usage guidance, then cost. Every sentence earns its place and the most important scoping claim is front-loaded.

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-only tool, the description covers purpose, when to use, the correct sibling alternative, and cost. Return format remains unspecified, but readOnlyHint plus the simple retrieval semantics make the call safe and predictable without it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does: 'exact key' adds match semantics and 'the key you wrote earlier' ties the parameter to a prior memory_set call. The schema only provides type and length constraints, so the description meaningfully enriches the meaning of the single parameter.

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 opens with a specific verb+resource statement: 'Fetch one stored value by its exact key,' which clearly scopes the operation to exact-key retrieval of a single value. The title 'Recall by key' reinforces this, and the usage line explicitly contrasts it with memory.search so an agent can distinguish the 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?

The 'When to use' line gives an explicit condition ('when you know the key you wrote earlier') and names the alternative (memory.search) with a reason to prefer this tool ('Cheaper and more precise'). This tells the agent not just when, but why to select it over a sibling.

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 readOnlyHint annotation already covers safety; the description adds the useful behavioral detail that values are not returned and that metadata is included. It does not describe pagination, metadata fields, or ordering, so it adds moderate but not rich behavioral context.

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 sections carry exactly the necessary information: what the tool returns, when to use it, and cost. The main behavior is front-loaded, and there is no redundant wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list operation with two optional parameters, the description sufficiently covers purpose, usage context, and value-exclusion behavior. It omits the exact metadata fields and any pagination behavior, but the low complexity and readOnlyHint make the definition adequate.

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 description does not explain how 'limit' or 'prefix' affect the result. The parameter names and schema constraints are self-evident, but the description provides no additional meaning to compensate for the missing schema descriptions.

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 precise operation: listing stored keys with metadata and explicitly excluding values. This distinguishes it from sibling tools like memory_get and memory_search, which fetch content rather than an inventory.

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?

'When to use: Call to see what you already know before deciding what to fetch' gives clear situational guidance aligned with the read-only inventory purpose. It implies the alternative of fetching values, though it does not explicitly name memory_get or memory_search as the tools for that.

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 and destructiveHint=false, so the read-only safety is covered. The description adds behavioral context beyond that: the search is meaning-based rather than key-based, and it surfaces the per-call price. It doesn't detail result ordering or error behavior, but the essential behavior is disclosed.

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, each earning its place: purpose, usage condition, and price. The primary purpose is front-loaded, and there is no redundant or filler content.

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 search tool with three parameters and no output schema, the description covers purpose and when-to-use but omits the meaning of tag and limit, and doesn't describe the return format. The annotations cover safety, so this is a moderate gap rather than a critical one.

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 low: only q has a description ('Natural-language description of what you are looking for.'), while tag and limit lack semantic descriptions. The tool description does not mention tag or limit at all, so it fails to compensate for the coverage gap. It only reinforces the q parameter via the 'by meaning' phrase.

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 opens with a specific verb and resource: 'Find stored memories by meaning rather than by exact key.' This distinguishes memory_search from memory_get (exact key) and memory_list (listing all) with a clear semantic scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides an explicit when-to-use condition: 'Call when you remember roughly what you stored but not the key you used.' It doesn't name alternatives or when-not-to-use cases, but the condition implies the distinction from key-based lookup.

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 description adds durability context beyond annotations: 'Survives your process dying' and the wallet-bound nature clarify persistence semantics. It also discloses the cost per call. The schema already notes overwrite behavior, so the description need not repeat it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is compact, front-loaded with the core purpose, and every sentence adds value: durability, when-to-use context, and pricing. No filler or redundant restatement of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low annotation richness and absence of an output schema, the description covers the key decision-relevant aspects: what it stores, how long it persists, when to use it, and what it costs. It does not describe the response shape or mention that deleting requires memory_delete, but those are minor for a simple write tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is high at 75%, with key, value, and ttl_seconds already explained in the schema. The description itself adds no parameter-level detail beyond 'durable key/value fact', 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 description states a clear verb and resource: 'Store a durable key/value fact bound to your wallet.' This distinguishes it from sibling tools like memory_get and memory_delete by intent and persistence. The title 'Remember something' is vague, but the description carries the definition adequately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit 'When to use' section with concrete examples such as decisions, credentials, user preferences, and task progress. It does not mention when not to use it or name alternatives, so it falls short of full exclusions 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?

Even with annotations present, the description adds meaningful behavioral context: the current process terminates, Aura holds the state and watches the condition, the state is returned byte-identical on resume, and a callback POST is optional. It does not disclose expiration behavior or the immediate return contract, but it goes well beyond the minimal annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: core behavior first, then usage guidance, then cost. Every sentence earns its place, and the critical safety/persistence semantics are front-loaded. No filler or redundant schema repetition.

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?

The nested `on` schema is complex, and while the description gives a solid high-level mental model, it omits important operational details for an agent invoking the tool: how the park call's response enables the later `resume`, and what happens when `expires_in_hours` passes. There is no output schema to fill this gap, so the description is adequate but not fully 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 description coverage is 80%, so the schema already carries most parameter meaning. The description adds a little context around state preservation and the callback, but it mostly restates what the schema says and does not clarify `expires_in_hours`, which lacks a schema description. This matches the high-coverage baseline of 3.

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-plus-resource ('park state and exit') and precisely distinguishes the tool from the sibling `resume` by framing park as the handoff that is later resumed. It also clarifies the asynchronous wake-condition model rather than just restating the title.

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 'When to use' paragraph gives explicit context: use when the wait outlasts the process, such as hours/days or an approval landing tomorrow, and frames it as cheaper/safer than staying alive. It does not name explicit alternatives or exclusions like 'use await for short waits,' so it falls just 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?

Beyond the annotations, the description discloses that the call is free when nothing is ready, costs US$0.002 per call when it returns work, and blocks until resolution without consuming tokens while waiting. This is valuable behavioral context not present in the annotations. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized into clear sections with purposeful detail. There is a slight redundancy between 'costs you nothing until it actually hands work back' and the later Price section, but each adds a distinct nuance, so the length is justified.

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?

Even without an output schema, the description names the return payload: the original state and the event that woke it. It also covers invocation timing, empty-state behavior, cost, and blocking semantics. Nothing needed to call the tool correctly appears to be 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 both parameters already have descriptive text in the schema: park_id explains omission semantics ('oldest ready one') and wait_seconds explains optional blocking. The description does not add new parameter-level meaning, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Claim state from a park whose trigger has fired.' It also states the return value (original state and waking event), which clearly differentiates this from sibling tools like park.

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 explicit usage timing: 'Call at the START of every run.' It explains what happens when no work is ready, which helps an agent decide when to call. It does not explicitly describe when not to use it or name alternatives, but the context is sufficiently clear.

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

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

Annotations already mark it non-read-only and open-world; the description adds that the message is sent by handle, the recipient can await on it, and each call costs US$0.002000. It does not cover delivery guarantees or unknown-handle behavior, but the essential side effect is clear.

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, purposeful sentences in a front-loaded structure: core action, when-to-use, and price. There is no redundant wording and every line 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?

Provides the purpose, coordination use case, recipient-await behavior, and cost, which is enough for an agent to select and invoke it. With no output schema, it does not describe the return value or failure semantics, but those are secondary for a simple signal-sending 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?

The description clarifies 'to' as a handle and 'name' as a filterable signal name, and implies payload is the JSON body. However, payload semantics remain generic, and the description does not add much beyond the schema's object type, especially given 67% schema coverage.

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'), object ('named JSON message'), and recipient ('another Aura agent by handle'), and ties it to the await sibling with 'They can await on it.' This clearly distinguishes it from local memory, inbox, or hook 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?

Provides an explicit 'When to use' section: call it to hand work to or coordinate with another agent without shared infrastructure. It lacks named alternatives or 'do not use when' conditions, so it is clear but not exhaustive.

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, so the safety profile is covered. The description adds that the call is free and returns balance/quota info, which is useful context beyond the annotation, but it doesn't mention details like rate limits or whether the returned balance is cached. Given the annotation coverage, a 3 is appropriate.

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 short and front-loaded with the return value list. The only waste is the duplicate 'Free' mention: 'Free.' appears as its own sentence and again under 'Price: Free.' This is minor redundancy, not enough to drop below 4.

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 tool, this description is complete. It names all the important return fields, states that it is free, and gives a clear trigger condition. No output schema exists, so the description's list of returned data adequately covers what an agent needs to know.

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 the baseline is 4. The description doesn't need to explain parameters, and it doesn't introduce any confusion about arguments. It focuses on return values, which is 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 uses a specific verb ('Return') and names the exact resources returned: handle, email address, webhook base URL, balance, and quota usage. This clearly differentiates it from siblings like identity_create (creation) and credit_deposit (balance top-up).

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 an explicit 'When to use' section telling the agent to call when it needs its own email address or needs to check balance before spending. It doesn't name alternatives, but the tool's purpose is self-evident and the context provided is clear enough.

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