quady3d_get_jobQuery a 3D generation job's status and result by ID, optionally waiting up to 30 seconds; a local timeout does not cancel the cloud task.
Query the original task, optionally waiting up to 30 seconds. A local timeout does not fail or cancel the cloud task and must not trigger a replacement generation.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| wait_seconds | No |
Changes observed during successful MCP inspections.
v0.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the description does not need to restate safety. It adds meaningful non-obvious context: the wait is bounded, a local timeout does not fail or cancel the cloud task, and it must not trigger a replacement generation. It stops short of describing what the query returns or how to interpret a pending job.
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?
Two tightly written sentences, front-loaded with the main action and followed by the most important caveat. Every sentence earns its place; there is no repetition or filler.
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 read-only tool with annotations covering safety and idempotency, the description covers the critical timeout caveat. But with no output schema, it leaves an agent without any indication of what a job query returns or how to interpret the result, and job_id remains unexplained.
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 both parameters. It adds useful meaning for wait_seconds ('waiting up to 30 seconds') but says nothing about job_id—its required status, expected format, or where the ID comes from—leaving half the parameters without semantic guidance.
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 uses a specific verb ('Query') and object ('the original task'), making the retrieval intent clear. It does not explicitly distinguish itself from siblings like quady3d_list_jobs or quady3d_create_job, and 'original task' is slightly less precise than 'job', but the core purpose is understandable.
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?
It gives useful operational guidance: waiting is optional up to 30 seconds, and a local timeout must not be treated as a cloud-side failure or trigger a replacement generation. However, it does not state when to use this tool versus quady3d_list_jobs, quady3d_create_job, or other alternatives, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.