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

Beyond annotations, the description discloses a required read-write token (an auth prerequisite not encoded anywhere in structured fields) and that the call returns job_id and attempt_id suitable for polling. It doesn't cover retry behavior or what duplicate triggers do, but the annotations already flag non-idempotent, open-world behavior.

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?

Three tight sentences: purpose first, target resolution second, return value and auth third. Every sentence carries information and nothing is 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?

With an output schema present and 100% schema coverage, the remaining gaps are small: the description covers the action, defaulting behavior, the follow-up polling tool, and the auth requirement. The one missing piece is any statement of how this differs from redeploy or deploy_files.

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 description's commit/ref defaulting language largely restates what the schema already says (commit defaults to tip of ref; ref defaults to the project's configured ref). No additional format or syntax detail is contributed beyond the schema, so 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: "Trigger a build + deploy for a project," plus the resolved target semantics (given commit, else tip of ref). An agent immediately knows what the tool does. It does not, however, distinguish itself from nearby siblings like redeploy or deploy_files, which likely have overlapping intent.

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?

Usage is only implied — you call it when you want to build and deploy. The one real routing hint is "poll with get_build_status," which helpfully names the next tool. There is no explicit when-not guidance or comparison against redeploy/deploy_files, so the alternative selection is left to inference.

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