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 meaningfully discloses that the draft is unpaid, returns an immediately viewable preview URL, requires a checkout URL for payment, and that unpaid drafts are deleted after 7 days. It does not cover error cases or auth requirements, but it provides substantial behavioral context.

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

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

The description is three short sentences with no filler. Each sentence earns its place: the first states the core action, the second explains return values and payment requirement, and the third discloses the expiration policy.

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?

Despite having 10 parameters and no output schema, the description explains the key return artifacts (preview URL, checkout URL), payment amount, and draft lifecycle. It does not mention how to coordinate with list_templates for template selection or detail optional fields, but for a draft-creation tool the essential flow is covered.

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 50%, covering required params like date, email, location, and partner names. The description adds no parameter-level meaning beyond the schema, and optional params such as story, venue, maps_url, and template are not clarified. However, the parameter names are mostly self-explanatory and template/language have enums, so the gap is moderate.

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 creates an unpaid wedding invitation website draft, which is a specific verb+resource combination. It is easily distinguishable from siblings list_templates and get_pricing, and the preview/checkout URL details further define the deliverable.

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: use this tool to create a draft that produces a preview URL and requires a EUR 49 checkout payment to publish. It does not explicitly state when not to use it or name alternatives, but the sibling tools are clearly different and the intended workflow is obvious.

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 burden. It states what the tool returns (pricing and inclusion details) but does not disclose output format, freshness, caching, or access requirements. For a simple get operation, this is minimally adequate but lacks richer behavioral context.

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

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

The description is a single, front-loaded sentence with no wasted words. It communicates both the action and the key scope ('what is included') efficiently.

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 (zero params, no output schema, no annotations), the description is mostly complete for its intended use. The phrase 'what is included' is slightly vague but acceptable for a pricing lookup 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 tool has zero parameters and the schema is empty with 100% coverage, so the description has no parameter semantics to add. Per the baseline for zero parameters, a score of 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 uses a specific verb ('Get') and clear resource ('current pricing') plus scope ('what is included'), distinguishing it from sibling tools like create_wedding_draft and list_templates. Even without the siblings, the purpose is unambiguous.

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

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

The description implicitly makes clear this is for retrieving pricing information rather than creating drafts or listing templates, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. The clear context is sufficient for a simple read-only tool.

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 exist, so the description carries the full burden. The verb 'List' implies a read-only retrieval, and it states the count of four, but it does not disclose the return shape, ordering, pagination, or any side-effect/resource-access details. It is not misleading, just minimal.

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 sentence with the verb front-loaded and no filler or redundancy. Every word adds value.

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, simple listing tool, the description is nearly complete. It would benefit from stating what the returned list contains (e.g., template names or IDs), but the lack of an output schema does not create a severe gap given the simplicity.

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 the baseline score of 4 applies. The description does not need to explain parameter semantics because there are none.

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 ('List') with a clear direct object ('the 4 available wedding website templates') and specifies the exact count. It is clearly distinct from the sibling tools create_wedding_draft and get_pricing.

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 action is straightforward and the description implies when to use it (whenever available templates need to be seen), but there is no explicit guidance about sequencing or alternatives. It does not say 'before creating a draft' or mention 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.