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

With no annotations, the description carries the whole burden and does substantial work: it discloses routing to the pro's endpoint when available, guaranteed persistence in the hosted inbox and receipts ledger, and the anti-quote design (no price field). It still omits auth/identity expectations, duplicate-request behavior, and failure modes for a write 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?

Front-loaded with purpose and required fields, then constraints, then routing behavior — a sensible order with no filler sentences. The required/optional enumeration partly duplicates the schema and crowds out the more distinctive behavioral notes, costing a point.

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 9-parameter unannotated write tool with no output schema, the description covers inputs, constraints, and side effects well. It does not mention what is returned (e.g. a request ID that sibling update_request_status would need), which is the main remaining gap an agent would hit on the next turn.

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 44%, so the description must compensate, and it does by enumerating all eight required fields plus access_notes and calling out the absence of a price field — important because additionalProperties is false, so an agent that invents a price/quote field would be rejected. It adds little semantic depth beyond field names (e.g. what listing_id must reference), which keeps it from a 5.

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 verb and resource ('Send a structured job request to a pro') plus the mechanism ('the network's standard form'), and the sibling pointers (search_pros / get_listing) locate it in a workflow rather than leaving it ambiguous. An agent can distinguish it from check_inbox or update_request_status without opening any schema.

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 prerequisite chain — 'Follow the listing's rules (see search_pros / get_listing)' — which tells the agent to resolve a listing first. It does not state an explicit 'do not use when' or what to do if required fields are unknown, so it stops short of full routing guidance.

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