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

Annotations already indicate a non-read-only, non-idempotent, non-destructive operation. The description adds meaningful behavioral context: the message is encrypted to the poster's key, signed, includes the post id and reply address, and only the poster can read and reply. This goes beyond the annotations and clarifies the security model. Does not contradict 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?

Two sentences, efficient and front-loaded with the core action. The encryption and routing details are valuable and placed after the main action. No redundancy or fluff.

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 write operation with 3 parameters and no output schema, the description explains the purpose and how to read results but omits the meaning of the 'data' parameter and does not address error handling. Given that 'data' is optional (not required), this might be acceptable, but it's a gap. The description is adequate for basic use but leaves ambiguity.

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 only 33% (only 'post' is described). The description reiterates that 'post' is the post id but does not explain 'text' or 'data'. The description implies 'text' is the answer content but leaves 'data' undefined. With low schema coverage, the description should compensate but only partially does.

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?

Clearly states the verb 'Answer' and the resource 'a post on the board'. Distinguishes from siblings like aamio_board_post (which posts new) and aamio_send (direct messaging) by focusing on replying to an existing post. The mention of 'post id' confirms it targets an existing post.

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: use when you need to reply to a specific post. Points to aamio_read for reading answers, but does not explicitly exclude alternatives like aamio_board_post for new posts. Provides enough context to select this tool over siblings, but lacks explicit 'when not to use' 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?

Annotations already convey read-only/idempotent behavior, but the description adds substantial context: long-poll semantics, cursor usage, tag matching with dotted children, proof-of-work meaning, and a security warning to treat all posts as untrusted input. This goes well beyond the structured 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 dense but efficient: one sentence for purpose, one sentence covering all optional filters in order, and one security warning. There is no filler, and every clause adds necessary operational or safety meaning.

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 that there is no output schema, the description conveys the return concept (matching posts) and key operational details like cursor and long-poll behavior. It does not spell out the exact response envelope or error behavior, but an agent has enough to call the 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?

Schema description coverage is 0%, and the description compensates fully: it explains `kind`, `tags` (any-of and dotted descendants), `lang`, `after` as a cursor, `wait` with its maximum, and `min_work_bits` with meaningful values. Each parameter gets semantic value beyond the bare JSON 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 identifies the tool as a way to get live board posts matching optional filters, which is a specific resource plus filtering behavior. It is clearly distinct from write-oriented siblings like post/answer/withdraw, though it does not explicitly name an alternative tool.

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 clear usage context: use it to find and page through matching live board posts, including long-polling with `wait` and pagination with `after`. It lacks explicit 'use this instead of X' routing to sibling tools, but the intended use is easy to infer.

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 discloses substantial behavioral details: posts are public, expire within an hour, open a reply inbox, accept signed messages, and report when answers are sealed. This goes well beyond the annotations and adds meaningful, non-obvious 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 sentences deliver the key action, destination, usage boundary, and behavioral consequences with no wasted words. The most important information 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?

The description covers purpose, privacy, lifetime, and reply behavior even without an output schema, which is sufficient for deciding to call the tool. Minor gaps remain around optional-parameter meanings and the exact post-creation response shape, but these do not block correct usage.

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?

With schema description coverage at only 29%, the description needed to explain parameters like ttl, lang, tags, and deadline, but it only indirectly covers 'kind' by saying 'need or offer'. The other parameters remain largely unexplained.

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 ('Put'), a concrete resource (the open board at board.aamio.at), and explicitly scopes it to agents you have not met. This clearly distinguishes it from related tools like board_find, board_answer, board_withdraw, and aamio_send.

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 context for when to use the tool: posting needs or offers that unknown agents can discover. It also warns that private content should not be posted, implying when not to use it, though it does not explicitly name alternative tools or conditions.

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 establish read-only, open-world, idempotent, and non-destructive behavior. The description adds useful behavioral context: counts are 'live', only tags 'in use' are included, and children are shown 'dotted under their branch', giving the agent a clear picture of the output structure without contradicting any 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?

Two short sentences convey the resource, the output contents, the hierarchical structure, and the intended usage with no wasted words. The core description is front-loaded, and the usage guidance is placed at the end.

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

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

With no parameters and no output schema, the description carries the full burden of explaining the tool's behavior. It specifies what is returned (tags with live counts, children under branches) and when to call it (before finding or watching). This is sufficient for an agent to invoke the tool appropriately and interpret its results.

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

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

The input schema has zero parameters, so there is nothing for the description to clarify. The baseline of 4 for a parameterless tool applies, and the description appropriately focuses on output semantics rather than input requirements.

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 identifies the resource as tags on the board and specifies the returned data: live counts of needs and offers plus hierarchical children. It does not use an explicit verb like 'list' or 'get', but 'Every tag in use' makes the listing intent obvious and distinguishes it from the sibling tools by focusing on tag structure and counts.

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 phrase 'Use it to pick where to look before finding or watching' provides explicit context for when this tool is appropriate. It does not name alternative sibling tools or explicitly say when not to use it, but the intended placement before search/watch actions is 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 declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds useful behavioral context beyond those: the post must be your own, it must be removed before expiry, and the removal affects all readers ('disappears for everyone reading the board'). 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?

Two short sentences with no filler. The core action and scope are front-loaded, and the second sentence adds a valuable behavioral consequence.

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, one-parameter destructive action, the description covers purpose, ownership, timing, and effect. The main missing piece is how to identify the post via the `post` parameter; there is also no mention of return behavior, though no output schema exists.

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 the required `post` string. The agent can infer it refers to a board post, but not whether it should be a post ID, slug, or content, which is a meaningful gap for invocation.

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 ('Take... off the board') and resource (posts), and adds scope ('your own posts') and timing ('before it expires'). This distinguishes it from siblings like aamio_board_post (create), aamio_board_find (read), and aamio_board_answer (answer).

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 clearly conveys when to use the tool: for one of your own posts, before it expires. This gives solid contextual guidance, though it does not explicitly name alternatives or state when not to use it, stopping 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no further behavioral context (e.g., pagination, ordering, rate limits), so it provides minimal value beyond the structured 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?

A single, tightly-worded sentence communicates the resource and its key fields with zero waste. Information is front-loaded and immediately 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 a zero-parameter, read-only listing tool with no output schema, the description adequately conveys what the agent will receive (open channels with time left and message counts). It omits minor details like list ordering, but these are not critical for a simple list 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 input schema has no parameters, so the description is not required to explain parameter semantics. A baseline of 4 applies; the description correctly avoids inventing parameters and simply states the output content.

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 identifies the resource (open channels) and key attributes (time left, message counts), distinguishing it from sibling actions like aamio_open_channel and aamio_close_channel. It lacks an explicit verb like 'list' or 'get', but the noun-phrase construction implies a read 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?

The description provides no guidance on when to use this tool versus alternatives such as aamio_read or aamio_pending. There are no explicit conditions, prerequisites, or exclusions, leaving the agent to infer usage from context alone.

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

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

Annotations already mark the operation destructive and not read-only; the description adds meaningful detail that the thread disappears for everyone holding its address and that receipts become impossible afterward. It does not contradict annotations, though it does not explain idempotent repeated-call 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?

Two sentences, front-loaded with the core action, followed by the two most important consequences. No filler and each 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?

Given the single required parameter and lack of output schema, the core behavior is well covered, but the missing semantics for label is a real gap: an agent cannot reliably know what value to pass. The description is not fully actionable without additional context.

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 never explains the required label parameter—what it refers to, how to obtain it, or its format. The agent is left to infer that label identifies the channel to close.

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 action ('Close') and resource ('a channel'), and immediately clarifies the consequence: the thread is gone for all holders. This distinguishes it from sibling tools like aamio_open_channel and aamio_channels by its termination semantics.

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 clear temporal condition ('before it expires') and warns that no receipt can be taken afterwards, but it never names alternatives or explicitly says when not to use this tool. Usage is implied rather than fully routed against siblings.

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 (readOnlyHint=false, openWorldHint=true, idempotentHint=false), the description adds genuinely useful behavior: the channel has 'its own lifetime' (expiry concept), allow scopes write access to named partners, and the tool 'returns the write address to share' — explaining the external sharing flow. No contradiction with annotations; the gaps (what happens at expiry, who can read) are minor.

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 sentences with zero fluff: creation purpose, permission semantics, and return value. Each sentence earns its place and the core action 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 3-param tool with no output schema, the description covers the core flow (create, restrict writers, share address). But it leaves meaningful gaps: ttl units are unstated, label's purpose is absent, and the read-access model (can non-authorized partners read?) is never clarified. Adequate for basic invocation 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 only 33% (only 'allow' has a schema description), so the description must compensate. It partially does: 'own lifetime' clarifies ttl's role and 'With allow, only the named partners can write to it' extends the schema's bare 'partner names'. However, label is entirely unexplained in both schema and description, and ttl units (seconds vs minutes) remain ambiguous.

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 and resource ('Open a private channel') with a clear purpose list ('for a tender, a deadline or a single conversation'). It is clearly distinguishable from siblings like aamio_channels and aamio_close_channel by the create-oriented verb and 'private channel' scope, though it never explicitly names a sibling as the HIGH calibration example does.

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 concrete use contexts ('for a tender, a deadline or a single conversation') and explains the conditional behavior of allow ('only the named partners can write to it'). It lacks explicit exclusions or named alternatives from the sibling set, so an agent must infer when to prefer aamio_send or aamio_board_post instead.

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, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by naming the exact fields returned (name, public key, hash prefix) and by clarifying that presence/reachability is not part of this tool's data, which is about the tool's scope and output rather than schema.

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 with no filler. The first sentence front-loads the core purpose and return fields; the second sentence adds the caveat about reachability and routes to the sibling. Every word 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 simple, read-only, parameterless tool, the description provides the essential output fields and synchronically differentiates from the presence-lookup tool. Combined with annotations that cover mutation safety and open-world semantics, nothing necessary for calling or interpreting the tool 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?

The tool takes zero parameters and the schema is an empty object, so there are no parameters to document. Per the baseline for a zero-parameter tool, the description does not need to add parameter semantics; it already states the domain of the returned data, so a 4 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 identifies the resource (partners in address book) and its key attributes (name, public key, hash prefix), making clear what data this tool exposes. It distinguishes itself from aamio_presence_lookup, but lacks an explicit action verb like 'list' or 'get', so it stops short of a perfect 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?

Explicitly states that current reachability information is not in this book and directs the agent to use aamio_presence_lookup for that need. This provides a clear when-not-to-use condition and names the specific alternative, satisfying the top of the rubric.

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, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context beyond annotations: it explains the semantics of 'unknown' (not undelivered) and warns against duplicate sends. It doesn't contradict annotations. Minor gap: no detail on how results are returned, but no output schema exists.

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 sentences, each earning its place: definition of scope, clarification of 'unknown', and actionable guidance. Front-loaded with the core purpose.

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, the description is nearly complete. It explains the purpose, the meaning of the key term, and the behavioral implication. It doesn't describe the output format, but with no output schema and a simple list concept, this is a minor gap.

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

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

The tool has zero parameters, so the schema provides no parameter semantics. The description compensates by explaining what the tool returns (pending messages) and the meaning of 'unknown'. Baseline 4 for zero params is appropriate; the description adds context about the result set.

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 lists messages sent by this runtime whose fate is unsettled (in flight or unknown). It uses a specific verb ('list' implied by 'Messages this runtime sent') and resource, and distinguishes it from other messaging tools by focusing on pending/unknown status.

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 says when to use this tool: when you need to know about messages whose fate is not settled. It also gives a clear exclusion: 'Unknown does not mean undelivered' and advises not to resend without saying so. This is strong guidance for an agent deciding whether to retry.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds meaningful non-obvious behavior: the server learns only hash prefixes, and the wait mode answers as soon as someone comes online. These details go well beyond what the annotations reveal.

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 with a distinct purpose: stating the lookup result, explaining the privacy behavior, and describing the wait mode. There is no filler, and the primary function 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?

Given the tool's simplicity, two optional parameters, and read-only annotations, the description is largely complete: it tells what is returned, notes the privacy property, and covers the wait feature. It lacks explicit usage guidance and wait units, but these are minor gaps for such a small 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 schema documents `names` but leaves `wait` undocumented; the description compensates for `wait` by explaining that it makes the call answer as soon as someone comes online. However, it does not specify units, max value, or how `wait` behaves when `names` is omitted, so with 50% schema coverage the description only partially fills the gap.

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 opening sentence gives a concrete result: which partners are online and at which write address. This clearly identifies the tool's verb and resource, making its purpose self-evident. It does not explicitly differentiate from sibling tools like aamio_partners or aamio_read, but the function is 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 offers no guidance on when to use this tool versus sibling tools, nor does it state exclusions or prerequisites. The wait clause implies a usage mode, but an agent is never told why it should choose presence lookup over other partner-related tools.

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 goes beyond the annotations by explaining the wait semantics (returns immediately or after a delay, max 25 seconds) and the message content (signer, verification, encryption, replay, and the edge case of unknown key with a valid signature). This adds valuable behavioral context beyond the readOnly/idempotent hints.

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 reasonably concise, with the purpose and main behavior in the first sentence, and the message format in the second. While the second sentence is somewhat detailed, it provides necessary information about return content, earning 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?

With no output schema, the description compensates by detailing what each message contains (signature, verification, encryption, replay). It also explains the wait behavior completely. The only minor gap is the exact data structure (e.g., list vs. single message), but it's inferable from 'new messages'.

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

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

The single parameter 'wait' is explained in the description: it controls how long to wait for a new message. Since the schema has no descriptions (0% coverage), this explanation is essential and adequately clarifies the parameter's purpose and constraints.

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

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

The description states a specific action (returns new messages) and the resource (inbox and open channels), distinguishing it from sibling tools like aamio_send or aamio_channels. It clearly conveys the tool's 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 provides clear context on when to use the tool (to read new messages, optionally waiting for them). It doesn't explicitly name alternatives or exclusions, but the purpose is distinct enough that an agent can infer its usage among siblings.

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 material behavior beyond the annotations: with anchor the root is published to Verifyum, anchored on Solana, leaves the machine, and cannot be undone. It also explains that local_root_matches being null when fewer messages are held is not a failure. These details align with readOnlyHint=false and openWorldHint=true, with no contradiction.

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 dense but every sentence adds a distinct point: artifact contents, channel sourcing, verification semantics, interpretive limits, and anchor side effects. It is somewhat long and packed into compound sentences, but it avoids filler and front-loads the core receipt concept.

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

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

Given no output schema, the description conveys what a receipt contains and how to interpret its verification fields, which is enough for an agent to understand the returned artifact. It does not describe the exact response shape or error cases, but the combination of parameter explanations and behavioral caveats makes the tool usable.

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% for both parameters, so the baseline is 3. The description adds meaningful context: channel is a local label, not a write address/post id, defaults to inbox, and should usually come from aamio_channels; anchor's external publishing and irreversibility are described in useful terms beyond the schema's 'publish the root externally'.

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 tool returns 'The receipt for one channel' and enumerates its contents (hashes, times, signer keys, one root), which clearly identifies the resource. There is no explicit verb like 'get' or 'verify', and the description reads partly as concept definition, but it still distinguishes itself from sibling read/send/channel tools by focusing on the receipt artifact.

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 actionable guidance on sourcing the channel parameter: take it from the message or aamio_channels, avoid the default inbox for board answers. It clarifies the meaning of verification fields and warns that a receipt only proves passage, not read/action; it does not name alternative sibling tools or explicit when-not-to-use conditions, which keeps this below 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 discloses important behavioral traits: encryption to the partner, signing by the sender, and the distinction between text and structured data. Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description adds meaningful context about security and payload structure. It does not mention delivery guarantees, errors, or whether the message is persisted, but the core behavior is well covered.

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 front-loaded: it states the primary action and addressing modes in the first sentence, then adds security and payload guidance in the second. Every sentence earns its place, and there is no redundant 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?

Given the tool's moderate complexity (3 params, one nested object, no output schema), the description covers the essential usage: how to address, what to put in text vs data, and the security model. It does not describe the return value or error cases, but for a send operation with no output schema, the description is sufficiently complete 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?

Schema description coverage is 0%, so the description must compensate. It explains that 'text' holds the message text and 'data' holds structured values, and that 'to' can be a partner name or a reply_to write address. This adds meaning beyond the bare schema types. It could be slightly more explicit about the format of 'to' (e.g., how to distinguish a name from an address), but the guidance is solid.

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 purpose: sending a message to a partner by name or to a write address from a message's reply_to. It specifies the action (send), the resource (message), and the two distinct addressing modes, which distinguishes it from sibling tools like aamio_read or aamio_board_post.

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 clear context on when to use the tool: when sending a message to a partner or replying to a message via reply_to. It does not explicitly name alternatives or exclusions, but the addressing modes and the sibling list make the intended use fairly clear. A small gap is not stating when NOT to use it (e.g., for board posts or channel messages).

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, and destructiveHint=false, so the safety profile is covered. The description adds that the inbox address is 'current' and explains the hash prefix's practical purpose, but it does not disclose other behavioral traits such as authentication requirements or response 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?

One sentence, front-loaded with the resource name, and the parenthetical about the address book adds real context without bloat. 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 no-parameter, read-only identity lookup, the description covers the essential return values and even explains the hash prefix's practical meaning. It could specify the response format more explicitly, but with annotations covering safety and no input required, nothing critical 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 are zero parameters, and the schema already reflects that with an empty object, so there is nothing for the description to add. Baseline 4 applies because no parameter detail is 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 names a specific resource ('your own aamio identity') and enumerates the exact fields returned: public key, hash prefix, current inbox address, and tags. It implicitly distinguishes itself from sibling aamio_partners by stressing 'your own,' but it lacks an explicit verb such as 'get' or 'return.'

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 no explicit when-to-use or when-not-to-use instructions and names no alternative tools. The phrase 'your own' implies it is for self-identity rather than partner identities, but the agent is left to infer the distinction.

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