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

With no annotations provided, the description carries the full burden, and it delivers: it explains the side effect (copies bytes), the storage location (assets/<sha>.<ext>), the classification logic (magic bytes first), the fact it never edits a scene or creates a revision, and the local-only constraint. It also warns against using httpUrl or the original file path for embedding, which is critical for durability. This is exemplary transparency.

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 well-organized, with purpose, usage, return format, classification, and constraints in separate paragraphs. Every sentence adds value, though it could be tightened slightly without losing critical information. It is front-loaded with the core purpose and then expands into necessary 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?

Despite having only one parameter, a nested source object, no output schema, and no annotations, the description covers everything an agent needs: return format, how to use the uri in edit, classification behavior, and the local-only limitation. It is fully self-sufficient 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 0%, so the description must compensate. It does: it explains the source object's structure ({ path }), that path must be absolute and readable by the server, and that it is local-only. This adds meaning beyond the schema's terse description and fully clarifies the single parameter.

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 ('Add'), resource ('local image or font file'), and purpose ('so it can be used in a design'). It also differentiates itself from siblings by naming asset_search and asset_generate as the alternatives for finding and generating assets, and import for turning design files into designs. This makes the tool's role unmistakable.

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 contrasts with asset_search and asset_generate, and provides a clear when-to-use rule: use this when you have a file on disk. It also states when not to use it (never for placement, use edit) and points to import for a different scenario. This gives the agent unambiguous selection criteria.

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?

There are no annotations, so the description carries the full disclosure burden. It covers the no-argument catalog response, the structured first content part, durable workspace URIs, labeled thumbnails, multi-output assets in stack order, verbatim metadata, and the sign-in requirement — substantially more behavioral context than basic operation.

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 warranted by the tool's complexity: invocation pattern, output format, multi-output behavior, and auth are each in their own focused segment. It is front-loaded with the core generation purpose and every sentence adds necessary routing or output semantics.

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 and no annotations, this definition covers what an agent needs to call the tool correctly: how to discover models, required parameters, optional format, image inputs, return-content structure, multi-output semantics, and the login prerequisite. 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 coverage is 100% so the baseline is 3, but the description adds meaningful operational meaning: model requires first listing the catalog, prompt pairs with model, format is an optional aspect such as 16:9, and image_uris come from import or earlier generations as workspace URIs. This goes beyond the schema's brief parameter 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 and resource: 'Generate images (text-to-image, image-to-image) via the IMG.LY AI gateway.' It further distinguishes generation from siblings by describing the no-argument catalog workflow and noting that generation requires login while 'all other design tools work without an account.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit invocation guidance: 'Call with NO arguments first,' then call again with model and prompt, and for image-to-image pass image_uris. It also states the login prerequisite, but it does not explicitly name a when-not-to-use alternative or contrast with sibling tools such as edit or import beyond the mention of embedding URIs in subsequent edit calls.

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

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

With no annotations, the description carries the full burden, and it delivers extensively. It discloses read-only semantics, pagination response shape, fuzzy matching behavior, upload grouping and ordering, the meaning of 'the image the user just uploaded', missing-source behavior, and the silent no-op of applyToBlock. This far exceeds what the schema or annotations provide.

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

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

The description is long but densely informative with clear paragraph boundaries: core behavior, result shape, workspace image specifics, warnings, and usage recipes. Every section earns its place, and the most important read-only/never-creates-a-revision message is front-loaded.

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 complex tool with no annotations and no output schema, this description is remarkably complete. It explains return values, edge cases, font handling, upload semantics, integration code, and failure modes. An agent has everything needed to select and invoke the tool correctly, and to apply its results in edit code.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful usage nuance beyond the schema, especially for perPage in font lookups ('perPage: 1 fetches the wrong family'), query behavior on labels and tags, and sourceId-dependent result shape. It doesn't systematically restate each schema field, but it adds practical semantics where it matters.

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 verb and resource: 'Discover the asset sources registered on the CreativeEngine and search the assets they contain.' It explicitly states read-only behavior and distinguishes the no-sourceId listing mode from the sourceId search mode, 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 gives explicit when-to-use and when-not-to-use guidance: it explains the two invocation modes, warns against fetching asset manifests or hardcoding CDN URLs, prohibits engine.asset.applyToBlock, and provides specific code paths for using results in edit code. It also names the correct alternatives: this tool and engine.asset.* are the only correct path.

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

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

With no annotations, the description carries the full disclosure burden. It explains the reply: whether the revision is still the design head, what was written since, ordering oldest first, diff notes, and the `origin` field. It does not explicitly state it is non-mutating, but 'check' and the described reply imply a read-only operation.

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 purpose, followed by the reply structure and the critical call timing. Each paragraph earns its place, and the mention of `edit` rejection is essential context 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?

Given a single required parameter and no output schema or annotations, the description covers everything needed: what the tool checks, what to pass, what the reply contains, and when it should be called. 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%, and the schema already says 'Revision you believe is current — normally the one your last `edit` returned.' The description repeats this guidance and adds workflow context, but it does not convey substantially new parameter semantics 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 first sentence states a specific verb and resource: 'Check whether the user changed a design in the browser editor since you last touched it.' It also names the workflow relationship to `edit` and `view`, distinguishing it from sibling tools like `history` or `inspect`.

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 trigger: 'Call this before your first `edit` of a design whenever the user may have had the `view` page open.' It explains the consequence of not doing so by noting that `edit` rejects a parent containing editor saves. It does not name an alternative tool, but the condition 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?

With no annotations, the description carries the full burden and delivers richly: it discloses that calling again REPLACES the whole list, that copy comparisons fold whitespace but treat wording/case/punctuation as exact, that note items are never machine-checked, that every export verifies the checklist, and the exact return shape. No behavioral surprise is left undisclosed.

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 lead sentence front-loads the core purpose; the item-kind bullets are necessary because the schema cannot convey these semantics; and the export-interaction and replacement warnings are essential operational facts. No filler or repetition.

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

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

Given no output schema and no annotations, the description is fully self-sufficient: it covers return values, item-kind semantics, replacement behavior, lifecycle timing, and failure-handling. An agent can invoke this tool correctly on the first attempt with zero information beyond the description.

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?

Although schema coverage is 100%, the description dramatically expands meaning beyond the bare field names: it defines each kind's semantics (output = absolute path that must exist; copy = verbatim with whitespace folding; note = never machine-checked), explains the read mode when only revision is passed, and documents the return object. This far exceeds the baseline-3 bar.

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

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

The description states a specific verb+resource: 'Register the brief's ACCEPTANCE CHECKLIST for a design — the machine-checkable claims that must hold before the work counts as done.' It is immediately distinguishable from siblings like export (which verifies the checklist), scorecard (which presumably grades), and edit/preview (which mutate/view the design).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit timing ('Do this right after intake, before the first edit'), specifies what to extract from the brief (output files, verbatim copy, self-check notes), and explains how unmet items interact with export ('treat an unmet item exactly like a failing test: finish the work, or re-register the checklist without the item'). This is actionable when-to-use guidance that also routes the agent's behavior downstream.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It discloses that status reports non-secret config, summary is bounded, and open returns a clickable URL with a Download-ZIP button. However, it doesn't mention side effects (e.g., whether 'open' launches anything or just returns a URL) or any rate limits.

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

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

Three tightly packed sentences, each covering one action with its output. Front-loaded with the tool's purpose and 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?

For a single-parameter tool with no output schema, the description covers the main behaviors and outputs. It could mention whether 'open' has side effects or how the viewer URL is delivered, but overall it's sufficient for an agent 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 coverage is 100% and the enum values are described in the schema. The description adds meaningful context for each action value, but since the schema already lists them, the added value is moderate. 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 clearly identifies the tool as inspecting the codesign MCP server and enumerates three distinct actions (status, summary, open) with specific outputs. It distinguishes itself from siblings by focusing on server diagnostics rather than assets, editing, or auth.

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 explains what each action returns and notes that status is the default, giving an agent clear context for choosing an action. It doesn't explicitly state when to use this tool versus alternatives, but the diagnostic scope is clear enough that an agent can infer when it's 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?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses the revision-commit side effect, the exact return JSON shape, the strict `code` return contract, the engine.design dialect enforcement, the dirty-on-throw engine reload consequence, and the refusal behavior when the user saved changes in the browser editor.

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 carries operational value, and it is well structured with bolded labels. Critical constraints like the handbook prerequisite, required `parent`, and return contract are front-loaded, while optional parameters and edge cases are grouped at the end.

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

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

Given no output schema and no annotations, the description fully compensates by specifying return values, failure modes, parameter constraints, and relationships to sibling tools. The agent has everything needed to call `edit` correctly and recover from common errors such as refused parents or thrown code.

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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: `parent` has no implicit default and must be the JSON null literal for new designs, `code` has a strict return contract and scope rules, `title` only applies when parent=null, `note` is purely metadata, and `render` should be disabled only for read-only or diagnostic edits.

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 opening sentence states a specific verb and resource: 'Edit the CE.SDK canvas by running JavaScript against the live CreativeEngine, then commit the result as a new revision.' It clearly differentiates this mutation-and-commit tool from siblings like `preview`, `changes`, and `rename` by defining the edit lifecycle.

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: call `skill({ name: 'handbook' })` before first use, use the returned render instead of `preview` for quick verification, keep `preview` for full-size/multi-page judging, and call `changes` when a parent revision is refused. It also notes that `rename` should be used for mid-chain renames, not `title`.

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

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

With no annotations, the description carries full behavioral burden. It discloses side effects (writes into workspace under a deterministic revision-pinned path), return shape (JSON with uri, httpUrl, bytes, format, revision, plus path), and format-specific quirks (SVG outlines text, imgly is self-contained, pdfx adds seconds, html injects GSAP). It also notes httpUrl is process-bound and warns about sandboxed harnesses. No 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?

The description is long but well-structured: it front-loads the purpose and format list, then dedicates focused paragraphs to outPath, svg, imgly, pdfx, and html. Every section earns its place given the tool's complexity; no filler. It could be slightly tighter but is appropriately detailed for the scope.

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 6 parameters, nested objects, and no output schema, the description fully covers invocation and behavior: return JSON, workspace path, format nuances, blockId rules, outPath usage, and sandbox limitations. An agent has everything needed to call the tool correctly and handle results.

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 83%, yet the description adds substantial meaning beyond the schema: it explains the format enum's practical implications (e.g., pdfx print-ready, imgly editable), clarifies blockId omission behavior (whole document), details outPath use cases, and expands on html and pdfx nested options with trade-offs. This goes far beyond the schema's terse 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 verb and resource ('Export a revision to a final deliverable') and enumerates all supported formats with one-line outcomes (pdf, png/jpeg/webp, svg, pdfx, html, imgly). It distinguishes itself from siblings by framing imgly as the inverse of import and noting that edit auto-persists, so an agent can clearly tell export apart from preview, view, and edit.

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: when to pass outPath (when file needed on disk, when sandboxed cannot fetch localhost), when to use imgly (to take an editable copy out), when to use pdfx (print shop), and when html is required (single page, blockId mandatory). It also tells the agent when not to use it ('you never need this to keep your work') and contrasts with edit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals the return chain ordering (root first), each entry's shape, the special meaning of `origin: "editor"`, and the non-obvious instruction not to prefer the newest revision. This is rich behavioral context well beyond a simple one-liner.

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, each earning its place: the first defines the operation and output ordering, the second documents the entry fields and important origin marker, and the third gives usage guidance and a critical behavioral guardrail. The most important information is front-loaded.

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?

Since there is no output schema, the description supplies the return shape, field semantics, and the intended post-rewind workflow. It does not explicitly state that the operation is read-only or what identifies the root (e.g., null parent), but for a history-walk tool these are minor omissions and the agent has enough 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?

The schema only defines `revision` as a required string with 0% coverage, so the description must compensate. It does explain that `revision` is the starting point for the walk and references it indirectly via `parent`, but it never clarifies the expected format, source, or valid values for the revision identifier. It adds some meaning but leaves a meaningful 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 states a specific verb ('walk back'), a resource ('revision chain'), and a clear output scope ('root first'). It also distinguishes the tool's role from related siblings like edit and changes by framing it as a re-grounding step rather than a mutation or listing operation.

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 when-to-use: 'Use this to re-ground after a rewind' and a clear behavioral rule: 'Continue a prior design only when the user asked for it — never because it is the newest entry.' However, it does not name alternative sibling tools or explicitly state when not to use history in favor of another tool like changes.

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

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

No annotations are provided, so the description carries the full burden. It thoroughly discloses side effects: creates a new root revision, extracts archive assets into `assets/<sha>.<ext>`, does NOT fetch external URLs, may return warnings, and notes that transient assets are lost on next save. The engine caveat is also clearly stated.

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 lengthy but well-structured and front-loaded: purpose/alternatives first, then sources, return value, warnings, and engine caveats. Every sentence carries meaningful content, though a slightly tighter presentation would improve 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?

Given the tool's complexity, the absence of an output schema, and no annotations, the description is remarkably complete. It covers return shape (`{ revision, title, format }`), warnings, asset classifications, follow-up actions, and engine-specific restrictions — everything an agent needs 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 the baseline is 3. The description adds useful behavioral context around sources (e.g., external URLs not fetched, demo id, local path) but does not substantively enrich the meaning of the two parameters beyond what the schema already documents.

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 precise statement: 'Import a design FILE as a NEW design root revision', lists all supported formats, and explicitly distinguishes itself from `export` (inverse) and `asset_add` (for media inside a design). An agent can immediately tell what this tool does and how it differs from its 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 gives explicit routing guidance: use `asset_add` for media files meant to be used inside a design, and import is the inverse of `export({ format: 'imgly' })`. It also provides follow-up instructions for foreign-format warnings (preview, repair with edit, find fonts via asset_search) and an engine-specific caveat for InDesign/PDF 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that `code` is omitted for revisions not produced by `edit`, warns that past code contains patterns not block ids (which are session-scoped), and explains the `origin` field. This is substantial behavioral context that helps the agent avoid misuse. It doesn't explicitly state it's read-only, but the nature of 'read' implies no side effects.

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 well-structured and front-loaded with the core purpose. It is concise for the amount of information conveyed: purpose, usage, return format, and an important warning about block ids. Each sentence adds value, and the warning is crucial. It is slightly long 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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers all essential aspects: what it does, how to use it, what it returns, and important limitations. It is complete enough for an agent to call it correctly without further assumptions. It could mention error handling or edge cases, but these are not critical 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?

The schema already describes the single parameter ('Revision id to inspect.') with 100% coverage. The description adds context by linking it to 'history' (implying the id comes from there) and by explaining what the revision represents. This is enough to meet the baseline for high schema coverage, though it could have elaborated on id format or how to obtain it.

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 clearly states the action ('Read one revision in full') and the resource (a revision), and enumerates exactly what is returned. It also differentiates itself from the sibling 'history' tool by specifying that it is used after picking a revision from history, making its purpose distinct and 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 tells the agent when to use this tool: 'Use this after `history` when you've picked a revision'. It also explains the distinction between the code (precise operation) and note (agent's summary), providing clear context for selection among siblings. It does not explicitly state when not to use it, but the guidance is strong enough.

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

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

With no annotations, the description carries the full behavioral burden, and it succeeds: it reveals the return type, sort order, optional `head*` fields, and their meaning. It adds actionable warnings about reading `headNote` and building from `latestLeaf` before making changes.

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 compact but information-dense, front-loading the core list function before diving into field semantics and usage caveats. Every sentence adds value: return shape, sort order, head-field interpretation, and routing guidance.

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 the lack of an output schema, the description documents the return object fields and their significance. It also covers when to use the tool and warns about destructive follow-up behavior, leaving no critical gap for an agent to call or act on this tool safely.

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 there is no schema detail to explain; the baseline for 0-parameter tools is 4. The description instead enriches the call semantics by explaining what the returned fields mean.

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

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

The description opens with a specific verb and resource: 'List designs in the workspace,' immediately establishing the tool's core function. It also defines the returned shape and ordering, and distinguishes the purpose from sibling mutation tools like `edit`.

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 ('when the user asks what designs exist or wants to resume earlier work'). It also gives targeted guidance about what not to do—seeing a design is not a reason to continue it—and directs new-design requests to `edit` with `parent: null`.

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

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

With no annotations provided, the description carries the behavioral transparency burden and does well: it discloses browser opening, automatic session saving, repeat safety, and that calling again does not restart the flow or invalidate the open link. It does not mention failure behavior or output, but the key side effects are covered.

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 main purpose is front-loaded, followed by repeated-use behavior, then the optional parameter. Every sentence contributes useful 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?

For a simple tool with one optional parameter and no output schema, the description is nearly complete. It covers the flow, repeat safety, and the parameter meaning. It does not explicitly state what the tool returns, but the 'call again anytime to confirm' hint provides enough practical context for an agent.

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 switch_account. The description adds 'sign in as a different user', which slightly clarifies intent, but does not add substantial meaning beyond the schema's 'Force a fresh sign-in screen even if a session exists.' 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 action ('Sign in with your IMG.LY account') and distinguishes this tool from siblings by noting it opens the system browser. It clearly identifies the resource and the auth flow.

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 call: anytime to confirm a session, and with switch_account=true to sign in as a different user. It does not explicitly mention alternatives like logout or when not to use it, but the usage context is unambiguous.

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

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

With no annotations, the description carries the full burden. It discloses the side effects: revoking the session and clearing local credentials. This is meaningful behavioral context beyond the tool's name, though it doesn't cover potential edge cases like error states.

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 that is immediately understandable, front-loaded with the core action and followed by the behavioral details. 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 zero-parameter, no-output tool, the description fully covers what an agent needs to know to invoke it correctly. There is no missing information.

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, and the schema is empty. Per the rubric, the baseline is 4. The description doesn't need to add parameter semantics since there are none to describe.

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 clearly states the verb 'Sign out' and the resource 'your IMG.LY account', and explicitly mentions the consequences (revokes session, clears credentials). It naturally differentiates from the sibling 'login' without needing to name it.

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 the purpose obvious — it is the action to end a session. It doesn't explicitly state when not to use it, but for a simple logout tool this is sufficiently clear and no alternatives need to be excluded.

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

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

With no annotations, the description fully discloses behavior: output is PNG (lossless), each block gets a 0.25 megapixel budget adjusted to aspect ratio (with examples), at most 10 blocks per call, no size/format knobs, and the revision is loaded before rendering to ensure correct scene resolution on shared servers. This is rich, specific behavioral detail that goes far beyond a simple 'renders pages' statement.

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 lengthy but every paragraph serves a purpose: purpose, parameter semantics, usage guidance, pixel budget, and alternative routing. It front-loads the core purpose in the first sentence and uses code formatting for parameter names. It's not bloated; it's thorough, though slightly verbose for a tool with only two parameters.

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

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

Given no output schema and no annotations, the description covers everything an agent needs: how to use each parameter, the rendering behavior (PNG, resolution per block), limits (max 10), and when to choose alternatives like `export`. It even addresses edge cases like shared-server state and pixel budget for fine detail. There are no obvious gaps that would prevent 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?

The schema already describes both parameters at 100% coverage, but the description adds significant semantics: `blockIds` is a list whose order matters, can be omitted to preview all pages, and has a 10-block cap; `revision` is required and loaded before rendering to resolve ids against the right scene. This adds operational meaning beyond the schema's static field 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 verb and resource: 'Render blocks (almost always pages) to inline images so you can see the result.' It clearly distinguishes itself from the sibling `export` by contrasting inline images with native-resolution output and an `httpUrl`. This is not a tautology; it tells the agent exactly what the tool does and how it differs from similar 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 description gives explicit when-to-use and when-not-to-use guidance: 'Preview several blocks at once when REVIEWING or capturing a finished design... While BUILDING a multi-page design, keep previewing each page right after you build it.' It also directs the agent to alternatives: 'For native-resolution certainty, `export` the page and open its `httpUrl`' and 'To eyeball fine detail, preview the suspect BLOCK directly.' This is comprehensive routing advice.

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

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

With no annotations, the description carries the burden of disclosing behavior. It adds the non-obvious side effect that 'the root's title is updated' regardless of which revision is passed, which is valuable behavioral context. It does not cover reversibility or permissions, but the key side effect is disclosed.

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

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

The description is two sentences with no fluff. The action is front-loaded in the first sentence, and the second adds behavioral detail and usage guidance. Every sentence 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 simple two-parameter rename tool with no output schema or annotations, the description covers the operation, parameter semantics, and usage context. It does not mention return values or error conditions, but these are less critical given the low complexity and straightforward action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains that 'revision may be any revision in the lineage' and that the root's title changes, giving meaning to both parameters. The title parameter's role is implied as the new name, though not explicitly stated, so a slight deduction 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 opens with 'Rename a design,' which is a specific verb and resource. It further distinguishes the action by noting that any revision in the lineage can be used and that the root's title is updated, clarifying exactly what the tool does.

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 states 'Use this when the title set at design creation no longer fits,' giving a clear context for use. However, it does not mention alternatives or exclusions, such as using the 'edit' tool for other properties, so it lacks full sibling differentiation.

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

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

With no annotations, the description carries full behavioral burden and does it well. It discloses that recording is a 'claim about work already done', not the action itself, and explains the side effect on `export` (adds a reminder if revision is not covered). It also clarifies the semantic of pass/fail outcomes. This goes beyond what an annotation could 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?

Despite being ~140 words, every sentence contributes. The purpose is stated first, followed by verdict semantics, then the export interaction, and a closing note on re-judging. It is structured with paragraphs and clear separation of ideas, front-loads the critical 'never call without' warning, and avoids redundancy. Appropriate length for the behavioral nuance it conveys.

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 tool with no output schema, the description covers all necessary context: the action's role in the judge workflow, prerequisites (actual previews), the meaning of each verdict, the interaction with `export`, and the policy for re-judging. An agent has everything it needs to decide to call and to use parameters 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 the baseline is 3, but the description adds significant semantic depth. It elaborates the meaning of 'pass' and 'fail' with specific threshold criteria (each axis ≥ 8) and clarifies that `revision` must be the id whose renders were previewed. This explains the purpose of both parameters beyond their schema types.

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 precise verb-resource pairing: 'Record the verdict of a judge loop you have COMPLETED for a revision.' It explicitly names the tool's role as the final step of the `judge` skill and distinguishes it from siblings by referencing its relationship to `export`. No ambiguity about what the tool does.

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 conditions for use: 'never call this without having scored the axes against actual `preview` renders.' It also instructs when to record a new scorecard ('Judging again after further edits? Record a new scorecard'), and explains the consequence of not covering a revision in `export`. Clear when-to-use and when-to-refrain guidance.

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

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

With no annotations, the description carries the full burden, and it discloses non-obvious behavior: entry documents are always returned whole and ignore offset/limit, query acts like Grep, large files should be sliced, and a search should be attempted twice before a full read. It also states the smart-case and invalid-pattern consequences in the schema-backed text, with no contradiction.

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

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

The operational guidance is front-loaded and each section has a role, but the available_skills block is lengthy. It is justified because the enum values and triggers must be documented somewhere, and the prose is tightly written given it covers ten skills.

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 7-parameter tool with no output schema and no annotations, the description covers the workflow, how to choose each skill, the search-vs-read strategy, and the entry-document/index hints. An agent can invoke this tool correctly without needing external knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns one more point by explaining how the parameters chain together (name → query → path → offset/limit) and by adding behavior the schema does not state, such as entry documents ignoring offset/limit. It does not duplicate every field, relying on the rich schema for details like maxResults/context.

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

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

The description opens with a specific verb and object: 'Load a skill — an instruction document...' and goes on to list ten named skills with one-line definitions, making it unmistakable what is loaded. It also separates the skill mechanism from the skills themselves, so an agent can tell 'skill' from content-bearing tools like list or view.

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 before/after rule ('Read the relevant skill BEFORE attempting work it covers'), a numbered intended sequence, and per-skill trigger conditions ('Use when...', 'Triggered for any task using...'). It even routes between alternatives within the tool ('For exact TypeScript signatures use the `api` skill 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?

With no annotations provided, the description carries the full burden—and it delivers: it discloses that the URL stays live and re-renders on `edit`, that pinning freezes a revision, and that human saves create new revisions with engine-computed change summaries. It also warns against re-emitting a fresh URL every turn, which is exactly the kind of non-obvious behavior an agent needs.

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 every sentence earns its place: core behavior, the critical 'emit once' instruction, the pin variant, and the downstream save/revision loop. The most important operational guidance is front-loaded, and there is no filler.

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

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

There is no output schema, so the description must explain what is returned—and it does (a stable URL, or a frozen permalink when pinned). It also covers the lifecycle after the human saves, which is essential for the agent to continue from the right revision. Given the tool's moderate complexity, nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it translates `pin: true` into a 'frozen permalink' and ties it to concrete use cases like 'look at exactly this' or comparing revisions. It also clarifies that any revision resolves to its root and opens at the design head.

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

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

The description opens with a specific verb and resource: 'Get a URL the human can open to view and edit the design in CE.SDK.' It clearly distinguishes the tool's core output (a stable, live design URL) from the surrounding editing/management tools and explains the two modes (live vs pinned).

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 usage context: emit the live URL once, avoid re-emitting every turn, and use `pin: true` for exact revisions or comparisons. It doesn't explicitly name sibling alternatives or state when not to use this tool, but it provides strong operational guidance for the main decision point.

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