acquire_deploy_lock

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

No annotations are provided, so the description must fully disclose behavior. It omits critical details: what happens if a lock already exists (fail or block?), whether the operation is idempotent, and what the output contains (though output schema exists). This lack of behavioral context risks misuse in concurrent scenarios.

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 two concise sentences. The first sentence states the core purpose, and the second lists the parameters. No fluff. It is front-loaded and efficient.

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 simple lock-acquisition tool, the description covers basic usage and parameter requirements. However, it lacks context about failure modes (e.g., lock contention), integration with sibling tools (e.g., calling release_deploy_lock after deployment), and whether the lock is scoped to a specific resource. The presence of an output schema reduces the need to describe return values, but behavioral gaps remain.

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?

The input schema describes both parameters with text, but the top-level 'body' parameter has no schema description. The description adds context for lockedBy (identity examples) and ttlMinutes (default 30, max 60), which partially compensates for the schema gap. However, the default value stated in the description (30) conflicts with the schema's default null, reducing clarity.

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 clearly states the verb 'Acquire', the resource 'deploy lock', and the reason 'to prevent concurrent deployments'. This distinguishes it from siblings like release_deploy_lock and force_release_deploy_lock.

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 explicitly lists required and optional parameters with defaults and maximums, giving clear usage instructions. However, it does not compare to alternative tools (e.g., when to use force_release_deploy_lock) or mention prerequisites like having an existing lock status.

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