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

With no annotations, the description carries the full burden and does disclose meaningful behavior: nothing is arranged on the user's behalf (no fulfillment side effect) and a receipt is returned listing uncovered fields. It omits idempotency, whether submissions are reviewed, retry/rate behavior, and whether contact storage is optional — details that matter for a write 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?

Two dense sentences, front-loaded with the core action and the fallback slug rule. Slightly clipped phrasing ("Nothing is arranged on your behalf") reads as compact rather than padded.

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 tool with 10 parameters, nested objects, no output schema, and no annotations, the description is thin. It never explains the receipt's structure despite referencing it, nor does it cover the majority of optional fields, leaving an agent guessing at how to build a well-formed submission.

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 40% across 10 parameters, so the description must compensate. It clarifies the sentinel value for `slug` and hints that `specifications`/`requested_fields` relate to fields no listed service covers, but leaves `action`, `budget`, `timing`, `quantity`, and `geography` entirely unexplained in both schema and description.

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?

"Record a requirement" is a specific verb+resource, and the description states scope (any service) plus the sentinel-slug fallback, which no sibling tool offers. It is not differentiated from the sibling tools by name, but none of them overlap functionally, so an agent can still place it.

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 routing rule: use slug "anything-else" when no listed service covers the need. However, it never says how to obtain a valid service slug (e.g., via entity_lookup or a listing call), nor does it state any prerequisite or exclusion beyond that one branch.

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