JANCTION Render

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

Annotations already declare it as a read-only, idempotent, open-world search, and the description adds substantial context beyond that: the result spec format 'polyhaven:<id>', that sizes are in metres, the entry file, 1k-default versus '@2k' texture variants, and that import_model strips Blender's startup cube. That is real behavioral knowledge an agent cannot get from the annotations.

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 purpose is correctly front-loaded, but the rest is one dense run-on paragraph that mixes search semantics with a full render workflow and a Python API reference (material, apply, world_hdri) that belongs to the import tooling, not to search. Several clauses would be better placed in render_preview or the import tool's description.

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?

Even though an output schema exists, the description still tells the agent what each result carries (spec id, size in metres, entry file), which is exactly what it needs to wire results into render_preview. Nothing required for a correct call 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 coverage is 100%, with both params (query, kind) fully documented including the enum-like kind values, so baseline is 3. The description's query examples restate the schema and the '@2k' suffix applies to the id used in asset_urls rather than to this tool's inputs, so it adds little parameter meaning of its own.

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 and resource: find free CC0 3D models, PBR textures or HDRIs on Poly Haven, plus concrete query examples. It is unmistakably a search tool and cannot be confused with the render_* siblings.

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 an explicit scenario ('for product shots of something the user has no model for') and chains it into render_preview with concrete arguments, so the agent knows when to reach for it. It stops short of naming the counterpart path (e.g. use render_import_file if the user already has a file), so it lacks a true alternative branch.

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?

Annotations already declare a safe idempotent read (readOnlyHint, idempotentHint, destructiveHint=false), so the safety bar is met. The description adds genuine behavioral context beyond that: the full pricing/free-tier model, that some offers apply conditionally, and the 'Relay tell_user to the user in their language when it is present' directive — an operational trait no annotation conveys.

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, but the body is a single run-on sentence with stacked nested parentheses describing the pricing model in more detail than an invocation decision requires. The information is largely useful, yet the structure makes it hard to scan.

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 needn't be re-specified, and the description stays adequate despite naming many of them anyway. Combined with the pricing model and the tell_user relay instruction, an agent has essentially everything it needs to call a zero-parameter query tool 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?

The schema takes zero parameters, so the baseline is 4. The description wisely spends no effort on parameter syntax and instead names the returned quantities, which is the relevant semantics for a no-arg query 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 opens with a specific verb and resource: 'Check what this key can still render for free and its credit (no GPU time).' It enumerates the exact fields returned (free GPU time left, expiry, balance, price per GPU-second, pending checkout link, offers), which clearly separates it from sibling tools like render_estimate or render_info.

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 — an agent infers this is the tool to call for account quota/credit status — but there is no explicit 'call this before rendering' guidance, no when-not-to-use, and no named alternative sibling. Nothing is misleading, but routing is left to inference.

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?

Annotations only declare destructive/idempotent/readOnly; the description goes far beyond them by spelling out billing consequences (rendered frames charged, unheld GPU time returned at once), irreversibility (cannot be undone or resumed), which jobs are no-ops, the assembly-stage exception, and the ownership rule (other keys get not_found). This is exactly the behavioral context an agent needs before a destructive call.

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 action, then effects, then constraints, with no filler sentences. It is dense and long for a single-parameter tool, but every clause (billing, irreversibility, ownership, assembly exception) carries distinct 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?

With an output schema present, return values need no explanation, and annotations cover the safety profile. The description still covers the operational gaps that matter: billing impact, irreversibility, edge cases, and authorization scope.

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 100%, so the baseline is 3. The description adds real value on top: it explains the j_... and b_... job_id formats, that a b_ job stop applies to every part, and the not_found behavior for foreign keys, none of which the schema states.

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+resource ('Stop a queued or running render job of this key') and further distinguishes the two job shapes it handles (j_... and split b_... jobs). An agent can separate this from render_final, render_status, and render_info without opening any 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?

Explicit when-to-use (queued or running job), explicit when-not (already done/failed/canceled, or being assembled into the video), and an explicit alternative path ('to render again, call render_final again'). It also adds a policy instruction to ask the user before cancelling a requested render.

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?

Adds substantial context beyond the annotations: links need no key and last ~24 h, files are retained 24 h after last use or normally 7 days for paid keys, the service waits at most 50 s per call, and a finished preview returns as an inline image. This is exactly the beyond-schema behavior an agent needs and is consistent with readOnly/idempotent hints.

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 and packs the retention, waiting and file-selection detail into one dense paragraph. It is a run-on sentence, but nearly every clause earns its place 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?

With no output schema, the description does the work of describing the return (links plus an inline preview image) and the terminal curl workflow, so an agent knows what to expect. Minor gaps remain around formatting of the returned links, but the tool is adequately specified.

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 already 100%, so 'only', 'job_id' and 'wait_seconds' are fully documented structurally. The description restates the 'only' options and the 50 s wait cap, adding the retention/expiry nuance but little parameter syntax the schema lacks; baseline 3 is appropriate.

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+resource ('Get the download links of a job') and immediately scopes it (links, not job status or rendering). It is clearly distinguishable from siblings like render_status (which lists jobs) and render_preview/render_final (which create jobs).

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 clear when-to-use context: call after a job exists, call again for fresh links once they expire, and set wait_seconds > 0 to block. It does not explicitly name an alternative tool for cases where the job is not yet done, but the wait/call-again guidance effectively routes the agent.

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?

Annotations already declare readOnlyHint/idempotent/non-destructive, but the description adds non-obvious behavior: the call consumes no GPU time, it reports queue wait and free-credit limits, and it may return preliminary numbers requiring a short contiguous test render before a full animation. It also flags when a job should be split.

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?

Purpose and the no-GPU-cost caveat are front-loaded, and every sentence carries decision-relevant content. However, the middle sentences are long and clause-stacked (quota/credit, calibration, test render, splitting all in one breath), which costs some scannability.

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 10-parameter tool with an output schema and full annotation coverage, the description supplies everything an agent needs: what it does, when to call it, what it returns conceptually, how to interpret an uncalibrated result, and what to do next. No material gap remains.

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 100%, so the baseline is 3, but the description adds real meaning beyond the schema: passing scene_id switches the estimate to measured render times and produces calibration.final_path_measured, which the schema does not convey. No other parameters are elaborated, so it stays short of 5.

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 and resource ('Estimate a render before starting it') and immediately qualifiers the scope with '(no GPU time)'. It explicitly positions itself against the sibling render_final ('Call it before render_final'), so an agent can distinguish the two without opening either 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?

Gives explicit trigger conditions ('when the time or quota is uncertain, the job is longer than about 24 frames or above 720p, or the user asks how long it takes') plus a follow-up instruction to relay the result. It also branches on the outcome via calibration.final_path_measured, telling the agent what to do when it is false.

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?

Goes far beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) by disclosing pricing (0.1 JPY/GPU-second prepaid, 100/400 JPY welcome credits, 2 free preview GPU-minutes/day), hard limits (3,000 frames/call, 1080p free vs 4K prepaid), chunk-and-join rendering, file deletion after 24h (7 days once topped up), and async job_id + notify_url completion behavior.

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 purpose, the estimate-first rule, and the download follow-up before the dense cost/limit detail, so the critical routing information comes first. It is long and the trailing 'Options per parameter' enumeration duplicates the schema, but nearly every sentence carries operational weight.

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 29-parameter, 0-required, open-world render tool with an output schema, the description covers everything an agent needs: prerequisites (approved preview), cost/credit constraints, frame and resolution limits, async return contract, cleanup policy, and follow-up tools. Return values are correctly left to 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 every parameter is already richly documented in the schema, so baseline 3 applies. The description's 'Options per parameter' list and preset explanation largely restate the schema rather than adding new per-parameter meaning, though the note to reuse the approved environment/blender adds light cross-parameter 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?

States a specific verb+resource+scope: 'Render the final frames or video of a Blender scene on cloud GPUs, after the user approved a preview.' It immediately distinguishes itself from render_preview and render_estimate, so an agent can route without opening any 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?

Explicitly names when to call render_estimate first (uncertain time, >24 frames, >720p, user asks how long), when to ask the user before spending (free time doesn't cover the job), and the follow-up call render_download(job_id, wait_seconds=45). It also prescribes re-estimating after a 10-frame test for animations.

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?

Beyond the annotations, the description discloses that no render happens and no charge is incurred, that large files can take minutes, that a retry resumes rather than restarts the download (corroborating idempotentHint=true), and that it creates a scene in the account (matching readOnlyHint=false). Failure handling is spelled out, which the annotations cannot express.

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?

Tight, front-loaded, and every sentence carries operational information: formats, side effects, follow-up calls, polling, failure recovery. The only blemish is an unexplained token ('JANCTION') that slightly interrupts the opening 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?

Covers a long-running async import end to end: accepted inputs, output (scene_id, though an output schema also exists), cost and render side effects, retry semantics, and error recovery. Nothing an agent needs to invoke or re-invoke this tool correctly 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 reported as 0%, so the description must carry the load: it enumerates the supported file types (.blend, glTF/GLB, FBX, USD, OBJ, STL, bpy .py), which is the key semantic constraint an agent needs. It also implies the same file object is reused on retry, though it does not explain the file_id/download_url fields.

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 and resource (import an attached file into a scene of this account), enumerates the accepted formats, and names the return value (scene_id). It also distinguishes itself from sibling tools by naming scene_info and render_preview as the follow-up steps rather than alternatives for the same job.

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 an explicit sequence of use (import → scene_info → render_preview), a polling instruction for the 'importing' status (call again with the same file after ~30s), and a fallback when fetching fails (ask the user to re-attach or use /upload). There is no ambiguity about when this tool should be called or what to do next.

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?

Beyond the annotations (which already declare readOnly/idempotent/non-destructive), the description adds substantial operational context: no GPU time and no charge, it runs as the connected account via OAuth or connector API key, every call is rate-limited per key, and a 429 carries retry_after_s to wait on. It also explains how to interpret diagnose.tell_user output, which the agent could not infer from the schema alone.

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 purpose and pre-flight use case are front-loaded in the first sentence, and every subsequent sentence adds operative detail (thresholds, auth, rate limits, how to relay diagnose output). It is a single dense paragraph of roughly 150 words, which is longer than strictly necessary but not 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?

An output schema exists, so return-value structure need not be restated, and the description still adds interpretation guidance (workers_available, gated, diagnose.tell_user). Combined with the disclosed cost, auth, and rate-limit behavior, an agent has everything needed to call and act on this tool 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing the description needs to compensate for. Schema coverage is reported at 100% and no parameter semantics are missing.

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 names a concrete resource (connection/service status) and enumerates what it returns: server URL, GPU worker availability, queue length, expected wait, key usage. It is clearly a pre-flight/service-status check rather than a job-status tool, but it never explicitly contrasts itself with siblings like render_status or render_estimate, leaving that distinction to inference.

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?

Explicit triggers are given: use it before the first render, when renders seem stuck, or to decide whether to route a render here, with a concrete decision rule (workers_available > 0 → preview in seconds; gated → gate gives typical wait). There is no stated when-not condition and no sibling tool is named as the alternative, so it stops short of a 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?

Annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) only sketch the safety profile; the description adds substantial non-obvious behavior: output includes a critic verdict (ok/check/fix) with fix codes, final_estimate and quota_left_today, prices surface as final_offers before rendering, paid renders require user approval, and a raising script returns a failure with the offending line and renders nothing. The 1280x720 cap and 1-4-frame tiling are also disclosed. No contradiction with annotations.

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 purpose is correctly front-loaded, but the body is an over-stuffed run-on spanning pricing, quota, critic verdicts, usage examples, literal Japanese user utterances, limits and a parameter index, with some repetition (pricing is implied twice). The embedded multilingual utterance list consumes space without adding invocation-relevant meaning. Value density is high but trimming would clearly improve it.

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 0-required-parameter, 22-parameter tool with no output schema, the description covers everything an agent needs: the three ways to supply a scene, what the response contains (verdict, estimate, quota), pricing/approval flow, failure semantics, hard limits, and how presets interact with explicit options. Nothing material for correct invocation is left unstated.

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 already 100%, so the schema carries most parameter meaning and baseline would be 3. The description adds a consolidated index of the option families (preset values 'product'|'turntable'|'animation', environment presets including 'compare', orbit, cameras, engine, transparent, 'polyhaven:<id>' assets) and summarizes the three mutually exclusive scene inputs (scene_script / scene_url / scene_id) — useful because the schema declares no enums and allowed values live only in prose. It mostly restates schema content, though, so it does not reach a 5.

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?

Names a specific verb and resource ('Show what a Blender scene looks like: a fast, low-cost preview render on a cloud GPU, back as an image in seconds') and distinguishes itself from the sibling render_final ('apply the fixes and preview again before any final render', 'reuse the returned scene_id in render_final'). An agent can identify this tool and its relationship to other render_* tools 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?

Gives explicit use cases ('after writing a bpy script', 'render this .blend', 'I have no GPU') and an explicit 'When not to use' clause naming the alternatives (local Blender MCP for editing an open scene, local NVIDIA GPU for single stills) plus the positive selection rule ('for CPU-only machines, animations, and scripts with no Blender installed'). This is about as complete a routing guide as a description can carry.

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?

Goes well beyond annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) by disclosing the public-exposure consequence, the persistence rule ('keeps its own copy of the result after the job's files expire, until render_unshare'), the operator-review gate on gallery listing, and the authorization constraint that only the rendering key can share.

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?

Single dense paragraph, correctly front-loaded with what gets published before the qualifiers. The run-on ':'-chained clauses pack a lot in but every clause adds real information, so little is wasted.

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 write tool with full annotation coverage, full schema coverage and an output schema, the description covers the remaining agent-relevant unknowns: public exposure, persistence, auth constraint, and user-consent requirement. Nothing needed to invoke it safely 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 100%, so the baseline is 3. The description reinforces include_script=True, listed=True, and prompt semantics, but that meaning largely duplicates the schema's own parameter descriptions rather than adding new syntax or format detail.

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 and resource ('Publish a finished render as a public web page'), enumerates exactly what the page contains, and names render_unshare as the lifecycle counterpart, so an agent can separate it from render_download or render_unshare without opening another 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?

Gives real usage conditions: 'ask the user before sharing and return the url to them', and clarifies that listed=True merely asks for gallery inclusion subject to operator review. It stops short of explicitly routing between this tool and siblings like render_download or render_final, so 4 rather than 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?

Annotations already declare readOnly/idempotent/non-destructive; the description adds behavior beyond them: the status value set, that eta.human includes queue wait, that Blender warnings surface here, that failures return the error with a log tail, and what happens when job_id is omitted. It never states scoping limits like rate limits or how long jobs are retained, so it stops short of a 5.

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 dense sentences, front-loaded with the returned fields before moving to routing and the empty-arg case. No filler, though the return-field enumeration is long and partially duplicated by the schema.

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 shape need not be documented, and for a single optional-parameter read tool the description covers the remaining gaps: field meanings, failure output, the no-arg listing behavior, and the sibling to use for link delivery.

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 100%, so the baseline is 3, but the description meaningfully adds beyond it: empty job_id lists the key's recent jobs and still-kept scene_ids, and job_id format (j_..., split finals as b_...). It does not define the queue-wait or ETA computation windows, which are only implied.

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 ("Check a render job") and then enumerates exactly what it reports: status enum values, frames done, ETA, files ready, warnings, error log tail. An agent can distinguish it from render_info, render_download and render_cancel without opening any 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?

States the primary use case ("report progress to the user") and explicitly names the alternative for a different need: render_download(job_id, wait_seconds=45) "waits and returns the links in one call." It also spells out the no-job_id branch — listing recent jobs and retained scene_ids to resume earlier work in a new conversation.

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?

Far exceeds what annotations convey (destructiveHint/idempotentHint are just hints). It enumerates exactly what is destroyed (page URL, image/video copy, shared script, shown request), states the action is irreversible and that re-sharing produces a new URL, clarifies job files survive, and specifies the authorization requirement plus the not_found outcome.

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?

Dense but front-loaded: the action comes first, then effects, then irreversibility, then scope limits and error behavior. Every clause carries information an agent needs before calling a destructive tool.

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?

With an output schema present, return values need no explanation, and the description covers destruction scope, reversibility, auth, side effects on other artifacts, and the failure case. Nothing material 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 coverage is 100% and the schema already explains job_id formats (j_..., b_...) and where it comes from. The description adds nothing about the parameter, so the baseline 3 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?

States a specific verb+resource ('Take down the public share page of a job') and explicitly ties it to the sibling that created it (render_share). An agent can distinguish it from render_share, render_cancel, and render_status without opening any 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?

Gives clear context: this undoes render_share, only the key that shared the job can do it, and a job without a share page returns not_found. It also clarifies that the job's own files are not affected. It stops short of explicitly naming an alternative or a 'when not to use' case beyond the not_found condition.

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?

Annotations cover the safety profile, and the description adds genuine operational context: runtime and no-GPU cost, that missing linked files render pink, and that the call emits a reusable scene_id. It never explains why readOnlyHint=false (that the call uploads/materializes the scene), which is the one behavioral trait an agent might misread from 'Read'.

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?

Purpose is front-loaded in the first clause and every sentence carries weight. The long enumeration of returned fields is informative for selection but partly redundant given an output schema exists.

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?

With a rich schema, annotations, and an output schema, the description covers purpose, cost, usage conditions, and cross-tool chaining. The only uncovered element is the non-read-only nature implied by readOnlyHint=false, which the 'Read' framing leaves slightly ambiguous.

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 100%, so the schema already documents all five parameters, including the scene_id reuse semantics. The description's note about passing scene_id to render_preview/render_final duplicates what the schema's scene_id description already states, adding no new parameter-level meaning. Baseline 3 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?

States a specific verb+resource ('Read a Blender scene') and enumerates exactly what is inspected (cameras, frame range/fps, resolution, objects, lights, materials, animation, missing linked files). It is plainly distinguishable from the render_* siblings because it explicitly says 'without rendering (a few seconds, no GPU time)'.

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 concrete when-to-use conditions: 'a .blend you did not write, or to check what a bpy script built', and names the downstream alternatives (render_preview, render_final) that consume its scene_id. It does not explicitly route away from siblings like scene_edit when mutation is intended, so no full when-not guidance.

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