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

No annotations are provided, so the description carries the full burden of disclosing behavior. It states that the tool imports an image but does not mention that it modifies a canvas, how baseRevision protects against conflicts, whether the operation is reversible, or what happens on failure. This is a significant transparency gap for a mutation tool.

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 concise sentence that is easy to scan and front-loads the core action. It could be slightly clearer, but there is no wasted wording.

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 tool with five required parameters, no annotations, and no output schema, the description is too sparse. It omits the role of baseRevision, mutationId semantics, behavior on conflicting revisions, and what the caller should expect after a successful import.

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 60%, with canvasPath, sourcePath, and projectPath already documented. The description's 'raster image' and 'current Workspace' phrases mostly restate schema details. It adds no meaningful information about mutationId or baseRevision, both of which are undocumented in 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 uses a specific verb ('imports') and identifies the resource ('one bounded local raster image') and source scope ('current Workspace'). It is clear about what the tool does, though it does not explicitly distinguish itself from sibling tools and 'bounded' is left unexplained.

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?

There is no guidance on when to use this tool versus alternatives. It does not state when to prefer it over related sibling tools like push_canvas, replace_canvas, or remove_unused_assets, nor does it mention prerequisites such as the need for a baseRevision.

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 does disclose two real behavioral traits: atomicity (all-or-nothing application) and the base-revision requirement, which implies the call will not blindly overwrite newer state. However, it does not disclose conflict behavior on stale revisions, whether this is a destructive write, or how failures surface. 'Atomically' also misleadingly implies the description is complete when it is not.

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 zero filler. The verb and the atomicity constraint are front-loaded, and the base-revision qualifier earns its place by explaining the concurrency contract. This is appropriately sized for what it attempts to convey.

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?

This is one of the most complex tools in the set (5 required params, an 11-op changes union, 200-item batches, no output schema, no annotations), yet the description is a single sentence. It omits how to construct changes (e.g., from inspect_canvas), the meaning of clientRefs, what happens on a revision mismatch, and the return/conflict behavior. The agent is left to infer critical operational details.

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 40%, so the description must compensate. It partially does: 'element and canvas changes' maps to the changes parameter, and 'at one base revision' explains baseRevision's purpose. But mutationId's role (e.g., idempotency/deduplication) is never explained, and the clientRef-vs-elementId referencing model that pervades the changes schema is absent. The description adds a little meaning but leaves most parameter semantics to 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 ('applies'), a clear resource ('semantic element and canvas changes'), and a defining constraint ('atomically... at one base revision'). This communicates a batch-commit operation with optimistic concurrency semantics. However, it does not explicitly distinguish itself from siblings like push_canvas, replace_canvas, or save_canvas_copy, which an agent may confuse it with.

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

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

No guidance is provided on when to use this tool versus alternatives such as push_canvas (full-state commit) or replace_canvas. The 'at one base revision' phrase implies a concurrency-aware workflow, but no explicit when-to-use, prerequisites, or exclusions are stated. For a tool with 24 siblings, this is a significant gap.

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 information burden. It discloses the key operational requirement that the open Browser View must be on the same saved canvas revision, and it explains the dual output behavior (PNG plus diagnostics). It does not discuss errors, side effects, or failure modes, but for a capture/read-style tool the stated precondition covers the most important behavioral constraint.

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 three concise sentences that front-load the primary output, then explain model suitability, then state the required precondition. Every sentence adds useful information and there is no redundant or filler content.

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 that there is no output schema and no annotations, the description does well by naming both return artifacts and the necessary precondition. It is complete enough for an agent to understand what this tool produces and when it can be invoked, though slightly more detail about how clipping diagnostics are structured or when capture fails would make it fully 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 60%, and the schema already documents the critical parameters revision, canvasPath, and projectPath with helpful examples. The description itself adds little parameter-level meaning, and the optional maxWidth and maxHeight parameters are only described by constraints and defaults in the schema. This is adequate but not enhanced by the 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 clearly states that the tool returns a standard MCP PNG rendered by the open Browser View plus text clipping diagnostics, and explains that image-capable models can use the PNG while other models can use the diagnostics. This is a specific verb-plus-resource description that makes the tool's intent clear, though it does not explicitly name or contrast any sibling tool such as export_canvas.

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 the tool can be used: the View must already be open on the same saved canvas revision. It also gives modality guidance by telling which models benefit from the PNG versus the diagnostics. It does not explicitly state exclusions or alternatives, but the precondition and intended audience are 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 provided, the description must carry the full burden of behavioral disclosure. It states that the tool checks validity, but it does not disclose whether the operation is read-only, what happens on invalid input, whether it returns a boolean/result/throws, or what 'valid bounded standard document' means in practice.

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 concise sentence with no filler or redundancy. It is front-loaded with the primary action and resource, though the unexplained jargon 'bounded standard document' slightly reduces clarity for an agent.

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

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

The tool has no output schema and no annotations, so the description must explain what the agent can expect. It does not describe the return value, success/failure behavior, or validation criteria, leaving a significant gap for a tool that appears to be a validation check.

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 have detailed descriptions with examples and usage caveats. The tool description itself adds no parameter-level semantics, so the baseline of 3 is appropriate since the schema already 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?

The description clearly states the tool's action ('Checks') and resource ('canvas'), and adds specificity by saying it verifies a canvas is a 'valid bounded standard document.' This goes beyond the tautological title, though the term 'bounded standard document' is somewhat jargon-heavy and not elaborated.

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

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

No guidance is provided about when to use this tool versus alternatives such as inspect_canvas, open_canvas, capture_canvas, or report_canvas_capture. The description gives no context for the intended workflow or preconditions, leaving the agent to infer when validation 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?

With no annotations, the description carries the full disclosure burden, but it only states that a canvas is created and opened. It does not mention that baseProjectRevision indicates optimistic concurrency, what happens if the canvas path already exists, or what the response is.

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 front-loaded sentence with no filler, and it immediately names the core action and 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?

For a mutation tool with four required parameters, no annotations, and no output schema, the description is too thin. It omits the meaning of the two undocumented required parameters, any conflict behavior, and what a successful call returns.

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 documents projectPath and canvasPath, but the required mutationId and baseProjectRevision have no descriptions, and the tool description adds no parameter explanation. An agent cannot infer the purpose of the revision/mutation fields from the 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 uses a specific verb ('creates and opens') and resource ('empty canvas') and scopes the action to 'one project.' This clearly differentiates it from siblings like create_project, open_canvas, duplicate_canvas, and list_canvases by emphasizing an empty, newly-created canvas.

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

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

No guidance is given on when to use this tool rather than alternatives such as replace_canvas, duplicate_canvas, or save_canvas_copy, and no exclusions or prerequisites are stated. The only implied use case is needing a new empty canvas, which 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal one side effect (opening the default canvas), but it is silent on whether creation is idempotent, what happens if the project path already exists, what 'managed' entails, and what permissions or side effects accompany creation. The required 'mutationId' parameter strongly suggests idempotency semantics, yet the description never mentions 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 a single front-loaded sentence with zero filler, which earns high marks for conciseness. However, at only eight words it is undersized relative to the tool's complexity (four parameters, no annotations, no output schema), so it is not fully 'appropriately sized.'

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 annotations and no output schema, the description must carry more weight than it does. It omits the return value, error behavior on existing paths, whether the default canvas is created or merely opened, and the purpose of mutationId. For a mutation tool in a rich domain with 24 siblings, this is a meaningful gap.

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 50%, so the description must compensate for the undocumented 'name' and 'mutationId' parameters. It does not: it only loosely echoes 'defaultCanvasPath' via 'opens its default canvas,' and gives no meaning for the required idempotency key or the meaning of 'name' (display name versus path basename).

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 ('Creates') and resource ('managed project'), and adds the secondary behavior 'opens its default canvas,' which distinguishes it from open_project and create_canvas. The term 'managed' is unexplained but does not obscure the core purpose. It falls short of a 5 because it does not explicitly contrast with sibling 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?

No guidance is given on when to use this tool versus siblings such as create_canvas or open_project. The description never states conditions, exclusions, or which alternative should be chosen instead, leaving the agent to infer selection from the tool name alone.

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 behavioral burden. It does disclose that deletion requires exact path and revision confirmation, which is meaningful safety-related context for a destructive operation. It stops short of stating that deletion is irreversible or what happens when the base revision does not match, but the core destructive nature is clear.

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 tightly written sentence that leads with the action and includes the most important safety precondition. There is no filler, redundancy, or restating of obvious schema 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 destructive tool with five required parameters, no annotations, no output schema, and a large sibling set, one sentence is insufficient. The description does not explain behavior on revision mismatch, the role of mutationId, or how this tool relates to replace_canvas and delete_project. It provides a foundation but leaves critical operational context unstated.

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

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

The schema describes projectPath, canvasPath, and confirmCanvasPath, but it leaves mutationId and baseRevision undocumented in the schema. The description adds a useful hint about 'revision confirmation' and 'exact path,' but it does not explain mutationId's purpose, and with only 60% schema coverage a destructive 5-parameter tool needs more parameter-level 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?

The description states a specific verb ('Deletes') and a specific resource ('a canvas'), which is further narrowed by the title to an Excalidraw canvas. It also distinguishes this from sibling deletion tools like delete_project by targeting the canvas resource, not a project.

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 conveys a clear precondition: deletion should happen only 'after exact path and revision confirmation.' However, it does not explicitly explain when to prefer delete_canvas over related sibling tools such as replace_canvas, duplicate_canvas, or delete_project, leaving the alternative-routing largely to the agent.

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

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

With zero annotations, the description carries the full behavioral burden. It does disclose a meaningful trait: the deletion is guarded by exact path confirmation and a base revision check, signaling a deliberately protected destructive operation. However, it stays silent on whether deletion is permanent or recoverable, how a stale revision mismatch is handled, and what happens to the project's canvases and assets on deletion.

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 10-word sentence front-loads the action ('Deletes a managed project') and packs the key safety qualifier into a compact dependent clause. Every word earns its place; there is no filler, no repetition of schema content, and no preamble.

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 operation with four required parameters and zero annotations, the description is thin. An agent invoking this tool would still need to know whether the deletion is irreversible, what happens on revision mismatch, whether canvases under the project are cascade-deleted, and what the success/failure response looks like. The description answers only the 'what' and the minimal 'guarded by confirmation' part, leaving high-stakes operational questions open.

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%: projectPath and confirmProjectPath have descriptions, while baseProjectRevision has only a regex pattern and mutationId has no description at all. The description's 'exact path and revision confirmation' adds meaning by clarifying the two path parameters as a confirmation pairing and the revision as a concurrency guard. It does not explain why two identical path fields are required or what mutationId is for (e.g., idempotency).

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 ('Deletes') and resource ('managed project'), making the tool's core action unmistakable. The qualifier 'after exact path and revision confirmation' adds the distinguishing safety mechanism. It differentiates cleanly from siblings like rename_project, duplicate_project, and delete_canvas, though the term 'managed' is never defined, leaving minor ambiguity about which projects qualify.

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 usage context: call this when a managed project must be deleted and confirmation data is available. However, it provides no explicit when-not-to-use guidance, no mention of alternatives like delete_canvas for smaller-scope deletions, and no statement about whether this should be chosen only as a final action. The guidance is present only by implication.

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 of behavioral disclosure. It only says 'Copies a canvas', which implies a new resource is created, but it does not explain conflict behavior when newCanvasPath already exists, the role of baseRevision and mutationId, or whether the operation is reversible or has 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 a single, short sentence with no filler, and the core action is front-loaded. It is concise, though it sacrifices helpful behavioral detail that other dimensions require.

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 mutating tool with five required parameters, no annotations, and no output schema, the description is too minimal. It omits details about concurrency semantics, overwrite behavior, return values, and error conditions, making it incomplete for an agent to invoke confidently.

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 60%, and the description adds no parameter-level meaning. The required baseRevision and mutationId parameters are left unexplained both in the schema and in the description, leaving an agent without enough information to supply them correctly.

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 ('Copies a canvas') and a clear scope ('inside the same project'). This distinguishes it from duplicate_project, but it does not explicitly differentiate it from other canvas-copying siblings like save_canvas_copy.

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 same-project scope implies when this tool is appropriate, but the description gives no explicit guidance about when to use it versus alternatives such as save_canvas_copy or duplicate_project. There are no exclusions or conditions stated.

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 does reveal one meaningful trait — the operation only proceeds when the base revision is current, implying an optimistic-concurrency check — but it omits failure behavior on stale revisions, the fact that a new project entity is created, idempotency semantics behind mutationId, and any side effects or return value.

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 with the verb and key condition front-loaded; every word earns its place and there is no filler. It is efficient, though it leans toward under-specification rather than comfortably concise.

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?

This is a mutating tool with 5 parameters, no annotations, no output schema, and only 40% schema coverage, yet the description offers just one sentence. An agent is left without guidance on the meaning of mutationId and name, the result of a stale-revision attempt, or what the operation returns — far more context is needed for safe 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 only 40%, covering projectPath and newProjectPath, while baseProjectRevision, mutationId, and name are undocumented in the schema. The description partially compensates by linking 'when its project revision is current' to baseProjectRevision, but it adds nothing about mutationId (presumably an idempotency key) or name (presumably the new duplicate's display name), which the schema also fails to explain.

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 ('Copies') and resource ('a managed project'), and adds the distinguishing condition 'when its project revision is current.' This separates it from siblings like duplicate_canvas (canvas resource) and create_project (creates from scratch rather than copying an existing project). It is clear but does not elaborate on what the copied result contains or how it differs from a fresh create.

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

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

No guidance is given on when to use this tool versus create_project or duplicate_canvas, and no alternatives are named. The phrase 'when its project revision is current' implies a precondition the agent must verify (likely via inspect_project), but the description never says how to satisfy it or what to do when the revision is stale.

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 burden of behavioral disclosure. It does reveal meaningful behavior: it opens the export view and triggers a download in one of three formats. It does not, however, mention side effects, whether the original canvas is modified, where the file is saved, or what the agent should expect as a result.

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 sentence with no filler or redundancy. Every component—opening the export view, downloading, and listing the three formats—earns its place, and the most important information is presented immediately.

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 annotations and no output schema, the description leaves important context gaps. It does not state what the tool returns after the download, how the agent can confirm success, or how this differs from closely related sibling tools such as save_canvas_copy, capture_canvas, or pull_canvas. A tool with three required parameters and a large sibling family needs more contextual grounding.

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 documents projectPath and canvasPath with examples and constraints, and format has an enum of json/svg/png. The description reinforces the format parameter by naming JSON, SVG, and PNG, but it adds no new meaning for the path parameters. With roughly 67% schema coverage, a middle score is appropriate because the description partially compensates for the format parameter's lack of prose.

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 a specific action: opens the export View and downloads the saved canvas as JSON, SVG, or PNG. It names both the resource (canvas) and the supported output formats, which conveys the core purpose. It does not explicitly contrast itself with sibling tools like save_canvas_copy or capture_canvas, so it stops short of a 5.

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 when the tool should be used: whenever a user wants the canvas exported/downloaded as JSON, SVG, or PNG. However, it provides no explicit guidance about when not to use it or which sibling tool would be a better fit, such as save_canvas_copy for copying a canvas or capture_canvas for a visual snapshot.

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 behavioral disclosure burden. It does disclose that the operation is read-oriented and returns filtered, paginated data, optionally including a standard document. However, it does not clarify side effects, output shape, or what 'small standard document' actually means.

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 one front-loaded sentence with no filler, and every word earns its place. The phrase 'small standard document' is cryptic and compresses too much meaning, which slightly reduces structural effectiveness.

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

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

For an 8-parameter tool with no annotations and no output schema, a one-sentence description is insufficient. It omits usage context, parameter semantics, key concept definitions, and any basis for choosing among the many canvas-related sibling tools. The agent lacks enough context to call this tool reliably.

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 25%, so the description must compensate for six undocumented parameters. It offers only category-level hints: 'filtered' maps roughly to ids/text/types, 'paginated' to limit/cursor, and 'optionally ... document' to includeDocument. It does not explain cursor usage, allowed types, or the meaning of the returned elements.

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 ('Returns') and a clear resource ('canvas'), and 'filtered, paginated semantic elements' distinguishes it from raw canvas export or project inspection. However, terms like 'semantic elements' and 'small standard document' are unexplained, and differentiation from siblings such as open_canvas, check_canvas, and capture_canvas is only implicit.

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?

There is no guidance about when to use inspect_canvas versus alternatives like inspect_project, open_canvas, check_canvas, capture_canvas, or export_canvas. The agent must infer usage entirely from the title and sibling names.

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. 'Returns' implies a read operation but does not explicitly state that the tool is non-destructive, what 'bounded' means, or what happens if the project path is invalid. No side effects or special behaviors are 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 a single, compact sentence with no wasted words. It is front-loaded with the primary action and resource, though the term 'bounded' could benefit from clarification regardless of conciseness.

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 no output schema and no annotations, so the description must substitute for both. It fails to describe what the 'project and canvas summary' actually contains, what boundaries apply, or how the response is structured. This is inadequate for an agent to confidently interpret the result.

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% because the only parameter, projectPath, is already documented with a clear example. The tool description adds no new 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 uses the specific verb 'Returns' with a clear resource: 'bounded project and canvas summary.' This distinguishes it from list-style siblings like list_projects and from canvas-level tools like inspect_canvas. However, 'bounded' is slightly ambiguous and does not fully explain the scope.

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

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

No guidance is provided about when to use inspect_project versus alternatives such as inspect_canvas, list_projects, or check_canvas. There is no mention of appropriate context, exclusions, or prerequisites, leaving the agent to infer usage from the tool name and sibling list.

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 full responsibility for disclosing behavior. It only says 'Lists canvases,' which implies a read operation, but it does not mention output format, behavior when the project is missing or empty, or any other runtime characteristics.

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 five-word sentence with no redundancy. The key action 'Lists' is front-loaded, and it is appropriately sized for a simple one-parameter listing tool.

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

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

The tool is simple and its only parameter is fully documented, but there is no output schema and no annotations. The description is adequate for a basic invocation, though it leaves questions about return value shape and edge-case behavior unanswered.

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 parameter semantics are already fully documented in the input schema. The description adds no new detail about projectPath beyond implying its role in scoping to 'one project.'

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 ('Lists') and resource ('canvases') with a scope ('in one project'). It clearly distinguishes this from sibling list_projects by identifying canvas objects rather than project objects as the subject.

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 'in one project' gives useful context and implies that a projectPath is needed, but the description does not explicitly address when to use this tool versus alternatives or mention any exclusions. No sibling tool is referenced as an 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?

With no annotations, the description carries the full behavioral burden. 'Lists' clearly signals a read-only operation, and 'managed and discovered' plus 'current Workspace' add useful scoping context. It could further disclose ordering, pagination, or return shape, but for a zero-parameter listing operation the behavior is transparent enough.

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, well-structured sentence with no filler. It front-loads the action ('Lists') and resource ('Excalidraw projects') before adding 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?

For a simple, parameterless listing tool, the description is complete: it names the resource, the scope, and the action. No output schema exists, but 'Lists... projects' sufficiently implies the return type. There are no missing prerequisites or hidden inputs.

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 documents 100% of them, so there is nothing for the description to add. The baseline of 4 for a parameterless tool 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 uses a specific verb ('Lists'), a clear resource ('Excalidraw projects'), and adds scoping detail ('managed and discovered', 'current Workspace'). This clearly distinguishes it from sibling tools like list_canvases and the create/update/delete project actions.

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 verb 'Lists' and the resource 'projects', but the description gives no explicit guidance about when to choose this tool over alternatives such as list_canvases or inspect_project. There is no exclusionary language or mention of 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 are absent, so the description must carry the behavioral burden. It gives no information about side effects, whether the operation is read-only or mutating, permission requirements, or what happens if the canvas or project does not exist. 'Open' is ambiguous regarding state 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 a single vague sentence that essentially restates the title without adding meaningful detail. It is under-specified rather than appropriately concise, lacking the substance needed for an agent to understand the tool's behavior.

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 annotations and no output schema, the description is the sole source of behavioral context. It provides no information on expected results, error conditions, or use cases, making it inadequate for a tool with two required parameters in a rich sibling landscape.

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 descriptions are thorough (100% coverage) with examples and explicit constraints like 'Never pass only main.excalidraw' and clarify the projectPath/canvasPath relationship. The tool description adds nothing beyond the schema, so 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 states 'Opens one canvas inside its project', which names a verb and a resource and distinguishes from open_project. However, it does not clarify what 'open' means operationally (load, select, display, set active), leaving ambiguity. It also does not differentiate from other canvas tools like check_canvas, capture_canvas, or inspect_canvas.

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

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

No guidance is provided on when to use this tool versus siblings such as open_project, list_canvases, or check_canvas. There are no prerequisites, exclusions, or context about when this tool is the right choice among the many canvas-related 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what is opened but does not mention whether the action is read-only, whether it creates or modifies any state, or what happens if the project does not exist.

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, focused sentence with no filler. The key scoping information, 'default canvas of an existing project', is front-loaded and directly useful for tool selection.

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 open operation, the description plus schema are minimally complete. However, with no annotations and no output schema, it lacks explicit side-effect or error behavior and does not mention alternative sibling tools such as open_canvas.

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 already documents projectPath with constraints and an example, so the description does not need to add much. It adds the notion that the project must already exist, but this is a mild addition 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 uses a specific verb ('opens') with a precise target ('default canvas of an existing Excalidraw project'). The phrase 'default canvas' distinguishes it from open_canvas, and 'existing' distinguishes it from create_project.

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 existing projects and their default canvas, but it does not explicitly say when to prefer open_canvas for non-default canvases or when not to use this tool. The usage context is implied rather than explicitly guided.

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 must carry the behavioral disclosure burden. It indicates a read-like behavior ('returns a document') and a precondition, which is useful, but it does not explain what happens when the revision is not stale, whether any server interaction or validation occurs, or what errors may arise. These gaps prevent a higher score.

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, compact sentence with no filler words. However, it is so terse that it sacrifices important clarifying details, such as what 'bound document' means and the exact behavior when 'app revision' is not stale, so it earns a strong but not perfect conciseness score.

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 there is no output schema and no annotations, the description leaves too much unstated: the return value's format, behavior for a non-stale revision, error handling, and how currentRevision influences the call. The low tool complexity makes a more complete description feasible, but this one leaves the agent guessing about key operational details.

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 50%: canvasPath is documented in the schema, but currentRevision is described only by a regex pattern. The description adds no parameter-level meaning—it mentions 'app revision' indirectly but never explains the currentRevision parameter, its purpose, or how it interacts with staleness. The description fails to compensate for the schema's missing documentation.

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

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

The description names a specific action ('returns') and resource ('the bound document') and adds a distinctive condition ('when the app revision is stale'), which goes beyond a mere restatement of the title. However, 'bound document' is somewhat ambiguous and the description does not explicitly differentiate pull_canvas from sibling read tools like open_canvas or inspect_canvas.

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 states when to invoke the tool: when the app revision is stale. This provides a concrete use condition, but it does not mention when not to use it or name any alternative sibling tools, so the guidance is helpful but incomplete.

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 alone must disclose side effects and failure behavior. It mentions compare-and-swap, but does not explain what happens on revision mismatch, whether the operation creates or updates, or what other side effects occur.

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 focused sentence with no filler and front-loaded action. It is maximally concise, even though that brevity reduces clarity in other dimensions.

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 CAS write tool with a nested document schema and no output schema or annotations, this one-line description is not complete. It omits return behavior, error conditions, and revision handling details.

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?

Only canvasPath has a schema description; baseRevision, mutationId, and document are undocumented. The compare-and-swap phrase hints at baseRevision and mutationId, but the description does not explain their roles, idempotency, or the expected document structure.

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 title and description state a clear action: saving the bound standard document with compare-and-swap. The CAS mention helps distinguish it from ordinary save or copy operations, though 'bound standard document' is somewhat vague.

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 no guidance on when to use push_canvas versus siblings such as save_canvas_copy, replace_canvas, pull_canvas, or apply_canvas_changes. The compare-and-swap hint is not expanded into concrete 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?

With no annotations present, the description carries the full behavioral disclosure burden. It does reveal two important traits: the operation is atomic and removes only files not referenced by live image elements. However, it does not state that deletion is permanent, whether the canvas file is modified, whether there are rollback possibilities, or what happens if the base revision is stale. For a destructive operation, this leaves meaningful gaps.

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, tightly worded sentence with no filler. The key behavioral qualifiers 'atomically' and 'not referenced by any live image element' are front-loaded, giving an agent the core semantics immediately. It is concise without being under-specified for its stated 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 no output schema, no annotations, and four required parameters, the overall description is too sparse to fully enable correct invocation. An agent is not told what baseRevision and mutationId semantically mean, whether the operation is reversible, what the success/failure response looks like, or what happens to the canvas after removal. This is insufficient for a destructive tool with no annotation safety hints.

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 50%, so the description should compensate for undocumented parameters. It does not explain mutationId or baseRevision at all, nor does it clarify how they affect the removal operation. While canvasPath and projectPath are documented in the schema, the missing semantic context for the other two required parameters is a significant deficiency.

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: it removes files not referenced by live image elements. This clearly communicates the tool's narrow scope and distinguishes it from asset-adding or canvas-editing siblings, even without naming them explicitly. It is not merely restating 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 gives no explicit guidance about when to use this tool versus alternatives like add_canvas_asset, replace_canvas, or apply_canvas_changes. It does not mention preconditions, such as needing a stable base revision or an existing project/canvas, nor does it say when cleanup should or should not be attempted.

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. 'Renames' implies a mutating operation, but the description does not explain whether the operation is reversible, what happens if the target path already exists, whether the old path is removed, or why baseRevision and mutationId are required. This is a significant gap for a mutation tool.

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 efficient sentence with no filler words. It front-loads the core operation and scope. The brevity, however, sacrifices useful detail, which is a tradeoff, but conciseness itself is handled well.

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 tool with 5 required parameters, no output schema, and no annotations, the description is notably incomplete. It omits the semantics of mutationId and baseRevision, preconditions, side effects, and error conditions. An agent would struggle to call this tool correctly without external knowledge or schema inspection.

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 description adds no parameter-level meaning beyond the input schema. Schema coverage is 60%: three parameters (canvasPath, projectPath, newCanvasPath) are well-documented, but mutationId and baseRevision have no schema descriptions and the description does not compensate by explaining their purpose (e.g., conflict resolution and idempotency).

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 'Renames' and the resource 'canvas', and adds a scoping constraint 'inside the same managed project.' It is distinguishable from rename_project, though it does not explicitly differentiate from similar canvas operations like replace_canvas or duplicate_canvas.

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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., the canvas must already exist), when not to use it, or which sibling tools are better suited for similar operations. The 'same managed project' clause hints at scope but is not enough to constitute usage 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?

The description discloses one behavioral aspect: the operation is conditional on the project revision being current, implying an optimistic concurrency check. However, it does not describe failure modes, side effects (e.g., whether the project is modified in place), or idempotency. Given no annotations are provided, the description carries the full burden but remains mostly opaque.

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, compact sentence that front-loads the action and object. It contains no extraneous words, qualifying clauses, or redundant information. The structure is highly efficient and easy to parse.

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 five parameters, but the schema descriptions cover only two (40%). The description does not compensate for the missing parameter explanations, nor does it clarify the concurrency model or the purpose of mutationId. Since there is no output schema, the description could have hinted at the return value, but it remains silent. Overall, an agent would be left with significant uncertainty about how to correctly invoke this tool.

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

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

The tool description adds no parameter-specific meaning beyond what the schema already provides for projectPath and newProjectPath. It does not explain the roles of baseProjectRevision or mutationId, leaving their purpose unclear. With schema coverage at only 40%, the description does nothing to fill the gaps, making parameter semantics weak.

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 ('Renames') and the object ('a managed project'), making the core purpose unambiguous. The added condition 'when its project revision is current' introduces a specific requirement, which is useful but not strictly necessary for basic purpose clarity. It does not explicitly contrast with sibling tools like rename_canvas, but the object type differs enough to avoid confusion.

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

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

No guidance is provided on when to use this tool versus alternatives such as create_project, duplicate_project, or rename_canvas. The description lacks any contextual advice, prerequisites, or scenarios where this tool is the preferred choice. Without this, an agent cannot determine when to invoke this tool over others.

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 mentions 'atomically replaces' which implies destructive behavior, but does not state that the existing canvas is overwritten, what happens on validation failure, whether changes are reversible, or what 'restores' means. It lacks essential details about side effects and failure modes.

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 concise sentence, but it is vague and uses jargon like 'standard document' without elaboration. It is not front-loaded with the most critical information (what exactly is replaced and the atomic guarantee). It is concise but not particularly well-structured or helpful.

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 complexity (5 required params, nested document object, no output schema, no annotations), the description is grossly inadequate. It fails to explain the atomic replacement semantics, how baseRevision is used for optimistic concurrency, what mutationId is for, or what happens to attached files and appState. An agent cannot safely invoke this tool 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 coverage is only 40% (projectPath and canvasPath have descriptions). The description adds no parameter-specific information. It does not explain the role of baseRevision (concurrency control), mutationId (idempotency), or the structure of document. With low schema coverage, the description should compensate, but it does not.

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 verb (replaces) and a resource (standard document), but 'standard document' is ambiguous and doesn't clearly tie to an Excalidraw canvas until the title. It also adds 'validates, restores' without explaining what these mean. It does not distinguish from sibling tools like apply_canvas_changes or push_canvas, which also modify canvas content.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of atomic replacement being preferred for full-document swaps, nor any exclusions (e.g., partial updates). The agent is left to infer use cases from the name alone.

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 disclosure burden. 'Settles' conveys that a pending capture transitions to a resolved state, but the description does not disclose side effects (e.g., whether the pending capture is removed from a queue, whether settling is idempotent, or what happens on an unknown commandId). Error behavior and post-conditions are absent.

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 14-word sentence with no filler, front-loading the core action ('Settles one pending Canvas Harness capture'). Every word earns its place, though given the tool's complexity as a result-reporting callback, the terseness borders on under-specification rather than elegant compression.

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 report/settle operation with zero annotations and no output schema, the description omits several things an agent needs: how this relates to capture_canvas (the obvious initiating sibling), what makes a capture 'pending', how commandId is obtained, and what happens on invalid or repeated settlement. The rich schema covers the outcome payload structure but not the surrounding 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 description coverage is 0%, and the description adds nothing about either parameter. The oneOf structure in the schema makes the outcome parameter fairly self-evident (succeeded with evidence vs. failed with message), but the semantic link between commandId and 'the pending capture' is never stated anywhere — the agent must guess that commandId identifies which capture to settle.

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 ('Settles') and resource ('one pending Canvas Harness capture'), which clearly distinguishes this from the initiating counterpart capture_canvas among the siblings. The term 'settles' accurately maps to the schema's outcome reporting structure. Some jargon ('Canvas Harness', 'bound Browser View') is unexplained, and it could more explicitly state that this is the reporting/callback step with a visible result.

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

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

Usage is only implied: 'settles one pending ... capture' suggests the agent should call this when a capture is pending and awaiting resolution. There is no explicit guidance about sequencing relative to capture_canvas, no mention of when a capture becomes pending, and no exclusions or stated alternatives. The name prefix 'report_' carries some of the inferential weight.

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 must carry behavioral context, but it only says 'saves' and 'new canvas in the same project.' It does not disclose side effects, whether an existing newCanvasPath is overwritten, idempotency behavior, or what happens to the original draft.

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 front-loaded sentence with no unnecessary words. It is concise, though its brevity comes at the cost of 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?

For a 4-parameter tool with a nested document object, no output schema, and no annotations, one sentence leaves critical gaps: what document should contain, the role of mutationId, and the expected result. The same-project and new-canvas constraints are useful but insufficient.

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%, and the description does not compensate. It loosely maps 'bound draft' to the document parameter and 'new canvas' to newCanvasPath, but mutationId and document remain effectively undocumented in the description, so an agent gets little additional meaning.

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

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

The description states a specific action and outcome: the bound draft is saved as a new canvas in the same project. This distinguishes it from applying changes to an existing canvas or duplicating an existing canvas, though 'bound draft' is not fully defined.

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

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

No guidance is given about when to use this tool versus alternatives such as duplicate_canvas, push_canvas, or apply_canvas_changes. The phrase 'as a new canvas' implies a save-as-copy use case, but no exclusions or selection criteria are provided.

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