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 only discloses that the result is a 'minimal valid document' — a genuinely useful scaffold hint. It omits what happens on path collision, whether the page persists in a checkpoint/timeline, and the side effects of a mutation. Too thin for a write tool with zero annotation coverage.

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 front-loaded sentence with no filler. It is efficient, though arguably too terse given the tool's mutation semantics and lack of annotations.

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

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

For a mutation tool with no annotations and no output schema, the description should explain the working-copy concept, collision/overwrite behavior, and expected_rev staleness at least in prose. None of this is present, leaving meaningful gaps an agent must guess at.

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

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

Schema description coverage is 100%, so all three parameters (path, title, expected_rev) are already documented in the schema, including the stale-revision refusal behavior. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

The description names a specific verb (Add), resource (HTML page), and scope (working copy), plus a distinguishing detail about how the page is created. It clearly separates itself from read-oriented siblings like web_read/web_pages, but does not explicitly reference any sibling by name.

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 when-to-use, when-not-to-use, or alternative guidance. The agent must infer that this is for creating a brand-new page as opposed to manipulating an existing one via web_insert_section or web_set_text. No prerequisites or conditions are 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, the description carries the full burden, and it does disclose that restore/delete are outside MCP scope. It still omits key mutation traits: whether saving overwrites an existing label, what happens on a revision mismatch, and whether the operation is reversible from the MCP side.

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

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

Two short sentences with zero filler; the primary action is front-loaded and the limitation follows. Every clause earns its place.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the description covers the action and the tool boundary but leaves expected_rev's role and failure behavior unexplained, which is the main gap an agent would hit in practice.

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 adds no parameter meaning at all. 'label' is undocumented and 'expected_rev' is only labeled 'Current revision' in the schema, so the important optimistic-concurrency semantics of expected_rev are never explained anywhere.

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

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

States a specific verb and resource ('Save a named checkpoint of the current working copy'), which is unambiguous. It does not differentiate against siblings like web_timeline or web_preview that might also relate to versioning, but the action itself is clear.

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 second sentence tells the agent that restore and delete are NOT available here and require a dashboard session, which is useful scoping. However, it never says when to create a checkpoint or in what workflow context, so usage selection against siblings is only implied.

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 that this is a read operation against the working copy, which is useful, but says nothing about return shape, ordering, pagination, or how unmatched selectors behave. Adequate but not rich.

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 front-loaded sentence with no filler; the read scope and matching rule are stated 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?

For a two-parameter read tool with no output schema, the description covers the operation and its matching semantics, and the schema documents file_id. It could say more about what the read returns, but nothing critical to invoking it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description adds genuine meaning beyond the schema by specifying that the selector is matched by substring containment ('contains the requested text') rather than exact match, which the schema's '.hero' example does not convey.

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

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

States a clear verb and resource: 'Read CSS rules whose selector contains the requested text.' The read-only framing distinguishes it implicitly from web_css_set, and the substring matching is a specific scope, but no sibling is named explicitly.

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

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

The phrase 'from the current working copy' gives a hint about context, and the substring-selector framing implies when it applies, but there is no explicit when-to-use/when-not guidance or routing to sibling tools like web_css_set or web_find.

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 states that a rule is set but does not disclose permissions required, whether existing rules are overwritten, what happens on stale revisions (beyond the schema), or any error behavior. 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 two sentences, front-loads the core action, and includes a concrete example without any wasted words. Every sentence earns its place.

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

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

Given a mutation tool with no annotations and no output schema, the description is too thin. It omits revision semantics, overwrite behavior, error handling, and return information that an agent would need to call it confidently, even though the schema covers parameter 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 100%, so the baseline is 3. The description adds a useful example for the declarations parameter ("color: red; margin: 0"), which slightly clarifies format beyond the schema, but it does not elaborate on selector, file_id, or expected_rev.

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 (Set) and resource (one stylesheet rule in a CSS file), making the tool's purpose clear. However, it does not distinguish this from sibling tools like web_css or web_set_text, so it falls 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 gives no guidance about when to use this tool versus alternatives such as web_css or web_set_text, nor does it mention prerequisites or exclusions. Usage is only implied by the verb and resource.

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 meaningful behavior: scripts, foreignObject and event attributes are rejected, and external references are refused unless the '--allow-external' flag is used. This is real constraint disclosure an agent cannot infer, though it omits overwrite/create semantics for an existing path.

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 short sentences, front-loaded with the primary action, then constraints, then follow-up routing. No filler and each sentence carries distinct information.

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

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

No output schema and no annotations, so the description must stand alone; it covers the content safety rules and the follow-up tools. What it lacks is any statement of success/return behavior or whether authoring an existing path overwrites it, which matters for a 3-required-param mutation tool.

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

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

Schema description coverage is 100%, so all three parameters (svg, path, expected_rev) are already documented in the schema, including the stale-revision retry behavior. The description adds nothing parameter-specific, 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?

States a specific verb+resource: 'Author a pure SVG asset file.' The content restrictions (scripts, foreignObject, event attributes) sharpen what kind of file this produces, distinguishing it from generic write tools like web_set_text or web_css. It does not explicitly contrast with any sibling by name, keeping it at 4.

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 tells you what to do after authoring ('Reference it afterwards with web_insert_section or web_set_attr'), which gives useful sequencing context. It does not state when this tool should be chosen over sibling write tools (web_set_attr, web_css_set) or what conditions make it the wrong choice beyond the SVG-specific rejections.

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. It usefully discloses case-insensitivity and the search scope (all files in the current working copy), but says nothing about the shape of results, whether matches include file/line context, or how traversal behaves across large trees.

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 front-loaded sentence with zero waste; the operation and its most important behavioral modifier (case-insensitive) are stated 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?

For a simple two-parameter read tool with fully documented schema, the description is close to sufficient. The only material gap is the absence of any hint about what a match looks like, which matters slightly given there is no output schema.

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

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

Schema description coverage is 100%: both 'query' and 'limit' are documented in the schema, including the default of 40 matches. The description adds no parameter-level meaning beyond that, 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 names a specific verb ('Search') and resource ('text across all files in the current working copy'), so an agent knows exactly what operation this performs. It does not explicitly contrast itself with any sibling tool, but the siblings (web_read, web_css, web_pages) are functionally distinct enough that confusion is unlikely.

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: the agent can infer this is the tool for locating text, but there is no statement of when to prefer it over web_read or other read tools, and no mention of prerequisites or exclusions. Minimum-viable implied guidance rather than explicit routing.

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

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

With no annotations, the description carries the full behavioral burden, yet it only restates the insert action. It does not disclose that this is a destructive/mutating operation, that it requires an expected_rev (optimistic concurrency, stale revisions refuse), or what happens to sibling nodes at the insertion point. The concurrency behavior is only discoverable from the schema field description.

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

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

A single tight sentence with no filler, and the core action is front-loaded. It is efficient, though arguably too terse for a five-parameter mutating 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 schema is fully self-documenting (including the stale-revision rule in expected_rev) and there is no output schema to explain, so the agent can still call this correctly. However, for a five-required-parameter mutation with zero annotations, the one-sentence description leaves behavioral context thin.

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

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

Schema description coverage is 100%, so all five parameters are already documented, making 3 the baseline. The phrase 'relative to a parent node' loosely ties parent_id and position together, but adds no syntax or format detail beyond the schema.

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

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

States a specific verb and resource ('Insert a <section> fragment') and identifies the anchor ('relative to a parent node'). It is clear what the tool does, but it does nothing to distinguish itself from sibling mutators like web_move, web_set_text, or web_set_attr.

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 when-to-use guidance, no prerequisite note, and no routing to alternatives (e.g. when to insert a section vs. use web_move or web_set_text). The agent must infer applicability purely from the name and schema.

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 not state that this is a mutation, whether it is reversible, what happens to the node's existing children, or that expected_rev is a concurrency guard (that detail lives only in the schema). For a write tool with zero annotation coverage this is a significant gap.

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 front-loaded sentence with zero filler. Nothing is padded and the core action leads 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?

Five required parameters, a mutation operation, no annotations, and no output schema means the description should explain more: the interaction between position and parent_id, the destructive/irreversible nature of the move, and the stale-revision refusal behavior. As-is it is too thin for the tool's complexity.

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 every parameter (file_id, node_id, parent_id, position, expected_rev) is documented in the schema itself. The description only loosely frames parent_id/position as a move 'relative to another node' and adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb (Move) and resource (node) with the scoping constraint 'relative to another node in the same file'. That distinguishes it reasonably from siblings like web_remove or web_insert_section, though no sibling is named explicitly.

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

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

There is no guidance on when to use this over alternatives such as web_insert_section or web_remove, nor on prerequisites. The only hint is the phrase 'in the same file', which constrains scope but does not route the agent between 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?

With no annotations, the description carries the full behavioral burden. It does disclose two non-obvious traits: a hard cap of 20 nodes per page and that node offsets are revision-specific (so offsets cannot be reused across revisions). It omits read-only status and any auth or return-shape context.

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

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

Two short sentences, front-loaded with the page-limit constraint before the pagination mechanics. No wasted words, though the phrasing 'List revision and files' is compressed to the point of ambiguity.

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 paginated list with no annotations and no output schema, the pagination contract is covered, but the description never clarifies what a 'revision' is, what the returned nodes look like, or whether results are stable across calls. Adequate but with clear gaps.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that file_id plus node_offset selects 'remaining nodes' and that node offsets are revision-specific, which the schema's flat 'Node offset, default 0' does not convey.

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 listing operation over 'revision and files' and nodes, but the resource naming is muddy: the tool is 'web_pages' yet pages are never mentioned, and 'revision' is undefined. An agent can infer it enumerates files/nodes, but cannot cleanly distinguish it from siblings like web_timeline or web_read.

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 statement of when to use this tool versus alternatives, and no mention of prerequisites. It only tells you how to page, not when this tool is the right choice over web_read or web_find.

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 and does add real boundaries: it reads (returns) rather than mutates, it captures no screenshot, and it flags that pause/undo/restore/confirmed-export belong to the human dashboard, not this tool. It does not state permissions, idempotency, or freshness/caching behavior of the returned revision, keeping it below a 5.

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

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

Three short sentences, front-loaded with the return value in the first sentence. Each sentence earns some place, though the third sentence is primarily a disambiguation against the screenshot sibling rather than essential here.

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-param, no-output-schema tool, the description covers what is returned (a URL and a revision) and the notable scope boundary (no screenshot, dashboard-only controls). It does not explain what the returned URL is useful for or when the revision might change, which is a minor 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it does not add misleading parameter-like guidance.

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

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

States a specific verb and resource: returns the loopback live-preview URL plus the current revision. It distinguishes itself from web_screenshot_note by explicitly saying no screenshot is captured, but it does not differentiate from the other web_* siblings (web_pages, web_timeline, web_checkpoint), so it falls 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?

Usage is only implied: an agent would infer this is called when it needs the preview URL or revision. The clause about the human dashboard controlling pause, undo, restore and confirmed export hints at what this tool does NOT do, but no explicit when-to-use or when-to-prefer-an-alternative statement is given.

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

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

With no annotations provided, the description carries the full burden and does reasonably well: it discloses the truncation cap, that a revision and next offset are returned (pagination signal), and that opaque assets are unreadable. It stops short of describing permission requirements or what happens at end-of-file, but the core read behavior is transparent.

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 tight sentences with zero filler. The size cap and return shape come first, and the readability exclusion follows immediately, so the most decision-relevant 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?

No output schema exists, so the description wisely names what comes back (revision and next offset), covering the return-value gap. Combined with 100% schema coverage, an agent has enough to call it correctly; only edge behavior at the end of the file is unstated.

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

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

Schema description coverage is 100%, so file_id, start, and end are already documented as inclusive/exclusive offsets in the schema. The description's mention of 'next offset' adds a hint about pagination continuity but no syntax or format detail beyond what the schema already supplies; baseline 3 is appropriate.

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

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

States a specific verb (Read), resource (managed HTML/CSS/text file), and an explicit scope cap of 16,384 characters. Clear enough for an agent to distinguish this from write-oriented siblings like web_set_text, but it does not name or contrast with any specific sibling tool.

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

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

Usage is implied by the verb and the stated 'Opaque assets cannot be read' exclusion, which is a useful when-not condition. However, there is no guidance on when to prefer this over web_find or web_pages, nor any mention of prerequisites for obtaining a file_id beyond the schema's reference to web_pages.

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 and delivers very little. It does not say whether removal is reversible (relevant given the sibling web_checkpoint), whether a parent or sibling must exist, or what errors occur beyond the stale-revision note already in the schema.

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

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

A single front-loaded sentence with zero filler. It is efficient, though arguably under-sized for a mutation tool with no annotations to fall back on.

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 mutation with no annotations and no output schema, the description omits the things an agent most needs: reversibility/undo behavior, failure modes, and side effects on the working copy. The schema covers parameters but the description does not fill the behavioral 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 description coverage is 100%, including the important note that stale revisions are refused, so the schema already does the heavy lifting. The description adds no meaning about file_id, node_id, or expected_rev beyond what the schema states, which is the baseline-3 case.

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

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

States a specific verb and resource ('Remove one node') plus the scope ('from the working copy'), which separates it from read-side siblings like web_read and web_find. It never names an alternative such as web_move or web_insert_section, so sibling differentiation is left to the agent.

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 when-to-use guidance, no preconditions, and no mention of alternatives for the closely related web_move / web_insert_section operations. Usage is only inferable from the tool name.

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 usefully discloses that no screenshot is captured and what is returned, but omits whether the operation has side effects, requires authentication, or is purely read-only.

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 front-loaded sentences with no wasted words: the first states the return values, the second rules out screenshots and points to an alternative.

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 tool with no output schema and no annotations, the description adequately explains the return values and the key non-behavior. It could be slightly richer about what the working-copy revision represents, but is otherwise 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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it correctly adds no extraneous parameter detail.

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

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

The description states a specific output ('working-copy revision and file count') and explicitly disclaims the screenshot action implied by the name. This distinguishes it from visual tools, though the tool name remains somewhat misleading.

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 provides a clear when-not ('no screenshot is captured or inspected') and names an alternative ('use a separate visual tool for screenshots'). However, it does not state when an agent should choose this tool over unrelated siblings like web_pages or web_read, leaving implicit usage.

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 says 'working copy' but does not disclose mutation side effects, permission requirements, reversibility, or what happens to the file revision beyond what the schema already 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?

The description is a single short sentence with no wasted words. The action and scope are front-loaded, making it easy to parse quickly.

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 five-parameter mutation tool with no annotations and no output schema, the description is too sparse. It should at least clarify working-copy semantics, the revision-check behavior, or how this differs from other web editing tools in the set.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the input schema. The description adds only the notion of setting one attribute and does not contribute additional meaning beyond the schema's name/value/file_id/node_id/expected_rev 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 states a specific verb and resource: 'Set one HTML attribute in the working copy.' It is clear what the tool does, but it does not distinguish itself from close siblings like web_set_text or web_css_set, which also mutate content in the same working 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 description gives no explicit when-to-use or when-not-to-use guidance. It does not name alternatives or conditions for choosing this attribute-setting tool over related editing tools such as web_set_text.

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 mentions the expected_rev/retry pattern, but that same detail is already in the schema. It does not disclose that this overwrites existing text, whether permissions are required, or what a successful mutation returns. For an unannotated mutation tool, this is a significant omission.

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

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

Two short sentences, front-loaded with the operation and followed immediately by the one non-obvious calling constraint. 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?

Without annotations or an output schema, the description should carry more of the behavioral contract for a four-required-parameter mutation tool. It omits overwrite semantics, permission expectations, success/failure behavior, and sibling routing, leaving notable gaps.

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

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

Schema description coverage is 100%, so the schema already explains text, file_id, node_id, and expected_rev. The description repeats the expected_rev guidance but adds no syntax, format, or edge-case detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Set the text of one paired HTML node.' This distinguishes it reasonably from siblings like web_set_attr and web_css_set, though it does not explicitly name an alternative. The purpose is clear without opening the schema.

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

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

The phrase 'Pass expected_rev from your last read' implies a prerequisite workflow (read before write) but does not state when to use this tool versus web_set_attr or web_css_set, nor does it give explicit exclusions. Usage is therefore implied rather than 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?

No annotations are provided, so the description carries the full burden. It usefully discloses a session/auth constraint (undo/redo/restore need a dashboard session, implying this read does not) and reads as non-mutating, but says nothing about ordering, pagination behavior, or whether the read affects state.

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

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

Two short sentences, the core action front-loaded and the session caveat second. Every clause earns its place with 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?

No output schema exists, so the description needn't explain return values, and the one optional parameter is covered by the schema. For a simple read tool the description is nearly sufficient, though a hint about what a timeline entry represents would fully close the 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 description coverage is 100% and the single optional limit parameter is fully documented in the schema (default 50, max 100). The description adds no further parameter meaning, so the baseline 3 applies.

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

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

States a specific verb and resource: reading the working-copy timeline. It is distinguishable from the mutation siblings (web_set_text, web_remove, web_move) but does not explicitly contrast with the closest sibling, web_checkpoint.

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 note that undo, redo and restore require the dashboard session implies this tool is the read-only timeline access path and that those actions are out of scope here, but it never says when to reach for this vs web_checkpoint or how it relates to the editing tools.

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