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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description is free to add the operationally important context it does: results carry a 'polyhaven:<id>' spec, size in metres, and entry file, and the '@2k' suffix changes texture resolution (1k default). This is behavior an agent cannot infer from the annotations or schema.

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, then usage, then result shape, then the scene-script API in a logical order with zero filler. It is dense and runs long in a single block, and some of the jr_assets API detail arguably belongs with the consuming tools, but every part is actionable.

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, yet the description still summarizes the return contract (id spec, size in metres, entry file) and shows the full search-to-render workflow. An agent has everything needed to search and to use the results 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 100%, so the 'kind' and 'query' documentation baseline is 3; the description goes further by showing worked query examples and, more usefully, the '@2k' resolution modifier that governs how the returned id is consumed downstream. It adds real semantics but not per-parameter edge cases.

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 by words'. It is plainly distinguishable from the render_* siblings, which produce output rather than locate input assets.

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 the alternative runtime path: 'to furnish a scene without uploading files; no GPU time', and gives a concrete when-to-use scenario ('For product shots of something the user has no model for') with the exact follow-up call to render_preview. When-to-use and the alternative are both spelled out.

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 cover readOnly/idempotent/openWorld/non-destructive, so the bar is lower, and the description still adds real behavioral context: credit expiry (14 days), the once-per-card 400 JPY grant, prepaid charging rates (previews free to 2 GPU-min/day, finals 0.1 JPY per GPU-second), and a tell_user relay directive that appears nowhere in structured fields. There is a mild tension between readOnlyHint=true and the topup_yen path that creates a Stripe checkout link, but the description frames it as link generation with no charge, so it is not a clear contradiction.

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 body is effectively one enormous sentence dense with nested parentheses enumerating the pricing ladder, expiry windows, and offer flags. It is front-loaded with the core purpose, but the run-on structure makes it hard to scan and several clauses (deposit mechanics, per-second rates) are crammed together rather than separated.

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 not be explained, and the description still covers the operational rules an agent needs: what is reported, the topup threshold, credit expiry/reset, and the tell_user relay. It is close to complete for a one-parameter tool; only the read-only-vs-checkout tension is left unaddressed.

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 parameter is fully documented in the schema, so the baseline is 3. The description contextualises the topup path (creating a checkout link) but adds no syntax or format meaning beyond what the schema already 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?

The description states a specific verb+resource ('Check what this key can still render for free and its credit'), then catalogues exactly what is reported: free GPU time, balance in yen, price per GPU-second, pending checkout link, and card/autocharge offers. It is clearly a billing/quota tool rather than a renderer, so an agent can place it against the render_* siblings. It stops short of naming any sibling or exclusion 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 implied rather than stated: checking credits/balance is the obvious 'use' and the schema's topup_yen documents the one conditional action. There is no explicit when-to-use vs when-not, no prerequisites, and no reference to alternatives, so guidance is only adequate.

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 the destructiveHint/idempotentHint annotations: it details that queued frames are dropped, already-rendered frames are charged and stay downloadable until expiry, held GPU time is returned, cancellation is irreversible, terminal jobs return unchanged, and assembling jobs cannot be stopped. It also states the auth boundary (only the owning key; otherwise not_found), which annotations do not cover.

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 and scope, then presents effects and edge cases in a logical sequence. It is on the longer side with some mild redundancy around irreversibility, but nearly every clause carries an edge case the agent needs.

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 single-param destructive mutation with an output schema and annotations already present, the description fills every remaining gap: side effects, billing, reversibility, idempotent terminal-state behavior, and permission boundaries.

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% for the single job_id parameter, so the baseline is 3, but the description adds the authorization constraint ('Only the key that started the job can stop it; any other job_id returns not_found'), which is behavioral meaning the schema does not carry.

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 ('Stop a queued or running render job of this key') and immediately distinguishes scope by naming the job id formats (j_..., b_...) and the part-job behavior. An agent can tell this apart from render_final/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 operating context: use it to stop a queued/running job, call render_final again to re-render, and 'Ask the user before cancelling a render they asked for.' It does not explicitly contrast against alternatives like render_status or render_final beyond the re-render note, so it stops short of full when/when-not routing.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds context the annotations cannot: artifacts are written to a local directory (~/janction-render/<job_id> by default), local paths are returned, and a positive wait_seconds blocks until the job finishes. It does not describe behavior when the job is still unfinished with wait_seconds=0, or download size/limits.

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?

Roughly three compact sentences, front-loaded with the action and destination before the option list; every sentence carries information. Minor awkwardness in the 'only picks the files' phrasing and the inline enumeration, but 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 return values need not be spelled out, and the schema plus annotations cover parameters and safety. What remains thin is the unfinished-job case (behavior when wait_seconds=0 and the job is not done) — otherwise the definition is sufficient to call the 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?

Schema description coverage is 100%, so all four parameters are already documented — the baseline is 3. The description mostly restates the enum values and the out_dir/wait_seconds defaults, adding only the rationale for 'mp4' ('to skip hundreds of frames'), which is a modest value-add beyond the 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+resource ('Download a job's files') plus the destination ('out_dir, default ~/janction-render/<job_id>') and the return ('local paths'). It is unambiguous among siblings such as render_preview, render_final and render_status, which produce or inspect jobs rather than retrieve their artifacts.

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 selection guidance for the 'only' mode, including the condition for the most important case ('mp4' — use when the user wants the video, to skip hundreds of frames), and explains the wait_seconds timing tradeoff. It does not, however, state when to prefer this tool over render_status/render_preview for checking job state, so there is no explicit exclusion.

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 true and destructiveHint false. The description adds rich behavioral context: no GPU time consumed, measured vs preliminary estimates, calibration.final_path_measured semantics, splitting advice, and the consequence of a false preliminary flag. This far exceeds what annotations provide.

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 information-dense and front-loaded with the key outputs. It is a single long paragraph but every sentence carries useful signal. Slightly verbose but appropriate for the complexity of the 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?

Given 10 parameters, no required params, full schema coverage, and an output schema present, the description covers the essential behavioral context: what the estimate returns, when to call it, how to interpret preliminary results, and when to split jobs. Nothing critical 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 all 10 parameters are already documented in the schema. The description adds marginal semantic value by explaining what the estimate does with scene_id and what calibration output means, but it doesn't add parameter syntax beyond what the schema already provides. 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 (Estimate) and resource (a render) and immediately specifies the output signals: GPU seconds, queue wait, human-readable wall-clock text, and quota fit. Clearly distinguishable from render_final, render_preview, and the other 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?

Explicit when-to-use guidance: 'Call it before render_final 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.' It also names the alternative (render_final) and gives concrete thresholds and exclusion conditions.

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 mark this as non-read-only, non-idempotent, open-world, and the description adds far more: per-call frame limits (3,000; 240 as parts under one job id), resolution caps on free vs prepaid, pricing (100 JPY free credit, 400 JPY after card save, 0.1 JPY/GPU-second), file deletion windows, chunk-and-join behavior, and an explicit 'ask before a render the free time does not cover.' This is unusually rich behavioral context.

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 estimate-first rule are front-loaded, and nearly every clause carries operational weight (limits, pricing, workflow). However, it is a single dense block that mixes workflow, pricing, and parameter notes; splitting into short labeled segments would improve scanability.

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, open-world, paid-render tool with an output schema, the description covers the full lifecycle: when to estimate, how to render, how to poll (render_status), how to download (render_download), cost limits, and deletion policy. Return values need not be explained since output_schema 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 100%, so the baseline is 3; the description earns an extra point by adding cross-parameter semantics not obvious from the schema, e.g. preset='product'|'turntable'|'animation' filling settings, output format list, assets ('polyhaven:<id>'), and using scene_id from render_preview vs scene_path/script/url. It mostly reinforces schema content rather than adding novel syntax 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?

Opens with a specific verb+resource+context: 'Render the final frames or video of a Blender scene on cloud GPUs, after the user approved a preview.' This clearly distinguishes it from render_preview (which happens before approval) and from render_estimate. An agent can select it without opening the 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 states when to call render_estimate first (uncertain time, >24 frames, >720p, user asks duration) and 'tell the user.' It also prescribes the animation workflow ('keep the approved engine/look, test 10 contiguous final-path frames, then estimate again') and routes to render_status / render_download afterwards. Alternatives and conditions are named.

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 cover read-only/idempotent/non-destructive), it discloses cost and resource behavior ('no GPU time, no charge'), the auth source (JANCTION_RENDER_API_KEY or ~/.janction-render.json, auto-provisioned), and rate limiting with the concrete recovery action ('a 429 response carries retry_after_s, wait that long'). It also explains how to interpret the gated state and diagnose.tell_user.

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 action and the cost reassurance, and nearly every clause carries information an agent needs. However, it is delivered as one dense ~120-word paragraph mixing purpose, routing logic, auth, rate limits and diagnosis, which would scan better broken into discrete statements.

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 documented exhaustively, yet the description goes further and tells the agent how to read the important fields (workers_available, gated, gate) and how to relay diagnose.tell_user to the user. Nothing an agent needs to call this 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter surface for the description to clarify, and it correctly spends its words on return-value interpretation instead.

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 scope: 'Check the connection and the service before rendering', then enumerates exactly what is reported (server URL, GPU worker health, queue length, expected wait, key usage). It is clearly a service-level diagnostic rather than a job-level one, but it never names the adjacent sibling render_status, so an agent must infer the boundary with that tool.

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 triggering conditions ('before the first render', 'when renders seem stuck') plus a decision rule ('to decide whether to route a render here'). It also names the alternative path implicitly by explaining that workers_available > 0 vs gated determines whether a preview is worthwhile. This is textbook when-to-use 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?

Annotations give the safety profile (readOnly=false, openWorld=true, idempotent=false, non-destructive) but the description discloses behavior the annotations cannot: a critic verdict ok/check/fix with fix code, final_estimate and quota_left_today surfaced before asking to proceed, and a script that raises returning a failure with the offending line and nothing rendered. It also states resolution caps and the tiling economy (1-4 frames for the cost of one 720p frame).

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, then when-to-use, then when-not-to-use and limits, which is good ordering. It is on the long side and the multilingual trigger phrases add bulk, but nearly every sentence carries routing or behavioral information an agent needs, 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 24-parameter zero-required tool with no output schema, the description still explains the salient returns (critic verdict, final_estimate, quota_left_today, failure-with-line), the limits, the input-source options and the follow-up workflow. Nothing an agent needs to call it correctly appears 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 modestly exceeds it by mapping preset values to concrete behavior ('product' | 'turntable' | 'animation' set camera, light, backdrop and frames) and by summarizing the four scene-source channels (scene_path, scene_script, scene_url, scene_id). It otherwise defers to the per-parameter docs ('Other options are explained on each parameter'), which is appropriate but not additive.

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+medium: 'Show what a Blender scene looks like: a fast, low-cost preview render on a cloud GPU, back as an image in seconds.' Scope, cost class and output form are all named, and the preview-vs-final distinction is drawn against the sibling render_final implicitly but clearly.

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 ('after writing a bpy script', 'I have no GPU') and when-not-to-use ('editing a scene open in the user's Blender belongs to a local Blender MCP', a single still on an NVIDIA machine renders faster locally), plus the intended workflow (apply fixes and preview again before any final render). Alternatives are named with the condition that selects them.

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: it runs on a cloud GPU, costs the same as one preview, enumerates the concrete checks performed (texture files, hidden objects, camera inside geometry, framing, exposure, light), returns fix code per problem, and returns the 4 views tiled in one image. The annotations only carry the generic openWorld/non-idempotent profile, so the description is doing real work here.

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 and output, then usage triggers, then the sibling routing rule. Every sentence carries information, but the block is long and the multi-language example strings ('モデルを確認して') add bulk without adding much decision value for an English-speaking agent.

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 11-parameter, zero-required tool with no output schema, the description covers what matters: the return shape (pass/warning/fail, score, checks, fix code, tiled image), the input alternatives, cost, and the boundary of what the checks can judge. Nothing an agent needs to invoke it 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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: it frames scene_path/scene_script/scene_url/scene_id as four alternative ways to supply the same scene ('Give the scene as ...'), which the flat schema never states. It also notes environment affects lighting choice. Minor gap: it does not explain orbit_distance/orbit_elevation semantics.

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 (check/review) and resource (a 3D model or generated Blender scene), and specifies the exact method: a 4-view turntable under neutral studio light returning pass/warning/fail, a score, and the checks run. It explicitly distinguishes itself from the sibling render_preview by naming the camera/lights case that selects the other tool.

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 when-to-use triggers ('after writing a bpy script, generating or converting a model ... before showing the result to the user or rendering a final'), the loop to follow ('apply the fixes and call it again'), an explicit limitation ('the checks cannot judge whether the shape matches the request'), and the alternative for camera-based shots (render_preview). Nothing 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 declare mutation and open-world traits; the description goes well beyond them by disclosing page durability beyond job file expiry, the operator review gate for gallery listing, the consent requirement before publishing, and the ownership precondition on the key. These are exactly the non-obvious traits an agent needs before performing an irreversible public action.

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 and the page contents before the operational caveats. It is long and clause-heavy in the opening sentence, but nearly every clause adds a fact (script gating, gallery review, durability, auth) rather than 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?

Although an output schema exists, the description still states that a URL is returned, and it covers durability, expiry, consent, ownership, and gallery review — everything an agent needs to call this correctly and safely. No material gap remains for a six-parameter public-publishing tool.

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 a 3 is the floor, and the description beats it: it clarifies that include_script controls whether the bpy script appears, that prompt is rendered as 'what the user asked the agent', that title/note are shown on the page, and that listed only requests gallery placement subject to review. Marginal additions are modest since the schema already carries much of this.

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') and enumerates exactly what the page contains, so the agent can distinguish it from render_unshare (removal) and the render_* job tools. An agent can select this tool without opening the 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 preconditions ('Only the key that rendered the job can share it'), the inverse tool for teardown ('until render_unshare'), the semantic difference of listed=True including operator review, and a direct behavioral instruction ('ask the user before sharing and return the url to them'). This is when-to-use, when-not-to, and alternatives all in one.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds genuine behavioral context: the enumerable status values, that eta.human includes queue wait, that Blender warnings and a log tail are surfaced on failure, and that omitting job_id switches to a listing mode.

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 dense sentences, front-loaded with the returned fields and then the usage/fallback modes; nothing is padding. The long field enumeration is justified but makes the second half slightly heavy.

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 documentation is not required, yet the description still sketches the response shape, covers the failure path and the no-argument listing path. Nothing an agent needs to invoke it 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 100% for the single job_id parameter, and the schema already documents its origin (j_.../b_...), key scoping, and the empty-string listing behavior. The description restates the empty case without adding new syntax or constraints, so 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 and resource ('Check a render job') and enumerates exactly what is reported: status enum values, frames done, ETA, files ready, warnings, error tail. It is clearly distinguishable from siblings like render_download or render_estimate, which it names as the follow-up step.

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 ('to report progress to the user'), what to do next ('call render_download once status is done'), and defines the no-argument case ('lists this key's recent jobs and the scene_ids still kept') including the motivating scenario of resuming 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?

With destructiveHint=true already in the annotations, the description still adds substantial value: it enumerates exactly what is destroyed (page URL, its copy of the image/video, shared script, shown request, gallery listing), states irreversibility and that re-sharing creates a new URL, clarifies job files are untouched, and documents the auth constraint (only the sharing key) plus the not_found case. The idempotentHint is consistent — repeat calls change nothing further.

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 destructive effect is front-loaded in the first sentence, followed by consequence, irreversibility, scope of side effects, and error case in compact declarative sentences. No filler or repetition; every sentence carries operational 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?

An output schema exists so return values need no explanation, and the annotations cover the safety profile. What remains for an agent to call this correctly — what gets deleted, that it can't be undone, whose key is required, and what happens with no share page — is all present.

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 job_id field description is already detailed (j_.../b_... prefixes, which key's jobs, render_status behavior), so the schema does the heavy lifting. The description adds only the constraint that the caller must hold the key that created the share, which is auth context rather than parameter syntax. 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?

The description opens with a specific verb+resource ('Take down the public share page of a job') and names the sibling that creates that page (render_share), letting an agent separate it from render_share, render_download, or render_status without reading 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?

It establishes the precondition clearly ('a job made with render_share') and the failure mode ('a job without a share page returns not_found'), and the job_id schema text explains which identifier to supply from render_preview/render_final. It stops short of an explicit when-to-use/when-not-to pair or a pointer to the sharing sibling for the reverse action.

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 idempotentHint=true and destructiveHint=false; the description adds genuinely useful cost/behavior context ('a few seconds, no GPU time') and clarifies that this is a non-rendering inspection step, which reconciles the readOnlyHint=false annotation with what the agent sees. It does not cover auth requirements, quotas, or failure modes, so 4 rather than 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 sentences, front-loaded with the verb and the no-render constraint, then the payload list, then the routing rule. Every clause carries information; nothing is padded or repeated.

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 no explanation, and the description still sketches what is inspected. Combined with the scene_id hand-off instruction, an agent has everything needed to call it and chain it into rendering, though it says nothing about what happens when the scene fails to load or has unresolvable assets.

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 per-parameter text is unusually detailed (Blender API notes, asset resolution rules, jr_assets helpers), so the schema does the heavy lifting and baseline is 3. The description only restates the scene_id reuse rule that the schema already documents, adding no new parameter-level meaning.

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 ('Read a Blender scene') and enumerates exactly what is returned: cameras, frame range, fps, resolution, objects, lights, materials, animation state, missing linked files. That enumeration distinguishes it cleanly from render_preview/render_final, which produce images rather than metadata.

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 when-to-use conditions ('a .blend you did not write', 'check what a bpy script built') and an explicit alternative/sequencing rule: pass the returned scene_id to render_preview and render_final instead of re-uploading. Nothing about tool selection 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.