build_statusCheck the status of an asynchronous build job by job_id, returning running, done, or error states with progress details.
Статус асинхронной сборки по job_id (running/done/error + прогресс).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Идентификатор job из build. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.14.0Input schema / additionalPropertiesAdded value: +falseInput schema / properties / job_id / descriptionPrevious value: -"Идентификатор job из build"New value: +"Идентификатор job из build."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}v0.10.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the operation is async and that the result surface includes running/done/error plus progress, but it says nothing about permissions, whether state is retained after completion, or timeout/expiry behavior for job_ids.
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 that front-loads the operation, the input (job_id), and the observable outcomes. Nothing is redundant 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?
For a one-parameter, non-nested status tool with an output schema present, the description covers what is needed to invoke it and even previews the state values. Minor gaps in workflow placement (when/how often to poll) keep it from a 5, but the return format does not need explaining given the output schema.
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 job_id parameter is documented as the identifier coming from 'build'. The description adds no format, length, or lifecycle detail beyond that, so it neither compensates for nor extends the schema — the baseline 3 for high coverage 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?
The description states a specific verb+resource: it returns the status of an asynchronous build identified by job_id, and even enumerates the possible result states (running/done/error + progress). This clearly distinguishes it from the sibling 'build' tool that presumably initiates the job, though it never names that sibling explicitly.
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: the word 'асинхронной' (asynchronous) and the required job_id signal that this is a polling tool used after a build has been started, but there is no explicit when-to-use statement, no guidance on polling cadence, and no named alternative. A caller must infer the workflow from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.