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

No annotations are provided, so the description carries the behavioral burden. 'Browse' implies a read-only operation and the occasion list clarifies accepted filter values, but it does not mention return format, pagination, or what happens when occasion is empty.

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, well-structured sentence that front-loads the core action and then adds the optional filter. There is no filler or redundant restating of the tool name.

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 browse tool with one optional parameter, the description covers the essential invocation details: what it returns conceptually and which filter values are valid. It lacks return-shape details, but the tool is simple enough that 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 input schema only declares an optional string with a default and no description, so schema coverage is effectively 0%. The description compensates by enumerating the valid occasion values and stating that filtering is optional, giving an agent the key semantic information.

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 ('Browse') and resource ('card catalog'), and the optional occasion filter adds precision. It distinguishes itself from siblings by resource domain, though it does not explicitly name an alternative.

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 when to use this tool: when browsing card templates, optionally narrowed by occasion. However, it provides no explicit when-not guidance or comparisons with siblings like send_card or get_offers.

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 disclosure burden. It adds a meaningful behavioral trait: 'their data never leaves you' signals privacy/local processing. However, it does not explicitly describe what the tool returns, whether it calls external services, or any other side effects, though for a zero-parameter read-oriented tool this is a reasonable level of disclosure.

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 short sentences, front-loaded with the core concept and free of filler. The second sentence combines selection guidance with a privacy note; both carry signal, though the tone is slightly more marketing-like than technical, which keeps it from a 5.

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-input tool this is mostly sufficient: an agent can infer it should call get_offers to obtain or consider gift offers and use known recipient context. However, the description never explicitly states whether the response is a list or a single offer, and it assumes the agent already understands how to use recipient data in the 'match' instruction, which is a notable gap without an 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 input schema is empty and parameter count is 0, so there is nothing for the description to document. Baseline 4 is appropriate because no parameter semantics are 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 identifies gift offers as the resource ('gift-offer shelf') and asks the agent to pick the one the recipient would want, so it is not a tautology. However, it lacks a clear verb+resource statement such as 'Returns gift offers'; the metaphor and imperative leave the exact operation somewhat ambiguous. The sibling tools are thematically different but no explicit distinguishing phrase is given.

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 implies use when a gift offer needs to be selected for a recipient, especially based on existing knowledge about that person. It never states when not to use it or names an alternative tool, so the usage logic is left mostly to inference.

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

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

With no annotations, the description carries the full behavioral burden. It adds useful context by defining register values (plain/lore/all) and the rule that users pick phrase IDs rather than write text. Yet it does not disclose what the occasion parameter does, the return structure, or whether results are filtered or paginated.

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 short sentences with no filler. It front-loads the resource identity, then lists register options and the selection behavior, with every phrase 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?

For a simple two-optional-parameter getter, the description gives a usable entry point: it explains the register options and the selection-based composition model. However, the omission of occasion's meaning and the absence of any output schema leave notable gaps for an agent trying to make an informed call beyond defaults.

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 contains zero parameter descriptions, so the description must compensate. It does for 'register' by listing valid values and the default, but 'occasion' is left completely unexplained. With half the parameters undocumented in both schema and description, the coverage is insufficient.

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 the resource as a 'selectable phrase library + sign-offs' and explains that cards are composed by selecting phrase IDs, which clearly distinguishes it from siblings like get_card_templates and send_card. There is no explicit verb in the description, but the tool name 'get' plus the resource framing makes the purpose unambiguous.

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

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

The description implies when to use the tool: when composing a card, you select phrases from this library rather than writing free text. However, it does not explicitly state when not to use it or point to alternatives such as get_card_templates, leaving the comparative routing to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It hints that multiple holidays may exist ("Send only the one") but does not state the return format, how many results are returned, whether the selection is random or ordered, or any side effects. The instruction to send is aimed at the agent, not the tool's 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?

The description is exceptionally compact: two short sentences, no filler, and the core retrieval purpose is front-loaded. The second sentence adds useful selection guidance without bloating the description.

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 getter, invocation is simple, and the description conveys the main purpose and a usage cue. However, with no output schema and no annotations, it leaves the return value unspecified—an agent still has to guess whether it receives a list, a string, or structured objects.

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 with zero parameters, so parameter documentation is trivially complete. The baseline of 4 applies; the description does not need to add parameter meaning when there are no parameters to explain.

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 today's micro-holiday and implies a retrieval action via "What micro-holiday is it today?" It is distinct from sibling tools like get_phrases and get_offers since it specifically targets holidays. It falls short of 5 because it lacks an explicit imperative verb such as "Gets" or "Returns."

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 for surfacing today's micro-holiday and instructs to pick the one the human would enjoy, giving some selection guidance. However, it never explicitly says when to prefer this tool over siblings like get_phrases or get_offers, nor does it provide exclusions or 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?

With no annotations provided, the description carries the full burden and does disclose meaningful behavioral traits: the free-tier hard cap, the restricted relationship values, and the special condition for fact_confirmed. It stops short of explaining side effects such as cost beyond the free tier, delivery behavior, or error handling when the cap is exceeded, but the stated constraints are valuable and non-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 compact and every sentence adds information. It front-loads the core purpose, then gives prerequisite and constraint details in tight, scannable sentences. The parameter-specific notes are clearly separated with 'relationship:' and 'fact_confirmed:' labels, making the structure easy to parse.

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 has 10 parameters, no annotations, no output schema, and 0% schema coverage, the description is reasonably complete. It covers the main preconditions and constraints needed to invoke the tool correctly. A few gaps remain, such as the exact meaning of 'plain register' and any guidance on what occasion should be, but the core usage rules are present and actionable.

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 real meaning to parameters by specifying that all IDs (template_id, phrase_ids, signoff_id, offer_id, holiday_id) must come from catalog tools, enumerating the two valid values for relationship, and giving a rule for fact_confirmed. It does not explicitly explain sender_name, recipient_email, occasion, or holiday_id, but these are fairly self-explanatory and/or covered by the schema defaults.

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 action 'Send a Dear Human card', naming a clear verb and resource. It also implicitly distinguishes this tool from the sibling getter tools ('get_card_templates', 'get_phrases', 'get_offers', 'get_todays_holidays') by being the only send action in the group.

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 explicit context on when to use this tool: 'All IDs must come from the catalog tools' tells the agent to first call the getter siblings to obtain valid IDs. It also provides a hard cap ('First 5 cards per sender are free') and a validation rule for 'relationship'. It does not explicitly name alternative tools or state 'when not to use', but the sibling names and the verb 'send' make the selection clear.

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