dearhuman

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

With no annotations, the description carries the full behavioral burden. It usefully enumerates possible statuses (pending, approved, paid with tx, rejected with reason), which clarifies what 'status' means. However, it does not mention behavior for invalid/unfound claim IDs, authentication, or whether the operation is read-only.

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 extremely concise, using a single line with no fluff. The status list is front-loaded and easy to parse. However, it is a fragment rather than a complete sentence, which slightly reduces clarity, but overall it is well-structured for its length.

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 single-parameter read tool with no output schema, the description provides the key return states, which is important. Yet it does not mention how the claim_id should be sourced (e.g., from submit_bounty), the expected response structure beyond status enumeration, or error conditions. It is minimally viable but has clear gaps.

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 adds no meaning to the sole parameter claim_id. It does not explain what the claim_id represents, its format, or how to obtain it. The description completely relies on the schema, which only provides the name and type, so it fails to compensate for the missing parameter documentation.

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 'Status of a bounty claim' clearly identifies the resource (bounty claim) and the operation (status check), even though it is phrased as a noun phrase rather than a full verb sentence. It is distinct from siblings like get_bounties and submit_bounty, though it doesn't explicitly state that distinction.

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?

No guidance is provided about when to use this tool versus alternatives. Since sibling tools include get_bounties and submit_bounty, an agent could benefit from a note like 'after submitting a claim, use this to check its status.' The description lacks any usage context or exclusions.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It reveals that bounties are paid in USDC on Base, are human-reviewed, paid claims are public on /ledger with tx hashes, and that rules/payload formats are included. This is meaningful context beyond a simple 'get' operation.

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 with the core purpose ('EARN: open bounties'), followed by payment details and a helpful pointer to documentation. The 'EARN:' prefix is slightly stylistic but not wasteful.

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 provides enough context for an agent to decide to call the tool and know what kind of information to expect: amounts, payload formats, rules, and verification via the ledger. It wisely defers detailed rules to /docs/bounties, which is reasonable given the lack of parameters and output schema.

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 and schema description coverage is effectively 100%, so there are no parameter semantics to clarify. Baseline 4 applies because there is nothing the description needs to add.

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 open bounties that Dear Human pays agents for, with amounts, payload formats, and rules. It distinguishes itself from related siblings like submit_bounty and check_bounty_claim by emphasizing 'open' bounties, though it lacks an explicit verb like 'list' or 'retrieve'.

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

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

The description implies use when an agent wants to see available paid bounties, and instructs reading /docs/bounties first. It does not explicitly state when not to use this tool or mention alternatives such as check_bounty_claim or submit_bounty.

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

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

No annotations are provided, so the description carries the full burden. The verb 'List' makes the read-only, non-destructive behavior clear, and all allowed filter values are disclosed. However, it does not describe the return format or any pagination behavior, which would further enhance transparency.

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

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

The description is a single, front-loaded sentence with no wasted words. Every element adds value: the action, the resource, and the explicit filter values.

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 list tool with one optional parameter and no output schema, the description adequately conveys the action and filter values. It could further specify the default behavior when no occasion is provided (implied but not stated) or whether the result is sorted, but these are minor gaps for this simplicity level.

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 for the parameter 'occasion'. It fully compensates by enumerating all acceptable values in parentheses, providing meaning that the bare string schema (with default '') lacks. This is a strong addition.

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 the specific verb 'List' with the clear resource 'card templates' and an optional filter by occasion. It distinguishes itself from sibling tools like get_offers and get_phrases, and the parenthetical list of occasions adds specificity.

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 clearly indicates when to use the tool (to list templates) and provides the valid occasion filter values, which gives practical usage context. It does not explicitly mention alternatives or exclusion cases, but sibling tools are clearly different in purpose.

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

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

With no annotations, the description carries the full burden. It discloses a meaningful privacy behavior ('their data never leaves you') and implies a read-only list operation, but it does not mention other aspects like authentication, rate limits, or side effects. For a simple list tool, this is adequate but not exhaustive; the description adds some context beyond the obvious.

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 two concise sentences: the first states the action, the second provides actionable guidance and a privacy note. Every part earns its place with no fluff or redundancy.

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 parameterless tool with no output schema, the description adequately explains what the tool does and how to apply the results. It could explicitly mention that it returns a list of offers, but that is implied by 'List the gift-offer shelf.' The guidance on selection and privacy adds useful 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?

There are zero parameters, so the description cannot add parameter semantics. The baseline of 4 is appropriate because the schema already covers everything (trivially, since there are no inputs), and the description need not explain anything about inputs.

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 'the gift-offer shelf', using a specific verb (list) and resource (gift offers), which distinguishes it from sibling tools like card templates or phrases. The additional instruction about selecting an offer reinforces its role in the gift-giving workflow, making the 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?

It provides clear guidance on how to use the output (e.g., 'Pick the one offer... match on what you already know about them'), which tells the agent what to do with the results. It doesn't explicitly state when to use this tool versus alternatives, but the distinct resource type (offers) implicitly differentiates it from siblings. The privacy note also adds context on how to approach selection.

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 provided, the description carries the full transparency burden. It discloses that this is a list operation, explains the three register modes including the self_only ownership caveat, and clarifies the selection-based composition model. It does not detail return shape or pagination, but for a simple list tool this is a minor gap.

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 and well-structured: three short sentences cover purpose, parameter semantics, and usage rule. It is front-loaded with the primary action and contains no filler.

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

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

For a read-only list tool with two optional parameters and no output schema, the description covers all essential aspects: what is listed, filters, register meanings, and how results are consumed. It could be more explicit about the returned fields, but the comment about picking phrase IDs makes the output shape sufficiently clear.

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 is the only source of parameter meaning. It fully defines 'register' with its default and all values ('plain', 'lore', 'all'), explains 'occasion' as an optional filter, and ties the output to phrase IDs for card composition. This completely compensates for the bare 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 specific verb+resource: 'List the selectable phrase library (and sign-offs)', and mentions optional occasion filtering. This clearly distinguishes it from sibling tools like get_card_templates, get_offers, and get_todays_holidays by naming the phrase library as its unique resource.

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 practical usage context: the register explanation recommends 'plain' for most recipients, and the final sentence clarifies that cards are composed by selecting phrase IDs rather than writing text. This signals when to use the tool in the workflow, though it does not explicitly name alternatives or exclusions.

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

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

Since no annotations are provided, the description carries the transparency burden. It communicates a lighthearted read-only lookup and a selection rule, but it does not say whether the result is one holiday or many, what format the result takes, or how 'today' is resolved.

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, each earning its place: the first states the resource, the second gives the selection behavior. It is concise, front-loaded, and free of repetitive 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 that the tool has zero parameters and trivial input complexity, the description is almost complete for selection and invocation. It would be more complete if it explicitly stated the output shape or that it can return multiple holidays, but the light context still gives enough for a simple lookup.

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 is empty, so there are no parameters for the description to clarify. This is the zero-parameter baseline case; the description does not need to add parameter-level detail.

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 ('today's micro-holiday') and makes the purpose understandable, especially combined with the tool name. It is clearly distinct from sibling tools like get_card_templates, preview_card, and send_card, though it does not use an explicit verb like 'retrieve'.

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 implied use case: finding a whimsical holiday the human would enjoy, and the second sentence gives a clear 'choose one' instruction. However, it does not explicitly explain when to prefer this over the other sibling tools or when not to use 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?

With no annotations, the description carries the burden. It clearly discloses that this is non-destructive ('without creating anything') and echoes text back, which is important behavioral context. However, it doesn't specify error behavior or output structure, which would be more thorough.

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, no fluff, directly states purpose and behavior. Highly concise.

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

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

Covers the basic purpose and non-destructive nature, but lacks details on output format, error handling, and parameter specifics. Given 6 parameters and no output schema, it could be more 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 0%, and the description doesn't explain any parameters beyond 'every ID'. It doesn't add meaning to template_id, phrase_ids, offer_id, holiday_id, or occasion. The description must compensate for the lack of schema annotations but 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 clearly states the tool's purpose: it performs a dry-run of a card composition, validates IDs, and echoes back assembled text. The verb 'validates' and resource 'card composition' distinguish it from send_card, which likely creates/sends.

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

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

The description implies usage (before sending, to validate IDs) but doesn't explicitly state when to use this versus alternatives like send_card or get_card_templates. It gives context but no exclusions or explicit when-not-to-use.

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 present, the description carries the full behavioral burden and excels: it warns that v0 sends no email, states that delivering the card is the agent's responsibility, notes the free-tier hard cap, and details validation constraints for relationship and fact_confirmed. This goes well beyond the structured 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?

The description is front-loaded with the core action, then delivers critical caveats in short, scannable lines. Every sentence adds unique value—free-tier limits, no-email behavior, relationship handling, and fact confirmation rules—with no filler.

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

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

For a 10-parameter tool with no output schema, the description gives enough operational context to invoke correctly: catalog-source IDs, the card_url result, no-email delivery, and special parameter semantics. Some details like error behavior or what happens after the free cap remain implicit, leaving room for improvement.

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%, but the description compensates by saying all IDs must come from catalog tools and by giving explicit semantic guidance for relationship and fact_confirmed. It does not individually describe occasion, sender_name, recipient_email, or holiday_id, but these are relatively self-evident.

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 the specific verb 'Send a Dear Human card', which clearly distinguishes it from the catalog/preview siblings. It also emphasizes that no email is sent and that the result's card_url is the card, making the tool's 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?

Useful context is provided: IDs must come from catalog tools, first 5 cards are free, and relationship/fact_confirmed modes are explained. However, it never explicitly says when to use send_card versus preview_card or any other alternative, so the exclusion/alternative guidance is implied rather than stated.

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 provided, the description carries the full behavioral burden. It discloses that the tool creates a real card, returns its URL, enforces a 3-demo limit per sender, and that demo cards do not count against the 5 free cards. It does not explicitly state whether a real card counts against the 5 free cards or whether an email is actually delivered, but the disclosure is still strong for an unannotated 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 concise and front-loaded with the core purpose, followed by concrete usage rules and the send_card routing. The 'TRY IT' and 'zero decisions' phrasing is lightly promotional, but every sentence contributes useful information and nothing is redundant or bloated.

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 tool with three optional parameters and no output schema, the description covers the key return value (URL), the demo vs real behavior, quota implications, and the intended workflow transfer to send_card. Minor gaps remain around exact real-card quota counting and whether a real card triggers an email delivery, but these are not critical for correct invocation.

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

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

Schema description coverage is 0%, so the description must add meaning beyond the bare property names. It does clarify that every argument is optional and explains the semantic difference of recipient_email (empty = demo, populated = real card). However, it does not explain occasion or sender_name beyond what their names and defaults already imply.

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 and resource: 'creates a real, live Dear Human card and returns its URL'. It also distinguishes itself from send_card by saying 'Then use send_card to say what you actually mean', which prevents confusion with the primary sending 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 clearly frames when to use this tool ('TRY IT', 'zero decisions') and gives concrete usage conditions: leave recipient_email empty for a demo or provide it to make a real card. It names send_card as the alternative for actual messaging. It does not explicitly mention preview_card or other siblings, but the guidance is sufficient for the main decision.

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 provided, the description carries the full burden of behavioral disclosure. It explains that wallet must be an EVM address on Base, that payload is read by a human and never executed, caps payload at 4000 chars, and indicates turnaround time in days. This is strong behavioral context, though it does not cover side effects or reversibility.

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: purpose first, then parameter definitions, then return values and turnaround. Every sentence adds useful information without repetition or 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 no output schema and no annotations, the description covers the core concerns: what the tool does, how to format the main parameters, what is returned, and expected timing. It could be more complete by explaining how to use claim_id/status_url or clarifying sender_name, but it is largely sufficient for an agent 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%, so the description must compensate. It adds meaningful semantics for wallet and payload, including formats and constraints. However, bounty_id and sender_name are left entirely to their schema titles, so the description only partially compensates for the low 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?

The description opens with a specific verb and resource: 'Claim a bounty from get_bounties.' It clearly identifies the action and the source of bounty data, and the 'Returns claim_id + status_url' clause distinguishes it from browsing bounties or checking a claim.

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 'from get_bounties' gives clear context that this tool is used after listing bounties, and the mention of returning a status_url implies later status checking. It does not explicitly rule out alternatives like check_bounty_claim, but the usage context is reasonably clear.

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