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

With no annotations, the description carries the full burden and largely meets it: it discloses that beta usage is free, that topup returns a Stripe URL the agent must show to the user, and that renders are charged by GPU second only for frames that actually rendered. It does not cover auth requirements, failure modes, or whether topup charges immediately versus at checkout completion.

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 core purpose is front-loaded in the first clause, and each subsequent sentence adds a distinct fact (beta behavior, paid branches, charging model). It is dense and slightly long for a one-parameter tool, but no sentence is redundant.

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?

An output schema exists, so return-value detail is not strictly required, yet the description helpfully summarizes what each mode returns. Given the financial nature of the tool, the main residual gap is the absence of any note on permissions or error handling, but nothing essential for correct invocation is missing.

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% and the single parameter is undocumented in the schema, yet the description fully compensates: topup_yen = 0 triggers payment confirmation and balance readout, while topup_yen > 0 with a minimum of 500 triggers a Stripe checkout URL. An agent can choose a value correctly without any other source.

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 opens with a concrete verb and resource: 'Check the account's quota or credit', and then details the mode-dependent payload (usage/quota/reset in beta, balance/price/previews when paid). This is clearly distinct from the render_* and scene_info siblings, which do not touch account balances or payments.

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 explicit conditional guidance keyed on topup_yen: 0 to confirm a just-made payment and read the balance, >0 (min 500) to obtain a checkout URL. It also frames the beta-vs-paid distinction. What's missing is routing advice against any alternative tool, but for this resource there is no competing sibling to name.

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

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

Without annotations, the description carries the full burden. It discloses that GPU time after cancel is not used (billing implication) and that only queued or running jobs can be canceled, but omits other behavioral traits such as permissions, reversibility, or what happens to the job after cancellation.

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 short sentences, front-loaded with the action and followed by a key effect. No wasted words.

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 mutation tool with no annotations, the description is sparse. While it covers the basic action and one billing detail, it lacks sufficient behavioral context (e.g., permissions, side effects, error conditions) and does not compensate for the undocumented parameter.

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%, and the description does not mention the job_id parameter at all. It provides no format, source, or constraints for the parameter, failing to compensate for the missing schema documentation.

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 (Cancel) and resource (JANCTION render job), and scopes the operation to queued or running jobs. It distinguishes itself from siblings like render_status or render_final, though it does not explicitly name alternatives.

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?

No explicit guidance on when to use this tool versus alternatives is provided. The description implies the tool is for cancellation, but lacks when/when-not conditions or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden; it usefully discloses the default output directory and the blocking wait semantics of wait_seconds, which are non-obvious. However it omits what happens on timeout or failed jobs, overwrite behavior for an existing out_dir, and any permission/auth requirements.

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, front-loaded with the action and output artifacts, then parameter behavior and the return value. No filler or redundancy.

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 3-parameter download tool with an output schema already covering return values, the description supplies the essential defaults and wait semantics. It stops short of covering failure/timeout or overwrite edge cases, but those are secondary given the low complexity.

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, and it does: it explains out_dir's default (~/janction-render/<job_id>) and the conditional semantics of wait_seconds (>0 waits up to that long). job_id is only implicitly explained as the target job, leaving minor room for improvement.

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 precise verb+resource ('Download a JANCTION render job's files') and enumerates the concrete artifacts returned (PNG frames, sheet.png, output.mp4), so the agent can distinguish it from siblings like render_status, render_cancel, or render_final without opening a schema.

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 implied (download a finished job's outputs) and the wait_seconds behavior hints at post-render retrieval, but the description never states when to prefer this over render_status or render_info, nor any prerequisite like the job existing or being complete.

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

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

With no annotations, the description carries the full burden and does most of it: it discloses that no GPU time is consumed, that scene_id switches to measured per-scene timings, and what the result contains (GPU seconds, queue wait, quota fit, size limits). It does not state error behavior or whether results can be cached/reused, so it falls just short of full disclosure.

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?

Front-loaded with the core purpose and cost, then structured by parameter and workflow. Dense but every clause carries information; only the parenthetical rendering example ('about 3 minutes') is decorative padding.

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 an 8-parameter, zero-coverage, no-annotation tool this is complete: purpose, cost, parameter semantics, and the workflow step that must precede render_final are all covered. Return values are partly described even though an output schema already exists.

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 coverage is 0% and all 8 parameters are undocumented in the schema, so the description must compensate — and it does. It defines kind ('final' vs 'preview'), the frames syntax ('1-24'), the frame_start..frame_end range, width x height, samples, and the effect of passing scene_id.

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 (estimate) and resource (render) with an explicit scope constraint: it runs BEFORE the render starts and consumes no GPU time. This cleanly distinguishes it from render_final and render_preview, which actually produce output.

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?

Explicitly says when to use it (before starting a render), what it costs (no GPU time), and names the sibling that follows it: 'Tell the user the result before calling render_final.' It also gives a condition for the optional scene_id parameter. Routing to the alternative is unambiguous.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that the call returns job_id plus an estimate immediately while rendering runs in the background, prescribes polling with render_status followed by render_download, and warns that inputs/results are deleted 24 hours after last use.

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?

Front-loaded with the core action, then workflow and retention caveats, with no filler sentences. Dense but every clause carries information; minor density cost from packing the polling chain into one sentence.

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?

An output schema exists, so return values need not be detailed, and the description still explains the async return contract and lifecycle. The only gap is the four undocumented rendering parameters, which an agent may set blindly given the defaults.

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 coverage is 0% across 11 parameters, so the description must compensate. It gives meaning for scene_id, scene_path, scene_script, frame_start/frame_end (inclusive), output ('mp4'/'png'/'auto') and fps, but leaves width, height, camera and samples entirely undocumented in both description and schema.

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 (render) and resource (final frames or video of a Blender scene) plus the execution environment (JANCTION GPUs). The phrase 'Call this after the user approved a preview' cleanly separates it from the sibling render_preview.

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?

Explicitly states when to call it (after preview approval) and names the alternative entry points: reuse scene_id from render_preview, or upload via scene_path/scene_script. It also routes the agent forward to render_status and render_download, so the full workflow is inferable without opening other definitions.

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

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

No annotations are provided, so the description carries the disclosure burden alone. It implies a read-only diagnostic (no mutation hinted) and names the data returned, but does not state read-only-ness, auth requirements, or rate limits explicitly.

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 sentences, front-loaded with what it shows and followed by when to call. Every clause earns its place with zero 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?

An output schema exists, so return-value explanation is unnecessary, and zero-param simplicity keeps the burden low. The only gap is the unexplained boundary with the sibling render_status.

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?

Zero parameters, so the baseline is 4. No parameter information is needed or missing, and the description correctly describes a no-arg diagnostic call.

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?

Specific verb 'Show' and resource 'JANCTION Render connection', with concrete fields (server URL, GPU worker status, queue length, key usage). It distinguishes itself from render_status by the connection/diagnostic framing, though the overlap with render_status is not explicitly addressed.

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?

Gives two concrete triggering conditions ('if renders seem stuck' and 'before the first render'). It doesn't explicitly contrast with sibling render_status, which is the nearest-overlap tool, so it stops short of a full 5.

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

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

With no annotations provided, the description carries the full behavioral burden and does well: it declares the output quality ('deliberately low, up to 1280x720, few samples, denoised'), cost model ('same GPU cost as one 720p frame'), return values including warnings and expiry ('24h after last use'), and reuse semantics ('reuse it without re-uploading'). The main gap is that it doesn't explicitly state potential side effects like whether a job consumes billing immediately or whether partial failures are returned as errors, but overall it is substantially informative.

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 front-loaded with the core purpose and then provides usage and parameter details in a logical flow. It is somewhat long but most sentences earn their place by clarifying behavior; a few phrases like the full iteration advice could be trimmed without losing essential 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?

Given no output schema, no annotations, and 9 parameters at 0% schema coverage, the description does a decent job covering return values and the frames parameter but omits explanation for five important parameters (camera, width, height, samples, out_dir). For a tool with this complexity, a more complete parameter guide is needed.

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, and it partially does: it explains scene_path (a .blend file OR a bpy Python script), scene_script (bpy code as text), scene_id (from a previous call), and frames (with exact syntax and tiling behavior). However, width, height, samples, camera, and out_dir receive no explanation, leaving meaningful gaps for a 9-parameter tool.

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 and resource ('Render a fast, cheap preview of a Blender scene on a JANCTION GPU') and clearly distinguishes itself from siblings by emphasizing it is a preview, with an explicit handoff to render_final. An agent can identify exactly what the tool does without reading other definitions.

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 explicitly states when to use this tool ('when the user is making 3DCG with Blender and wants to see how it looks, but has no GPU or local rendering is slow'), provides the alternative action ('call render_final' once satisfied), and describes the iterative workflow between them. This is a strong example of routing guidance.

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

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

With no annotations, the description carries the full burden. It details returned fields (frames done, queued chunks, ETA, artifacts, warnings, error/log tail), which is useful, but it never states that this is a read-only operation, nor does it mention permissions, rate limits, or idempotency.

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 packed sentences front-load the purpose, then list the exact return fields, and close with a routing tip. Every phrase earns its place and there is no 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?

An output schema exists, so the description does not need to explain return values (though it does helpfully enumerate them). The main gap is the unexplained job_id parameter, which an agent must still infer from context or prior tool calls.

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?

There is one required parameter (job_id) with 0% schema description coverage. The description never mentions job_id, its expected format, or where to obtain it, so it fails to compensate for the missing schema documentation.

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 ('Check') and resource ('a JANCTION render job'), then enumerates the exact status fields returned. It also distinguishes itself from the sibling 'render_download' by saying to use that only once status is done.

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 an explicit alternative and condition: 'Use render_download once status is done.' However, it does not state when not to use this tool or clarify its relationship to other status-like siblings (e.g., render_info).

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

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

With no annotations, the description carries the full burden and delivers real behavioral context: no GPU required, takes a few seconds, detects missing linked files ('that would render pink'), and returns a scene_id for reuse. It stops short of error/permission behavior or whether the scene is mutated, but the operational profile is unusually well disclosed.

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?

Front-loads the core purpose in sentence one, then handles invocation modes and workflow placement. Three sentences, each carrying distinct information with no 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?

Output schema exists so return values need not be re-explained, yet the description still notes scene_id is returned for reuse. Combined with input-mode coverage, sibling routing, and the no-render behavioral profile, an agent has everything needed to invoke this correctly.

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 coverage is 0%, so the description must compensate, and it largely does: scene_path is '.blend or .py file', scene_script is 'bpy Python code as text, no file needed', and scene_id comes 'from a previous call'. Each of the three parameters gets explaining format or provenance, leaving only mutual-exclusivity/default rules unstated.

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?

Opens with a specific verb+resource ('Read a Blender scene') and immediately scopes it ('WITHOUT rendering'), then enumerates exactly what is returned (cameras, frame range, fps, resolution, engine, objects, lights, materials, animation, missing linked files). This clearly differentiates it from the render_* siblings, which perform rendering.

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?

Explicitly states when to call it: 'Call this first for a .blend you did not write yourself, or after writing a bpy script to check what it produced.' It also routes output forward ('Use the camera names and frame range in render_preview / render_final'), naming the downstream alternatives.

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