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

Goes well past the annotations (which only cover read-only/idempotent/destructive). It discloses anonymization (contractor names and contact details absent, replaced by labels like "Contractor A"), that company size and rating band are non-price signals shared across contractors, the absence of a limit parameter and of any next page, and the required scope. For a listing tool with no pagination, that last detail is genuinely load-bearing.

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?

Payload contents come first, then the anonymization caveat, then the operational constraints (read-only, US, no pagination, scope) in short declarative fragments. No sentence is filler; each one closes a question an agent would otherwise have to guess at.

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?

With an output schema present the description is not obligated to explain return values, yet it summarizes the payload anyway and layers on regional, auth, and pagination constraints. Nothing material is missing for a single-parameter read 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?

Schema description coverage is 100% and the single bidCardId parameter is already documented as a UUID sourced from list_my_jobs, so the schema does the work. The description only adds the ownership constraint (it must be one of the signed-in homeowner's jobs), which is useful but marginal — baseline 3 applies.

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 ("Returns the bids contractors placed on one of the signed-in homeowner's jobs") and immediately enumerates the payload shape — amount, timeline, written scope, contractor label. An agent knows exactly what it gets back and can distinguish this from job-level siblings like list_my_jobs or bid_checklist.

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?

Prerequisites are spelled out: needs the jobs:read scope, US only, and bidCardId comes from list_my_jobs (also encoded in the schema). What it does not do is name an alternative or exclusion path — e.g. it never says to use bid_checklist instead when the homeowner wants evaluation criteria rather than raw bids — so an agent must infer the routing from sibling names.

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