Request Quote

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

The annotations already carry readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful non-obvious behavior: it never transmits contact information, never creates a lead itself, requires the buyer to open and submit the form, and does not reserve or guarantee pricing/availability. There is no contradiction with the annotation object.

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 dense but front-loaded with the trigger condition and key requirement. It is arguably a little long and contains a couple of repeated privacy-related caveats, but each sentence carries a meaningful operational or safety instruction for an agent.

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 schema covers all parameters, an output schema exists, and annotations cover the read-only behavior, the description supplies what is left: preconditions, fallback behavior, expiration handling, and the PII boundary. The tool is fully covered from the perspective of an agent deciding whether and how to invoke it.

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 100%, so the baseline applies. The description does reinforce that plan_id must be a saved non-PII plan reference from plan_staffing or save_staffing_plan, but it adds no new meaning for skill_id, skill_version, or source_platform beyond what the schema already documents.

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 a specific verb and resource: after a buyer asks to proceed, return a TempGuru-owned pre-filled review form for a saved plan_id. It explicitly states the tool does not create a quote reference or CRM lead, which clearly distinguishes its purpose from quote-status or lead-creation tools.

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 gives an explicit trigger condition, required input source, and the buyer's required follow-up action. It also gives concrete when-not guidance by saying to give continuation.form_url directly when no plan_id exists, to never collect contact details, and to re-run an expired plan.

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