company_job_quote

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

With no annotations, the description carries the full burden, and it does substantial work: it reveals that the team is matched from bundle plans using persisted work-order hours, costed with contingency, overhead, and target utilisation, then judged against offer/budget. It also names the possible verdicts and the inclusion of floor/target prices and risks, which is genuinely valuable behavioral 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 front-loaded ('Quote a job') and contains no filler, but it is a single dense run-on sentence with multiple embedded clauses that is hard to parse. Every clause adds information, yet the structure makes it less digestible than it should be for an agent scanning many tools.

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?

Although an output schema exists and the description does preview return categories, this is a complex 7-parameter tool with no annotations and zero schema descriptions. The description does not explain how to construct bundle_json, what project_id selects, the role of payload_json, or the meaning of now/engine/operation/entity_ref, so an agent cannot confidently build a valid call.

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, but it does not map its domain concepts to the actual parameters. It mentions 'payload job', 'profiles', 'offered_price', and 'taxonomy', yet the schema exposes project_id, bundle_json, payload_json, now, engine, operation, and entity_ref, with no explanation of how these relate or which must hold the mentioned data.

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 states the specific action ('Quote a job') and names concrete inputs ('payload job', 'sealed worker profiles') and outputs ('bid, negotiate, no bid, cannot staff, or unpriced' with floor/target prices and risks). It distinguishes this from related quoting/costing siblings by describing the decision-oriented outcome rather than just cost computation.

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 a use case ('Quote a job') but gives no explicit guidance on when to choose this tool over siblings like company_job_costing, company_quotes, or company_quote_outcomes. There are no stated exclusions, prerequisites, or alternative routing, so an agent gets little help with tool selection.

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