Queue a fictional retry after diagnostics. Defaults to dry-run and returns a retry build identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | ||
| build_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ||
| dry_run | Yes | ||
| build_id | Yes | ||
| observed_at | Yes | ||
| retry_build_id | Yes |
Changes observed during successful MCP inspections.
Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "build_id": {
+ "type": "string"
+ },
+ "dry_run": {
+ "type": "boolean"
+ },
+ "observed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "retry_build_id": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "build_id",
+ "retry_build_id",
+ "dry_run",
+ "status",
+ "observed_at"
+ ],
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses that the operation defaults to dry-run and returns a retry build identifier, which is useful. However, it does not clarify what side effects occur outside dry-run, what 'fictional' means, or whether permissions/rate limits apply.
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?
A single, compact sentence covers the action, the default behavior, and the return value. No filler or redundancy; every clause contributes useful information.
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?
The tool is simple with only two parameters and an output schema, so full return documentation is unnecessary. Still, the description misses the meaning of build_id and the operational context of 'after diagnostics', leaving slight gaps for correct invocation.
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 for parameter meaning. It only mentions the dry_run default, leaving the required build_id parameter entirely unexplained. The agent cannot infer what build_id refers to from the description alone.
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 a specific action ('Queue a fictional retry') and object ('after diagnostics'), plus a concrete output ('retry build identifier'). It is clearly distinguishable from siblings like ci_get_build_status or ci_trigger_deploy, though the word 'fictional' is unusual and slightly obscure.
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 phrase 'after diagnostics' implies a workflow context for when this should be used, but there is no explicit guidance on when to prefer it over alternatives like ci_run_build_command or ci_trigger_deploy, nor any exclusions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.