Sceneplane

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

The description goes well beyond the annotations by explaining the URL mechanics (credential in query string, no headers), verifiable response fields (byte count, SHA-256), precise 401/404/403 semantics, and the edge-protection User-Agent pitfall. This is exactly the kind of behavioral context that annotations cannot convey.

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, followed by valuable operational details and a clear error-code warning. The anecdote about the 31-artifact download pass is slightly verbose but reinforces the User-Agent warning; overall every sentence contributes meaningful 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 no output schema, the description compensates by naming the key response elements (byte count, SHA-256) and detailing error behavior. It does not state the URL expiration time or the full set of metadata fields, but the essentials for calling and using the result are 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?

The input schema has 100% description coverage for the single parameter, artifactId, so the schema already defines the parameter. The description adds no additional parameter-level meaning, which matches the baseline of 3 for high schema coverage.

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 clear verb and resource: 'Get artifact metadata plus an expiring authorized download URL.' This is much more specific than the title, and the mention of metadata plus a download URL distinguishes it from siblings like artifacts_list. An agent can tell exactly what this tool returns.

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?

The intended use is implied by the purpose statement, and there is useful client guidance about User-Agent handling and error codes. However, it does not explicitly say when to choose this tool over sibling tools like artifacts_list, nor does it state when not to use it.

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, so the description focuses on what annotations cannot say: results are newest-first, each entry carries its producing revision, and the payload does not include download URLs. Pagination behavior (the cursor/nextCursor cycle) is only implied via the schema, which keeps it 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 tight sentences, front-loaded with the action and scope, then the recoverability note, then the pointer to artifact_get. Every clause carries information an agent would otherwise have to infer.

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 annotations covering safety, a full output schema covering return shape and nextCursor, and 100% parameter coverage, the description only needs to supply ordering, filtering, and cross-tool routing — all of which it does.

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 five parameters are already documented including kind examples and the cursor's row-offset semantics. The description only restates that filtering is by revision or kind, adding no format or constraint detail beyond the schema. 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?

Specific verb and resource ('List a project's artifacts') plus the content types it covers (renders, exports, previews, audio), the ordering (newest-first) and the filter axes. It is immediately distinguishable from artifact_get, which the description explicitly defers download URLs to.

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 routes the agent away from two siblings with stated conditions: download URLs come from artifact_get, and recovering a lost artifact id does not require walking jobs_list. There is no explicit 'when not to use' framing, but the alternatives are named with reasons, which is more than most definitions do.

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 (non-readOnly, openWorld, non-idempotent, non-destructive), and the description adds the costly details they don't: this consumes external provider credits, each provider requires an integrations_set token first, and output is one freestanding object per task. The provider-capability matrix and the poll→import chain are exactly the context needed before invoking.

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 disambiguation and the authorization gate, then capabilities, then the follow-up workflow. Dense but every sentence carries operational information; nothing repeats the schema or annotations.

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 credit-consuming external generation call with three params and an output schema, the description covers cost, auth prerequisites, argument/provider compatibility, scope constraints, and the full downstream workflow. Nothing an agent needs to call 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 baseline is 3, but the description adds real semantics the schema lacks: which providers accept imageUrl versus prompt-only (hyper3d), and the constraint that prompt should describe a single freestanding asset. Provider-token requirements further constrain the enum values.

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 ('Start a text/image → 3D generation') and immediately distinguishes itself from the catalog-search siblings ('External generation, not a catalog search'). An agent can tell it apart from assets_search and asset_import 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 gating condition ('start only when the user has chosen or already authorized this generation path'), an explicit prohibition ('Do not spend provider credits to discover candidate assets'), and named alternatives for the excluded cases (scene ops for ground planes/assemblies, duplicating for reuse). It also routes to the follow-up tools: asset_generate_status then asset_library_import.

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 and idempotent behavior, so the description's extra context about needing the same provider and subscriptionKey and the next import step adds useful behavioral boundary. It accurately reflects a non-destructive polling operation and has no contradiction with 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?

Two short sentences deliver the polling purpose, the required identity context, and the success-path next step with zero filler. The content is front-loaded and every clause earns its place.

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 two-parameter, read-only polling tool with a full output schema, the description is complete: it explains what to pass, what to wait for, and what to do after. The agent has all the context needed to call the tool correctly and continue the workflow.

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 description does not need to re-document the parameters. It reinforces that provider and subscriptionKey should match the originating generation request, but this mostly restates the schema's existing descriptions.

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 action, 'Poll a generation', and ties it directly to the output of asset_generate_3d, so an agent knows exactly what this tool is for. It also distinguishes the tool from the generation and import siblings by framing it as the middle polling step of the workflow.

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?

The description states the precondition (generation started by asset_generate_3d with the same provider and subscriptionKey) and gives a clear transition condition to asset_library_import when status=done. It does not explicitly list alternatives or when not to use the tool, but the workflow condition is specific enough to select it correctly.

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 the safety profile (readOnly=false, destructive=false, openWorld=true), and the description adds genuinely new behavior: asynchronous job handle return, job_wait/job_get for resolving success/errors, REVISION_CONFLICT rejection on stale bases, and that quarantined/rejected uploads cannot be imported. This is rich context beyond the structured fields.

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?

Four tight sentences, each carrying distinct information (purpose, prerequisites/alternative, error condition, return handling). Front-loaded with purpose and prerequisites; only minor density cost from packing routing and error semantics together.

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, the description need not detail return values, yet it still tells the agent the return is a job handle and how to resolve it. Combined with annotations, the error path, prerequisites, and alternative routing, an agent has everything needed to invoke it 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 baseline is 3, but the description adds cross-parameter semantics by tying baseRevisionId to the REVISION_CONFLICT outcome and the linear-history rule. It does not restate per-parameter detail, but it meaningfully frames how the inputs interact.

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 (Import), resource (validated uploaded asset), and target (current project head as a new revision). It also explicitly names the sibling it is not (asset_library_import), so an agent can distinguish it 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 an explicit prerequisite chain (upload_create then upload_complete before this tool) and an explicit alternative with its triggering condition (library slugs or generated provider models -> asset_library_import). 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?

Beyond annotations it discloses source-specific side effects: HDRIs become the world environment, models join the scene, texture sets create a wired PBR material, and Sketchfab requires an org token. It doesn't spell out that replacing the world environment is the destructive aspect flagged by destructiveHint, nor what a job handle implies for 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?

Front-loads what it does and returns, then proceeds source by source. Dense but every clause carries operative information; only the nested parentheticals make it slightly 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?

Covers the high-risk decisions for a 10-parameter mutating import: source, slug format, sizing, auth, and revision targeting. An output schema exists so return values needn't be described, and the 'job handle' mention is enough; minor gaps are the enum-only parameters.

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 only 30%, and the description compensates for slug (per-source semantics), targetSize (with concrete meter anchors), applyToObjects, and baseRevisionId indirectly, but resolution, materialName, and type go unexplained in both places. Strong on the hardest parameters, silent on the rest.

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 a library asset into a project as a new revision') and adds an outcome ('Returns a job handle'). It does not distinguish itself from the sibling asset_import, which is the one ambiguity an agent would still need to resolve elsewhere.

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 precondition ('Use only after the user has chosen the asset/action or delegated source selection') and names the discovery alternatives (search, asset_preview) that present options without importing. It lacks an explicit when-not relative to asset_import, but the selection ritual is clear.

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 read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable behavioral detail: it returns an inline image, requires exact case-preserved slugs, and crucially states 'An unavailable preview is not an invented image' to prevent hallucination.

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 workflow guidance, slug format, and failure behavior. Every sentence earns its place, though the second sentence is somewhat long and agent-instructional.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple preview tool with full schema coverage and rich annotations, the description covers purpose, return format (inline image), slug requirements, and failure behavior. It is nearly complete, though it doesn't specify image dimensions or error response format.

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 baseline is 3. The description adds meaning beyond the schema by specifying that slug is 'exact, case-preserved' and that it can be a 'Poly Haven slug or Sketchfab uid', which clarifies format and source mapping.

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 (preview), resource (asset's thumbnail), output format (inline image), and timing (before importing). This clearly distinguishes it from sibling tools like assets_search, asset_import, and asset_generate_3d.

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 to use it before importing and for candidate suggestions with source/license, offering reuse/adapt/build. It does not name explicit alternatives or when-not-to-use cases, but the context is clear enough for an 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 establish read-only, idempotent, non-destructive behavior, lowering the burden on the description. The description adds useful behavioral context by mentioning per-category counts and that categories can be passed as search queries, going beyond what the annotation block alone provides.

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 with no filler: the first states the core action and output characteristic, and the second provides usage guidance for the related sibling tool. Every sentence earns its place.

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 one required enum parameter, full schema coverage, an output schema, and safety annotations, nothing needed to call the tool correctly is missing. The description also covers the likely next step by connecting categories to assets_search.

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 single 'type' parameter is fully documented in the schema with an enum and a clear description, so the description doesn't need to add much. The phrase 'for an asset type' maps to that parameter but adds no format or value detail 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?

The description states a specific action ('List'), a concrete resource ('Poly Haven categories'), and a scope ('for an asset type'), plus a distinguishing detail ('per-category counts'). It also references assets_search, making clear this tool is for browsing the category taxonomy rather than searching 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?

It gives a clear follow-up directive: 'Pass a category as the assets_search query to filter,' which tells the agent when to hand off to assets_search. It does not explicitly enumerate exclusion conditions like 'use only when you need categories,' so the guidance is strong but not fully explicit.

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 readOnlyHint/idempotentHint/openWorldHint: polyhaven needs no setup (CC0 HDRIs, textures, models), while sketchfab requires integrations_set provider=sketchfab for import, is limited to type=model, and each hit's license must be honored. Setup/auth and licensing constraints are exactly what annotations cannot convey.

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 purpose in the first clause and every sentence carries routing or constraint information. It is a dense paragraph that folds workflow coaching into one long run of clauses, which costs a little scannability but adds 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?

With an output schema present, return format needn't be explained, and the description still notes hits carry source/license. All decision-relevant context — default source, setup requirements, license obligations, downstream tool — is present; only minor detail like result paging is left implicit.

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 baseline is 3; the description still adds meaning the schema does not — that source=polyhaven is the default with no setup, and that sketchfab only works for type=model. It does not expand on query/limit semantics, so it sits just above baseline.

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+scope ('Read-only search of existing 3D asset catalogs') and names the downstream consumer ('returns real slugs for asset_library_import'), which distinguishes it from asset_library_import and asset_generate_3d. An agent can route correctly 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 states when to search (no explicit/prior source choice; before building), what to do with results (preview a few with source/license, then ask reuse vs adapt vs build), and the exclusion ('Honor explicit from-scratch choices'). This is a genuine decision procedure, not implied 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?

Discloses key non-obvious behavior: output is deterministic given the same payload and seed, and the result is delivered as an audio_wav artifact with a download URL in job_get. Since no output schema exists, this is valuable; annotations only provide generic hints and nothing contradicts the description.

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-load the purpose and parameter categories, with no filler. The lists are compact, and each sentence adds a distinct fact: what is generated, determinism, and how the artifact is delivered.

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, no-output-schema job tool, it covers the typical workflow: artifact and download URL in job_get, parameter scoping by audio kind, and deterministic guarantees. It could say more about the async job lifecycle, but the job_get reference is likely sufficient.

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?

With only 45% schema description coverage, the description compensates by grouping the BGM parameters (bpm, bars, root, scaleMode, voice) and linking presets to sfx/jingles and seed to determinism. It doesn't exhaustively define every enum value, but it clarifies the main parameter relationships.

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 action (synthesize deterministic 16-bit PCM WAV), names the output artifact, and enumerates the three audio kinds: sfx presets, win/lose jingles, and loopable BGM. This clearly distinguishes it from asset_generate_3d and other resource-generating 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?

The description gives concrete use cases and parameter groupings: sfx presets, jingles, or BGM loops, and notes exact-bar looping. It stops short of explicitly naming when-not-to-use alternatives, but the context is clear enough for an agent to select it for game-audio generation.

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, and the description adds substantial context: ownership/checksum constraints, the exact measurement set, preview audio return behavior, and explicit limitations. 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?

Two sentences with no filler: the first front-loads the core action, resource, and measurement list; the second compactly covers preview behavior and non-goals. Every sentence earns its place.

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 purpose, measurements, preview behavior, and non-goals despite having no output schema. The main gaps are the undocumented previewOffsetSeconds parameter and lack of return-structure detail, but for a read-only inspection tool with strong annotations this is nearly complete.

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 only 33%, so the description must compensate. It clarifies previewSeconds ('returns up to three seconds as playable MCP audio') but leaves previewOffsetSeconds entirely unexplained in both the schema and the description, leaving a meaningful parameter without semantic guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Measure') and resource ('checksum-verified owned PCM16 WAV'), then enumerates concrete metrics such as peak/RMS/DC, clipped samples, and loop-boundary differences. It also explicitly contrasts with non-goals ('does not listen, judge sound quality, measure LUFS or certify a seamless loop'), making it clearly distinguishable from siblings like audio_generate and artifact_get.

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?

Provides clear context: this tool is for measuring sample-level properties without Blender compute, and it explicitly lists exclusions such as not judging sound quality or measuring LUFS. However, it does not name a specific sibling tool to use instead, so the guidance is strong but not fully explicit.

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=false, destructiveHint=false, idempotentHint=false, so the description doesn't need to restate those. It adds useful behavioral context: the permission requirement (owner/admin) and the organization defaulting behavior. It doesn't mention what the response contains, but an output schema exists, so that burden is reduced.

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?

One sentence, front-loaded with the action and resource, then the two most important usage constraints. 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 create tool with an output schema and full parameter documentation, the description covers the key non-obvious context: permission requirements and organization defaulting. It doesn't explain what 'isolated' means or what happens on failure, but those are minor given the output schema and annotations.

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 schema already documents both parameters. The description adds the organization defaulting behavior, which clarifies when organizationId can be omitted, but it doesn't add much beyond that. 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 states a specific verb ('Create') and resource ('new isolated Blender deployment'), and the title reinforces it. It distinguishes from siblings like deployment_update and deployment_delete by focusing on creation, and the 'isolated' qualifier adds specificity.

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?

The description gives clear context: requires owner/admin in the target organization, and defaults to your only organization when you have exactly one. It doesn't explicitly name alternatives or when-not-to-use, but the permission and default behavior guidance is strong enough to guide correct invocation.

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 signal destructive intent, but the description adds materially more: permission requirements, the empty-deployment precondition, and the refusal behavior when projects still exist. This tells the agent what to expect beyond the binary destructive flag.

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 with no filler. The most important constraint (EMPTY) is front-loaded, and the precondition/refusal behavior is compressed into the second 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?

Given only one parameter, full schema coverage, an output schema, and annotations that cover destructive behavior, the description covers all necessary operational context: permission, precondition, and failure mode. Nothing essential is missing for an agent 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 100%, with the single deployment parameter fully described as 'deployment slug' in the schema. The description adds no extra parameter details, but for a single self-explanatory parameter, the baseline of 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 action ('Delete') on a specific resource ('deployment') with a critical qualifier ('EMPTY'), making its purpose unmistakable. It distinguishes itself from related deployment operations like deployment_create and deployment_update.

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?

Provides explicit preconditions: only owner/admin, only empty deployments, and that projects must be deleted first. It doesn't explicitly name an alternative tool, but the guidance clearly tells when not to invoke this tool directly and what to do instead.

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 annotations (destructiveHint=true, idempotentHint=false) by disclosing partial-update semantics ('omitted fields remain unchanged'), the owner-only restriction on dangerousScriptingEnabled, plan/platform ceiling validation, policy version recording, and rejection of concurrent edits. This is exactly the behavioral context the annotations cannot carry.

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 omitted-fields rule, then routing guidance. Dense with no filler, but it packs many clauses into a single long paragraph, which slightly hurts 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 destructive 11-param mutation with an output schema, the description covers auth requirements, partial-update behavior, concurrency, validation, and even the return fields (policyVersion, scriptingEnabled). Nothing material 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 schema already documents all 11 parameters and the baseline is 3. The description still adds meaning not in the schema: omitted fields preserve current values, and only the owner may flip dangerousScriptingEnabled. That extra semantic is useful but limited in scope, so a 4 rather than 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?

States a precise verb+resource ('Change execution limits, approvals or scripting for an existing deployment') and explicitly carves out scope against siblings like deployment_update and deployments_list. An agent can distinguish it from the other deployment_* tools 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?

Names the alternatives and the conditions that route elsewhere: 'Use deployment_update to rename or enable/disable the workspace, or deployments_list to find its slug.' Also gives the prerequisite auth (owner/admin and deployments:admin). Explicit when-to-use and when-not.

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, so the safety profile is covered. The description adds useful behavioral context: the result is scoped to the account's accessible deployments, and the active deployment for other tool families can be switched via the ?deployment=<slug> query parameter.

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 with zero waste: the core operation and scope appear first, followed by the session/query guidance. Every sentence earns its place without repeating schema or annotation details.

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 zero-parameter, read-only list operation with an output schema and full safety annotations, the description provides the essential extra context: account scope and the deployment-switching mechanism. Nothing needed to invoke the 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?

The input schema has zero parameters, so the baseline is high. The description goes further by documenting an actionable URL-level switch, ?deployment=<slug>, which is not represented in the schema and is important for controlling which deployment subsequent tools act on.

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 object, 'List every deployment this account can access,' adding account-level scoping to the title. This makes it clearly distinct from deployment_create, deployment_update, and deployment_delete without needing to name them.

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 frames the tool as the way to enumerate all accessible deployments and connects this to the session-bound deployment concept, implying this list is used to discover the slug for other tools. It does not explicitly name alternatives, but the context is clear enough for an agent to select this tool appropriately.

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 flag destructiveHint=true and readOnlyHint=false, so the safety profile is known; the description adds real value beyond that by naming the required role/scope (owner/admin, deployments:admin for narrowed credentials) and the operational consequence of disabling. It stops short of covering reversibility or how partial updates interact with unmentioned fields, so it is strong but not exhaustive.

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, purpose front-loaded first, sibling routing second, return values last. Dense but every clause carries information; the permissions clause is slightly compressed ('for narrowed credentials') but not wasteful.

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 elaboration, yet the description still summarizes them. Combined with explicit permissions, side effects, and sibling routing, an agent has everything needed for correct invocation.

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 description still adds meaning: the `disabled` flag is tied to blocking new work, and the permission caveat hints at credential sensitivity. This is above the baseline 3 for fully documented parameters, though it does not explain the name/slug distinction beyond what 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 specific operations (rename, enable/disable) on a specific resource (existing deployment) and immediately scopes the side effect: 'disabling blocks new work'. An agent can distinguish it from deployment_create, deployment_delete, and deployment_policy_update 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 routes the agent to alternatives with the selecting condition: deployments_list to find the slug, deployment_policy_update for execution limits or scripting, deployment_create for a new workspace. 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 already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it mentions did-you-mean suggestions for unknown names, the extra node socket details, and the fact that it reads from a 'pinned Blender build' because the official API reference omits socket lists. This goes beyond the structured metadata without contradicting it.

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 dense but not bloated. Each sentence contributes: purpose, accepted input formats, unknown-name behavior, node-type special behavior, and the reasoning behind the node detail. The purpose is front-loaded in the first clause. Slightly long, but every part earns its place.

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?

The tool has moderate complexity (special node-type handling) but the description fully covers input scenarios and the extra node info. An output schema exists, so return format is presumably documented there. The description doesn't mention authentication or rate limits, but those are not implied as needed. An agent knows exactly when to call and what to expect.

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% (the single 'identifier' param is described simply as 'Exact Blender Python API identifier'). The description massively expands on this by specifying accepted formats (dotted identifiers, wildcards like 'X.*', '*' for top-level, node type names) and what each returns. This is exactly the value the description should 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?

The description states a specific verb and resource: 'Verify bpy signatures, properties, and enum values' — clearly distinguishing it from sibling tools like docs_bpy_search (which likely searches) and docs_manual_get (which fetches manual pages). It also gives concrete input examples ('bpy.types.Object', 'bmesh.types.BMEdge.is_manifold'), making the purpose unambiguous.

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?

The description explicitly says to use it 'BEFORE writing scene_script code', providing a clear workflow context. It also explains the special node-type query path that returns socket names and hidden sockets, which isn't obvious. However, it doesn't explicitly contrast with docs_bpy_search or state when to use that alternative, so it's clear but not fully explicit about when not to use it.

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 read-only, idempotent, and non-destructive behavior, so the description adds value beyond structured data by disclosing the UI-label alias behavior ('color ramp' finds ShaderNodeValToRGB) and ranking of results. It doesn't introduce any hidden side effects or contradictions.

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 efficient sentences with no filler. The core purpose and scope are front-loaded, examples are embedded compactly, and the special UI-label behavior is appended as a valuable clarification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only search tool with a fully documented 2-parameter schema and an output schema, the description covers purpose, query semantics, special matching behavior, and how results relate to a sibling tool. Nothing critical is missing for correct selection and invocation.

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 enriches the query parameter's meaning by showing that matching is not only over identifiers but also over node UI labels. It also implies the query string expects human-readable terms like 'subsurf modifier' rather than raw identifiers.

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: 'Keyword search over every documented bpy identifier'. It distinguishes itself from the sibling docs_bpy_lookup by explicitly positioning itself as the search step that feeds lookup, and from docs_manual_search by limiting scope to bpy API identifiers.

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 clearly indicates this tool should be used to find bpy identifiers, and that results are meant for docs_bpy_lookup. It provides concrete query examples and notes UI-label matching behavior, but it does not explicitly state when not to use it versus the manual search tools.

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 this tool safe (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds useful behavioral context beyond annotations by stating it retrieves the page 'in full' and by identifying the source and license (blender.org, CC-BY-SA 4.0), which is relevant for reuse.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single concise sentence contains the verb, resource, scope, and path source, followed by licensing information. No filler or redundancy; every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only tool with a rich output schema and complete annotations, the description fully covers what an agent needs: what it fetches, how to identify the resource, and the license terms. Nothing essential 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%, with the path parameter already documented as 'Manual page path returned by docs_manual_search.' The description reinforces this but adds no new semantic detail beyond what the schema provides. Baseline of 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 states a specific verb ('Fetch'), a precise resource ('one Blender manual page in full'), and the required mechanism ('by its path'). It also references docs_manual_search, which distinguishes it from sibling docs tools like docs_bpy_search and docs_operations.

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?

The description clearly implies the intended workflow: first use docs_manual_search to obtain a path, then call this tool with that path. It provides clear context but does not explicitly name alternatives or state when not to use it. No exclusions are given.

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 establish read-only, idempotent, non-destructive behavior. The description adds relevant behavioral context beyond that: full-text search, ranked results, snippets, and the recommended next step. There is 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 description is two sentences with the core action and scope front-loaded, followed by concrete output expectations and a routing instruction. Every sentence earns its place and there is no redundancy or 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 a low-complexity search tool, the description, full schema, and rich annotations cover the main invocation need: what to query, what to expect in return, and how to proceed. It is minimally incomplete only in not explicitly warning that Blender API/symbol lookups belong with docs_bpy_search.

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 schema fully documents both query and limit. The description adds no additional parameter-level meaning such as query syntax, ranking behavior, or limit tradeoffs; the baseline of 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 names a specific verb and resource ('Search the Blender user manual full-text') and narrows the purpose to conceptual questions about modifiers, shading, physics, animation, and constraints. This clearly distinguishes it from API-reference siblings like docs_bpy_search and from the read tool docs_manual_get.

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 clear context for when to use the tool: for conceptual manual questions, and it explicitly instructs the agent to follow up with docs_manual_get to read a result. It does not explicitly name docs_bpy_search as the alternative for API/symbol lookup, so it falls just 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 already declare readOnlyHint, idempotentHint, and non-destructive behavior, but the description goes further: it says the tool 'queues no job, spends no compute and changes nothing' and is 'always safe to retry, including after a transport-level error'. It also explains that schemas are introspected from the validator itself, so results exactly match what scene_apply accepts. This is rich behavioral context beyond the annotations and does not contradict them.

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 long but every sentence earns its place: the primary use is front-loaded, alternatives and exclusions are stated early, and each optional parameter's behavior is covered efficiently. The 'READ ONLY and free' safety note is a deliberate closing signal. No filler or redundant restatement of schema fields.

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?

The tool has six optional parameters, an output schema, and several sibling tools, but the description covers all necessary invocation patterns, special values, result formats, and the caveat about repeated-detail namespaces. It also explains the tool's cost/safety profile, which matters for an agent deciding whether to retry. An agent has everything needed to select and call 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: it explains op='guide' compatibility with older catalogs, what namespace='mesh' does, the caveat that repeated details live under object.radial_array rather than a 'pattern' namespace, and that search returns ranked matches. It also clarifies the format parameter's relationship to structuredContent, which adds real value for an agent choosing how to consume results.

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: 'Enumerate and inspect the validated operations scene_apply accepts'. It also distinguishes the tool from siblings by saying 'call this BEFORE reaching for scene_script' and noting most modeling does not need raw bpy, which separates it from the docs_bpy tools. No ambiguity about what the tool is for.

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 use the tool (before scene_script), when not to use raw bpy, and which sibling handles adjacent concerns ('validation is the separate scene_validate tool'). It also gives concrete conditional usage: guide=true for the guide, namespace for a namespace, search for ranked matches, op for a schema. This leaves little 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?

With annotations present, the description adds substantial behavior beyond them: selection is resolved against the exported revision before dispatch, the response enumerates selected objects by type, stale ids or empty matches fail loudly, surface-less curves are skipped and named, and the call returns a durable job handle producing an immutable artifact. This is far richer than the minimal annotation 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?

Core purpose is front-loaded in the first sentence, and the following sentences are information-dense rather than filler. However, the single long paragraph packs many distinct concerns (presets, selection, curves, job lifecycle) and is heavier than strictly necessary.

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 covers the mutation semantics, selection resolution, and job/artifact lifecycle for a complex 18-param tool. A few undocumented parameters (bakeSize, bakeObjectLimit, bakeOverflow) leave minor gaps.

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 only 50% across 18 params, but the description compensates well: it explains enginePreset's Y-up/scale behavior per engine (unity/godot/print/unreal), that print is ×1000 AND Z-up as a whole convention, and how selection/id staleness works. It leaves some params (bakeSize, bakeObjectLimit, bakeOverflow, format) unexplained, so shy 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 (export) plus the resource (a revision) and enumerates the exact output formats (GLB, OBJ, STL, .blend, .ngp) for an ngPlant project. This cleanly distinguishes it from sibling mutation tools like render_create or asset_generate_3d.

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 routing guidance for parameters: ngp means byte-preserving with no selection/modifiers, enginePreset selects target-engine conventions, and bakeLighting explicitly points to bakeTextures as the alternative for metal/glass turntables. It lacks explicit when-to-use-this-tool-vs-siblings guidance (e.g. vs render_create), so not 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 already declare this is read-only, idempotent, non-destructive and not open-world; the description adds genuine value on top by disclosing that it emits a prompt plus upload/material steps and delegates generation to the harness's own image tool. That clarifies the call has no side effects and no compute cost, though it does not describe the shape of the returned prompt/steps.

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, no filler. The scope statement comes first, the return/delegation behavior next, and the negative constraint ('does not generate... or spend Blender compute') last, which is the right ordering for an agent deciding whether to call.

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 19-param planning tool with no output schema, the description summarizes the return ('a prompt and upload/material steps') but does not describe its structure, and it leaves most parameters undocumented while coverage is low. It is adequate to understand the tool's role but thin for calling it precisely.

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 only 32% across 19 parameters, so the description carries much of the documentation burden, yet it mentions no parameter at all. The artifact-type list echoes the purpose enum but adds no syntax, format, defaults or interaction guidance (e.g. how layout, resolution and physicalCoverageMeters relate).

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 ('Plan a source image') and enumerates the artifact types it covers (surfaces, decals, trim sheets, atlases, environments, animation). It also carves out a clear boundary against the generation siblings: it returns a prompt and steps, not pixels, and does not 'spend Blender compute.'

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?

The description gives a usable selection condition: use this when you want a prompt plus upload/material steps rather than an actual generated image or spend. It does not, however, name the concrete alternatives (e.g. texture_maps_create, material_from_image, asset_generate_3d) that a caller would be choosing between.

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 destructive=true and idempotent=false, but the description adds substantial non-redundant context: what is destroyed (the stored credential), downstream consequence (subsequent calls requiring it need setup again), auth requirements, the deleted=false return case, and the explicit boundaries of the deletion. This is exactly the value-add expected above the annotation baseline.

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 effect and its consequence, then prerequisites, then scope boundaries. Dense but each sentence carries distinct information; the website note is the only mildly marginal addition.

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 destructive one-parameter tool, the description covers effect, authorization, boundaries, and the edge-case return value, while annotations and an output schema handle safety flags and return shape. Nothing needed 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% and the single 3-param provider enum is fully documented as 'Configured integration to remove.' The description doesn't add syntax or selection guidance beyond the schema, 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 ('Remove') and a precise resource ('this organization's stored credential for a third-party asset/generation provider'), which is clearly distinct from integrations_set (writing) and integrations_list (reading). An agent can route confidently without opening schemas.

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 prerequisites (owner/admin with deployments:admin) and an explicit inspection path ('Use integrations_list to inspect configuration'). It also clarifies a scope exclusion (doesn't delete imported assets or revoke provider tokens) and points to the website for replacing keys. No explicit 'when not to use' statement, 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 and closed-world, so the safety profile is covered. The description adds genuine value beyond that by disclosing that credentials are never returned ('masked hints only, never tokens') and by describing the connectivity prerequisites that determine what the list will show.

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 statement and the security guarantee, then the provider matrix. The final sentence is slightly encyclopedic for a list tool, but each clause maps to a real decision an agent must make about the returned integrations.

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?

No parameters and an output schema exists, so return structure needn't be described. What remains ambiguous for a zero-arg integration-list call — what is masked, and which providers require approved connections — is explicitly answered.

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 of 4 applies; there is no argument syntax to explain. The description correctly spends its words on result semantics and provider states instead of inventing parameter 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 ('Read-only list of configured third-party source integrations') and immediately clarifies the payload shape ('masked hints only, never tokens'), which separates it from integrations_set/integrations_delete. An agent knows exactly what this returns 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 a concrete use case — 'Check import/generation availability without requesting credentials in chat' — and explains per-provider conditions (Poly Haven needs no connection, Sketchfab import needs an approved connection, Hyper3D/Hunyuan3D/Tripo3D are generators not catalogs). It does not explicitly name when to skip this tool in favor of a sibling, 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 already indicate destructiveHint=true, and the description adds valuable context beyond annotations: tokens are encrypted at rest, owner/admin permission is required, and provider-specific integrations are enabled. It does not explicitly say that setting a token overwrites an existing one, but the destructive hint covers that risk.

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 action and security context, then organized by provider with consistent formatting. Every sentence adds useful information—there is no filler or redundant restatement of the tool name or 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?

For a two-parameter tool with full schema coverage and an output schema, the description is complete: it covers permission requirements, encryption, provider-specific token sources, and downstream effects. An agent has everything needed to call the tool correctly without additional documentation.

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?

While schema coverage is 100%, the description adds significant meaning by mapping each provider enum value to its token source and the feature it enables. This goes well beyond the schema's generic 'Provider-issued API token' and helps the agent construct correct values.

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 action ('Store a third-party source API token') with the resource scope ('for the organization') and encryption detail. It clearly differentiates from sibling tools like integrations_delete and integrations_list by focusing on configuration/setup rather than removal or listing.

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?

The description gives clear context: it requires owner/admin and explains when each provider token should be used by linking providers to enabling specific features. It does not explicitly mention when not to use the tool or name alternatives, but the context is strong enough for an agent to select it appropriately.

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 annotations by describing cooperative cancellation semantics, partial completion at checkpoints, rejection conditions, compute accounting, and that the response is not proof of cancellation. This gives the agent rich behavioral context that annotations alone (destructiveHint, idempotentHint, etc.) do not convey.

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 adds constraints, billing, return semantics, and alternatives in tightly packed but non-redundant sentences. Every sentence contributes 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?

Despite having an output schema, it still usefully clarifies that the response is not proof of cancellation and directs the agent to poll job_get or job_wait. Combined with annotations and schema, nothing needed to invoke the 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 100%, so the schema already documents both jobId and reason fully. The description adds no parameter-specific meaning, which is the baseline case when the schema does the heavy lifting.

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 ('cancel' a 'job') and immediately scopes it as cooperative cancellation for open jobs. It clearly distinguishes itself from job_get, job_wait, jobs_list, and job_report by naming their distinct roles.

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 ('when an open job should stop'), when it will be rejected (terminal jobs or once result publication starts), and which alternatives to use for locating jobs, polling terminal state, or getting detailed results.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral nuance beyond annotations: events are ordered, and results are only present when the job is terminal, including revision and artifact download URLs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence packs the core action, the exact queryable data, and the terminal-condition nuance without filler or redundancy. The most important information is front-loaded, and every clause earns its place.

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-parameter, read-only, idempotent tool with no output schema, the description is complete. It explains what the endpoint returns, including the terminal-only results qualification, so an agent can correctly invoke it and interpret the response without additional context.

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 jobId parameter is fully documented in the schema. The description adds no independent parameter-level information beyond referring to 'a job', which is acceptable given the schema already explains the durable ID 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?

The description names a specific action ('Get') and resource ('a job'), then enumerates exactly what the tool returns: status, progress, ordered events, and terminal results. This clearly distinguishes it from sibling tools like jobs_list or job_report, which an agent can infer are broader or differently scoped.

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?

The description provides clear context for when to use this tool: whenever a caller needs a job's status, progress, ordered events, or terminal results. It does not explicitly name alternatives or exclusion cases, but the precise return-value list makes intended usage apparent relative to siblings.

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 read-only/idempotent safety profile, and the description adds substantial non-obvious behavior: continuation identity pinning (artifactId, filterId), byte-budget short pages, truncation semantics for oversized records, and the distinction between pending/failed/cancelled/incomplete/truncated states versus real validation results.

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 operation, then ordered detail on sections, paging, and states. Dense but nearly every clause carries operational information; some sentences (state enumeration) run long and could be tightened.

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 detail is unnecessary, and the description still covers what an agent needs to page correctly and to interpret terminal states. Nothing critical 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%, so the baseline is 3, but the description adds a genuinely important semantic the schema only hints at: offset counts records for list sections but counts bytes for section=report, and limit may return fewer due to the byte budget. Filters are left to the schema, which already documents them fully.

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 bounded pages from a completed job's immutable report_json artifact') and names the sibling it differs from (artifact_get for the complete file). The section enumeration makes the scope concrete without requiring 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 routing advice: use section=summary for cheap aggregates, note that issues is the default for validation and summary for scene_apply/export, and points to artifact_get for full download. It stops short of saying when this tool should be avoided in favour of job_get or job_wait, so not 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, and the description is consistent with that ('Read-only'). Beyond annotations it adds real value: it discloses the return shape (items plus opaque nextCursor) and the pagination termination rule ('copy nextCursor verbatim until null'). It does not discuss rate limits or result ordering, so a 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?

Front-loaded with purpose, then the sibling-routing sentence, then the pagination rule. Every clause carries information an agent needs; 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 needn't explain return values, yet it still names items/nextCursor. Combined with complete sibling routing and annotation coverage of the safety profile, an agent has everything required to call it 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 (limit, cursor, status, projectId) are already fully documented in the schema, including the keyset-vs-offset cursor warning. The description restates the filter intent and the cursor-copy rule but adds no semantics beyond the schema, 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 and resource (list recent jobs) scoped to the bound deployment, with optional project/status filtering. It also carves out a distinct use case — recovering when a job ID has been lost — that separates it from the sibling lookup tools.

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 alternatives and the conditions that select them: job_get for a single job's status/result, job_wait to await terminal state, job_report for full paged reports, job_cancel to stop. This is genuine routing guidance, not 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 already establish that this is read-only, idempotent, and non-destructive, while the description adds useful operational context: the 90s default is tied to cold-starting Blender containers, long calls risk transport errors, and validation coverage must be checked via inlineComplete and coverageComplete. Nothing contradicts 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 description is front-loaded with the core behavior and key timeout default, then moves to alternatives and output caveats. It is dense but mostly purposeful; the validation-report sentences are useful but overlap somewhat with the output 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?

For a long-polling job tool with two parameters, an output schema, and safety annotations, the description covers the essential calling strategy, timeout risks, alternatives, and how to interpret truncated or incomplete validation coverage. An agent has enough information to invoke it 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% and the parameter descriptions are already detailed, so the baseline is 3. The description adds some value by explaining that 90s is the usual cold-start requirement and by framing the tradeoff between round trips and connection risk, though much of the timeout guidance is also present in the schema note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Long-poll a job until it reaches a terminal state or the timeout elapses.' It also distinguishes this from a polling loop with job_get and from the webhook alternative, so an agent can identify the tool's role 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?

It explicitly says this is cheaper than a job_get loop, advises chaining calls for longer jobs, and names webhooks_set as an alternative that avoids polling. It also gives concrete timeout guidance and warns that long single calls trade round trips for connection risk.

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 set destructiveHint=true and readOnlyHint=false, and the description earns credit by disclosing what actually happens: a new revision is committed, applyToObjects assigns it, maps pack into the .blend, and a durable job handle is returned. It adds the 2048px generation cap and the decal/profile behavior switch, which annotations do not cover. It doesn't explain the consequence of the destructive hint (linear history, revision conflicts on stale baseRevisionId), so a small gap remains.

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 and scope, then the cap/alternative, then flow, then the profile caveat. It is dense (semicolon-packed sentences) but nearly every clause carries a discriminator or constraint that an agent needs. Slightly heavier than ideal for a description that could have deferred the longer options discussion to 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?

Annotations and an output schema exist, so the description needn't restate safety or return shapes; it correctly focuses on the non-obvious parts (upload flow, profile switch, size cap, decal transparency). Given 16 parameters and a deep nested options object, a few gaps remain — destructive/revision-conflict semantics and role interpretation for the roles array — but nothing an agent needs in order to call 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?

With 19% schema coverage across 16 parameters plus a 20-property nested options object, the schema leaves most of the semantics unstated. The description compensates for the most consequential distinction — profile=surface/decal/supplied invoking the v2 workflow while legacy mask/emboss arguments apply only when profile is omitted — and glosses maskSource, baseRoughness/maskRoughness, baseColor and metallic. But the majority of options (tile, seamMode, normalConvention, displacementMode, physicalCoverageMeters, alphaMode) are left entirely to the schema, so it adds real but partial value.

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 ('Turn ONE uploaded image into a full PBR material') plus a key differentiator ('deterministic, no AI'). Combined with the caps note routing 4K work to asset_import, an agent can tell this apart from material_from_maps and texture_maps_create 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 an explicit prerequisite chain (upload_create → PUT → upload_complete → material_from_image) and a clear exclusion with an alternative for full-resolution label work (embed in GLB via asset_import). It stops short of contrasting the profile vs legacy argument paths against the sibling material_from_maps, so routing is clear but not fully disambiguated.

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 destructiveHint=true and readOnlyHint=false, so the mutation profile is already conveyed. The description adds real value beyond that: it discloses slot replacement, atomic validation before commit ('commits one revision after all targets validate'), and preservation of UVs and earlier revisions. Return shape is summarized as a job with job_wait/job_get for terminal status, though error/partial-failure semantics are only partially implied.

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?

Four tight sentences, front-loaded with the action and input sources, then targeting semantics, then atomicity guarantees, then sibling routing. No filler or repetition of schema text.

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 14-parameter mutation tool with nested objects and an output schema, the description covers input alternatives, targeting behavior, atomicity/revision semantics, and the follow-up status tools. Return values are delegated to the output schema, which is appropriate.

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 goes beyond it by disambiguating two easily-confused targeting parameters — applyToObjects targets slot zero while assignments targets explicit slots — which is genuine routing value an agent needs.

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 ('Create a scene material') and pins the two valid inputs (completed textureJobId or validated role-labeled images). It is clearly distinguishable from material_from_image and material_recipe, which it names directly.

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 routes the agent to alternatives with conditions: texture_maps_create for downloads without scene changes, material_from_image for one image, material_recipe for a procedural proposal. Both when-to-use and when-not-to-use are covered.

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 and idempotentHint, so the description's 'Read-only' is redundant. However, it adds meaningful scope: 'no project, job or compute' and the paging behavior ('pages of at most 24'), which are not present in annotations. These additions give agents a clearer behavioral model.

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 with no filler. The core function is front-loaded, followed by safety scope and then usage context. Every sentence adds value and the structure is easy 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?

There is no output schema, so the description carries the burden of explaining return relevance. It does mention that node selection returns 'pinned Blender input/output indices and enum properties' and that search returns pages, which is useful. It is reasonably complete for a read-only discovery tool, though offset behavior and response structure could be more explicit.

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 describes `node` and `query`, but `limit` and `offset` have no descriptions. The description adds some meaning: 'pages of at most 24' clarifies limit, and 'select one node' clarifies the node parameter. However, `offset` is never explained, and the description does not fully compensate for the 50% schema coverage gap.

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 action and resource: 'Search supported shader aliases/native names in pages of at most 24, or select one node for pinned Blender input/output indices and enum properties.' It clearly differentiates the two modes (search vs. select) and relates the tool to material_recipe and scene_apply, making its role distinct from 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?

It explicitly states when to use the tool: 'Use the alias and exact sockets when editing a material_recipe proposal or scene_apply graph.' It also gives exclusions with 'no project, job or compute,' clarifying what the tool is not for. This provides clear guidance without needing to name an alternative tool.

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, and the description reinforces this with the sharpest possible statement ('Proposals only: no mutation, provider call, baking or compute'). It also discloses the intended workflow sequence (review, inspect sockets with material_nodes, execute with scene_apply), which is real context beyond the annotations. It stops short of describing the proposal payload shape or validation-check 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?

Five tight sentences, none redundant: purpose first, then routing rule, then hybrid detail, then safety contract, then workflow. Zero filler and every clause pays for itself.

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 25-parameter, nested-object tool with no output schema, the description covers routing, safety, sibling boundaries, and the follow-up workflow, which is most of what an agent needs. The gap is parameter-level completeness: roughly half the schema fields are undocumented, and the description does not close that hole.

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?

With 25 parameters at only 48% schema description coverage, the description carries a heavy burden and only partially compensates: it hints that hybrid recipes reuse existing image nodes and aligned color variants, and that weathering uses a deposit/wear tint. It adds no guidance on the mass of undocumented parameters (seed, roughness, uvScale, variation, assignments, extension modes), so many params remain unexplained in both places.

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 (propose) and resource (editable procedural/hybrid shader operations) plus its domain (wood, metal, stone, fabric, image weathering) and explicitly distinguishes itself from its closest siblings by name. An agent can route to this tool 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 an explicit selection rule ('Choose this for node-based materials') and names four alternatives with the exact condition that selects each (material_from_image for one uploaded image, material_from_maps for a prepared map set, texture_maps_create for downloads without scene changes). 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 already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds the account-membership scoping and the fact that each entry includes the caller's role, which is useful behavioral information beyond 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?

A single concise sentence that front-loads the action and resource and then adds the key behavioral detail (role in each organization). Every word contributes value.

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 zero-parameter, read-only listing tool with an output schema and strong annotations, the description fully conveys what the agent needs to invoke it correctly. Nothing important 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 has zero parameters, so the schema leaves nothing to document. The description accurately implies that no arguments are needed to call it; there is no parameter information for the description to supplement.

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 the exact resource ('organizations'), the action ('List'), and the account-scoped membership context, so an agent can distinguish it from the many other list tools in the sibling set. It also adds the 'role in each' detail, which goes beyond the title.

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?

The description makes it clear that this is the tool for enumerating the organizations the current account belongs to. There is no sibling organization tool to contrast with, so the absence of an explicit 'use X instead' statement is acceptable; the resource scope alone routes selection.

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 establish that this is a safe, idempotent, closed-world read, so the bar is lower. The description still adds real value beyond them by disclosing the caching subtlety — it returns the versioned live snapshotPolicy when cached tool descriptions differ — which an agent could not infer from the annotations or the empty 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?

Two sentences, front-loaded with the payload list and closed with the actionable trigger, so the most decision-relevant content comes first. The snapshotPolicy clause is dense but earns its place as the one non-obvious behavioral detail.

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 needn't be spelled out, and the description instead covers what an agent needs for the decision: what signals come back and when to call. For a zero-parameter read-only probe, nothing material 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 the description carries no parameter burden and the baseline of 4 applies. The schema is empty and fully consistent with a no-argument probe.

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 specific capability probe and enumerates concretely what it reports: Blender execution availability, compute budget usage, open job counts, and deployment policy limits. That set of return signals distinguishes it clearly from siblings like deployments_list, jobs_list, or asset_generate_status, which each cover only one slice.

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 trigger: "Call before queueing work to fail fast," which tells the agent precisely when this probe pays off relative to render_create, scene_apply, and other queueing tools. It does not state when-not to call or name an alternative for narrower questions, which keeps it 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 declare destructive=true/non-idempotent, and the description adds real behavioral context beyond them: presets compile to validated scene operations, write a new revision, and that lighting/camera rigs are authored against a 2 m reference at 800-1500 W and 4-6 m. It doesn't explain the destructive/linear-history implication of the write (that is left to the baseRevisionId schema text), 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?

Front-loaded with purpose, then organized by preset family, with the highest-risk caveat (small-subject white frame) clearly stated. The vivid 'white frame' line and the 42 mm arithmetic are dense but genuinely load-bearing; the passage is slightly longer than strictly necessary but no sentence is disposable.

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 an output schema and partial annotation coverage, the description supplies the missing context an agent needs: what each preset family changes, the scaling contract for subjectSizeM, and the default state when it is omitted. Return-value behavior is delegated to the output schema, so nothing material 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 only 56%, and the description compensates by mapping otherwise-undocumented parameters to behavior: 'tint via color, assign via applyToObjects' explains two of the bare schema properties. subjectSizeM's rescaling rule is reinforced, but materialName and the interaction of preset type with per-parameter validity remain unaddressed.

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 first sentence gives a precise verb+resource ('Apply a curated preset as a new revision') plus a parenthetical on what that produces ('compiles to validated scene operations'). It then enumerates the four preset families and their distinct effects, which lets an agent separate this from scene_apply, material_recipe, or presets_list 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?

The description gives concrete when-to-use guidance for the key parameter ('Pass subjectSizeM and the whole rig is rescaled for you') and an explicit failure mode for omitting it on small subjects. It does not name sibling alternatives (presets_list for discovery, scene_apply for raw ops) or state preconditions, so it falls short of full 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate the safety profile. It adds useful context about what kinds of presets exist, but it does not disclose additional behavioral details such as filtering semantics or output size.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with a colon-led enumeration. The main action and scope are front-loaded, and every clause adds useful information without waste.

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 one optional parameter, a rich enum schema, and an output schema present, the description is mostly complete for selecting and invoking the tool. It could slightly improve by explicitly noting when this tool should be used in a preset_apply workflow, but little critical information 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?

Even though schema coverage is 100%, the description enriches the 'kind' parameter by mapping each enum value to concrete examples like PBR materials, studio three-point, hero three-quarter, and draft render profiles. This is meaningful value beyond the schema's fairly terse parameter description.

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 ('List') and concrete resource ('curated one-call presets for preset_apply'), then enumerates the four preset kinds. This is specific and clearly distinguishes presets_list from sibling preset_apply and other list-like tools.

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?

The phrase 'for preset_apply' clearly signals the intended workflow: list available presets before applying one. It provides clear context, though it does not explicitly state when not to use this tool or name alternative tools beyond preset_apply.

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 carry the safety profile (not read-only, not idempotent-hinted); the description goes far beyond by disclosing the return contract (stable liveUrl plus durable job handle), the sign-in requirement, the polling path via job_get, and the first-immutable-revision timing. This is exactly the behavioral context that structured fields do not supply.

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: purpose first, then engine guidance, then the return/workflow contract. It runs long and mixes invocation guidance with agent workflow instructions, so some sentences could be trimmed, but each carries distinct information 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?

For a creation tool with an output schema, annotations, and five enum-heavy parameters, the description covers purpose, alternatives, engine semantics, return values, the required sharing step, and polling. Nothing an agent needs to call 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 real meaning on top: the ngplant-vs-Blender tradeoff for executionEngine and the true/false defaults for generatePreview that depend on the template, plus the rationale for template=empty. It augments rather than repeats 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 and resource ('Create a project from a template') and immediately frames the engine choice with sibling tools ('vegetation_create/edit to author its native model'). An agent can route this against project_update, scene_apply, and the vegetation 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?

Explicit selection rules: executionEngine=ngplant for plants/procedural vegetation, vegetation_create/edit for the native model, Blender as default for other scenes. It also names the when-not condition for preview generation on template=empty. That is genuine when/when-not/alternatives 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 already declare destructiveHint=true and readOnlyHint=false, so the description adds value by specifying the nuanced behavior: it is a soft-delete, revisions are retained, and open jobs block the operation. This goes beyond the simple destructive flag and informs the agent about consequences and prerequisites.

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 concise sentences front-load the action and its key effects, followed by the critical prerequisite. Every clause carries information without redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter destructive tool with an output schema and annotations, the description covers the main behavioral constraints (soft-delete, blocking condition, cancellation path). It does not mention auth or rate limits, but those are typically outside description scope; the essential call-time knowledge is 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 both parameters (projectId, confirm) are already documented in the schema. The description does not add additional parameter-level meaning, so the baseline of 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?

The description states a specific action ('Soft-delete'), the resource ('a project'), and the behavioral effect ('hidden from listings; revisions retained'). This clearly distinguishes it from other delete tools like deployment_delete or integrations_delete, and clarifies it is not a permanent deletion.

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?

The description gives an explicit precondition ('Open jobs block deletion') and directs the agent to a sibling tool for the required workaround ('cancel them first with job_cancel'). It implies when to use it (when no open jobs exist) and when not to, with a concrete alternative.

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 mark the tool as readOnly, idempotent, and non-destructive. The description adds meaningful behavioral context beyond the annotations by enumerating the returned metadata categories and clarifying that the liveUrl lets signed-in organization members watch progress without starting Blender work. This enriches the agent's understanding of what the operation actually returns.

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 a single, dense sentence that front-loads the core action ('Get project metadata') and then uses a colon-delimited list of concrete return items. Every element contributes information, with 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?

Given the tool has a single required parameter, a full schema for that parameter, an output schema, and safety annotations, the description is nearly complete. It covers the main metadata categories and the special liveUrl behavior. It could be slightly more complete by noting when to prefer this over related read tools, 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?

There is only one parameter, projectId, and the schema describes it fully with 100% coverage. The description adds no additional parameter-level guidance, but since the schema already provides complete meaning, the baseline score of 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 uses a specific verb ('Get') and resource ('project metadata') and enumerates the concrete data returned: head revision, recent revisions, active jobs, preview artifact, policy limits, and a liveUrl. It is clear what the tool does, though it does not explicitly contrast itself with the sibling projects_list or project_update.

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?

The description implies this is for retrieving detailed metadata for a single project as opposed to listing projects, but it never states when to use project_get versus projects_list, artifact_get, or job_get. No explicit alternatives or exclusions are provided, leaving the usage context 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 already declare read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds useful behavior beyond annotations: results are ordered newest first, are scoped to the account, and use cursor pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with no waste, and it front-loads the core purpose before ordering and pagination details.

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?

The tool has an output schema, complete parameter documentation, and annotations, so the description need not explain return values. It covers the essential behavioral facts (ordering and pagination), though it omits any mention of filtering or sibling alternatives.

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 schema already documents limit, cursor semantics, and nameFilter in detail. The description adds no parameter-level detail beyond saying cursor pagination, so 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 states a specific verb and resource ('List the account's projects') and adds ordering. It is clear enough to distinguish from project_get/project_update siblings, but it does not explicitly name or contrast those 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?

Listing projects implies a context of use, but the description gives no explicit when-to-use guidance or alternatives. It does not tell the agent when to use projects_list rather than project_get or when filtering with nameFilter is appropriate.

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 indicate this is a destructive/non-read-only operation, and the description adds useful context by explicitly stating that history, revisions, and jobs are unaffected. It goes beyond annotation hints without contradicting them, though it does not detail any other side effects or permissions.

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-load the core action and then add the most relevant side-effect clarification. There is no redundant wording or filler, so every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter rename operation with a complete input schema, output schema, and annotations, the description is sufficient. It tells the agent what the operation does and which data is preserved, leaving no critical gap for correct invocation.

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 schema already explains both 'name' and 'projectId'. The tool description adds no parameter-level semantics beyond what the schema provides, so the baseline score of 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 uses a specific verb and resource, 'Rename a project', and clarifies scope by stating that history, revisions, and jobs are unaffected. This distinguishes it from destructive siblings like project_delete and from project_create/get/list, making the tool's purpose unambiguous.

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?

The description implies the tool is for renaming and reassures that history, revisions, and jobs are unaffected, which gives some context about safe usage. However, it does not explicitly state when not to use it or mention alternatives such as project_create or project_delete, leaving usage guidance largely implicit.

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?

Despite minimal annotations (all hints false), the description discloses key behaviors: output is an immutable artifact downloadable via artifact_get, inputs must belong to the project/deployment, audio must be PCM16 44.1 kHz mono/stereo, clipping is rejected with a directive to lower gainDb, output streams/timing are verified, and the return is a durable job handle. It also states the 600-frame limit and concat-safety of parallel segments. This goes well beyond 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?

Every sentence in the description adds non-obvious, actionable information: engine tradeoffs, prerequisite ordering, job limits, parallelization strategy, artifact immutability, audio constraints, rejection behavior, verification, and return type. Despite its length, there is no filler or repetition, and it is appropriately front-loaded with the core purpose.

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 12 parameters, no output schema, and minimal annotations, the description is exceptionally complete. It covers prerequisites, engine selection criteria, operational limits, parallel scaling, artifact lifecycle, audio input validation, failure mode, verification, and return contract. The only minor omissions (explicit sibling differentiation, per-parameter detail for resolution/fps) are largely compensated by schema defaults and clear parameter names.

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?

With only 25% schema description coverage, the description carries the burden of explaining parameters. It richly explains the engine enum and audioTracks semantics (startSeconds, sourceOffsetSeconds, gainDb, looping), plus frame-range implications. However, it leaves fps, width, height, samples, and cameraId entirely implicit, relying on parameter names. That partial compensation yields a middle score.

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 clear, specific verb and resource: 'Render a frame range to an H.264 MP4.' It also distinguishes internal engine modes, giving it a concrete scope. However, it never explicitly contrasts itself with sibling tools like render_create or render_turntable, so an agent must infer differentiation from the name and context.

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?

The description gives explicit when-to-use guidance for each engine (cycles_cpu for photoreal, lit_preview for review at 10x lower cost, preview_fast for shape-only) and a prerequisite ('Animate first... via scene_apply animation.*'). It also advises splitting long sequences into parallel contiguous ranges. But it doesn't name alternative tools or state when not to use this tool versus a sibling, so it stops short of full exclusion guidance.

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