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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds a genuinely useful behavioral detail beyond the annotations: sequence numbers are NOT reset, which tells the agent that this is a partial purge rather than a full state reset.

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 that carries the action, both scopes, and the key non-reset caveat. 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 one-parameter tool with full schema description coverage and annotations covering the destructive/idempotent profile, little more is required. The remaining omission is any statement about auth or capture-session preconditions, but nothing essential to correct invocation is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning: omitting targetId clears all renderers while supplying it targets one. This clarifies the otherwise opaque optional-parameter semantics beyond the schema's own note.

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

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

The description states a specific verb (clear) and resource (captured debug events), plus the scope (one renderer or all renderers). No sibling tool performs a similar clearing operation, so no explicit sibling differentiation is needed; the one gap is that it doesn't note the parent system being modified.

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 implies usage by explaining the two scopes (single renderer vs all renderers), but gives no explicit when-to-use guidance or prerequisites (e.g., whether a capture session must be active). The agent must infer the appropriate calling context.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the 'visible element' precondition, but does not say what happens on hidden/unmatched elements, timeouts, or whether the action triggers navigation - real behavioral gaps for a mutating click 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?

A single front-loaded sentence that leads with the action and mechanism, then the one disambiguation rule. No filler.

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

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

For a 5-parameter mutation tool with no output schema and thin schema coverage, the description leaves return/error behavior and several parameters unexplained. It is adequate to attempt a common call but not 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 coverage is only 20% (just targetId documented) across 5 parameters. The description explains index disambiguation semantics, which the bare schema does not, but ref, snapshotId, and how selector/ref interact remain undocumented in either place.

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 (click) plus resource (visible element) and the mechanism (Playwright/CDP), which cleanly separates it from siblings like type, press_key, and scroll. It does not, however, name any sibling or scope limits beyond visibility.

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

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

Gives one conditional hint - use index when the selector matches multiple elements - which is genuine usage guidance, but there is no when-to-use/when-not framing relative to alternatives such as type or press_key, and no prerequisites 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only the filter-by-sequence-number behavior, which is parameter-level rather than behavioral context; it does not disclose auth requirements, rate limits, or capture prerequisites.

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

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

A single front-loaded sentence with no filler, appropriately sized for a simple read tool. It could be slightly richer given the tool's four parameters, but every word earns its place.

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

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

With no output schema, four parameters at low description coverage, and no disclosure of capture prerequisites or level semantics, the description leaves an agent under-informed. It does not explain how logs are captured, what levels mean, or how afterSeq and limit interact.

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 25% – only targetId is documented. The description hints at afterSeq ('after a previous sequence number') but never names it, and gives no meaning for levels or limit, so it compensates only partially for the low schema coverage.

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

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

States a specific verb ('Read') and resource ('captured console events'), and notes optional filtering by a previous sequence number. However, it does not differentiate this tool from sibling tools like get_javascript_errors or get_network_requests, leaving the agent to infer 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 when-to-use guidance, no alternatives, and no prerequisites are provided. The description only describes what the tool returns, not when to choose it over sibling tools such as get_javascript_errors or get_network_requests.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The word 'bounded' adds a genuine behavioral note about output capping, but the description omits the default/max limits, how format selection affects the result, and the targetId focus requirement noted 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 well-formed sentence, front-loaded with the verb and resources, with no filler. It is appropriately terse, though the terseness is what causes the coverage gaps elsewhere.

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 six-parameter, zero-required tool with low schema coverage and no output schema, the description is far too thin. It does not explain how ref/selector/targetId/snapshotId interact or how the three formats differ in output, leaving the agent under-equipped to call it correctly.

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

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

Schema description coverage is only 17%, so the description carries the burden, yet it only implicitly maps to the format enum (html/text/accessibility). It says nothing about ref, selector (defaults to 'html'), maxChars, or snapshotId, leaving five of six parameters unexplained in both description and 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 gives a specific verb (read) and three concrete resources (bounded HTML, visible text, accessibility snapshot) plus the source (Typora), so the agent knows what it produces. It does not, however, differentiate itself from siblings like get_element, query_selector, typora_snapshot, or typora_get_document_source, leaving the selection decision ambiguous.

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 prerequisites, and no named alternatives, even though several siblings overlap heavily (get_element, query_selector, typora_snapshot). The agent must infer the use case entirely from the one-line purpose.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond the list of returned data: it doesn't explain how the element is identified, what happens with multiple windows or missing targets, or failure behavior. Given annotations carry the safety burden, this is thin.

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 and well-structured, though arguably too terse for an 8-parameter 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?

For an 8-parameter tool with 5 different ways to identify an element, 13% schema coverage, and no output schema, the description is significantly under-specified. It omits any guidance on the identification parameters or the include* toggles, which is the primary thing an agent needs to call it correctly.

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

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

Schema description coverage is only 13% (only targetId documented), so the description must compensate and does not. It never mentions ref, index, selector, snapshotId, or the include* flags, leaving an agent to guess how to select the element and what the includeStyles/includeListeners/includeAccessibility toggles control.

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 ('Inspect') and resource ('one element'), and enumerates the data classes returned (attributes, geometry, computed styles, accessibility, event listeners). This clearly separates it from bulk-DOM siblings like get_dom or typora_snapshot, though it never names an alternative 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 'one element' implies the single-target use case versus whole-document tools, but there is no explicit when-to-use, when-not-to-use, or named alternative (query_selector, get_dom). Usage is only inferable.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The word 'captured' hints that events must be captured beforehand, adding mild behavioral context, but nothing is said about ordering, pagination, or rate limits.

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

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

A single front-loaded sentence with zero filler. It is efficient, though arguably too terse for a tool with filtering and pagination parameters.

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

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

There is no output schema, so the description would need to explain return content, but it does not. Combined with undocumented limit/afterSeq pagination behavior and the 33% schema coverage, an agent lacks what it needs to call this correctly.

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

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

Schema coverage is only 33%: limit and afterSeq have no schema description and the tool description explains none of the three parameters. With coverage below 50%, the description is expected to compensate for the gaps, and 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?

Clear specific verb 'Read' plus a well-scoped resource ('captured uncaught errors and unhandled promise rejections'), which lets an agent distinguish it from get_console_logs and get_network_requests. It does not explicitly name those siblings, but the resource is precise enough to stand apart.

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 versus get_console_logs or other debug tools, no mention of prerequisites, and no note on exclusions. Usage is only implied by the resource 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?

Annotations already declare this a safe non-mutating read (readOnlyHint=true, openWorldHint=false), so the safety bar is largely met. The description adds one genuinely useful behavioral fact: response bodies are opt-in and bounded. It omits cursor/pagination behavior (afterSeq) and what happens when capture was never enabled.

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 compact sentence with no waste and the key opt-in/bounded constraint front-loaded. It is efficient, though its brevity is part of the reason the usage and parameter gaps exist.

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 six-parameter tool with 17% schema coverage, no output schema, and no annotation coverage of return shape, the description is thin. The capture-must-be-enabled prerequisite and the afterSeq cursor for paging through events are missing, leaving real gaps for correct invocation.

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

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

Schema description coverage is only 17% (only targetId is documented), so the description must compensate and mostly does not. Only includeBodies/maxBodyChars are hinted at via "opt-in and bounded"; limit, afterSeq, urlPattern, and non-focused-window targetId semantics are undocumented in both places.

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

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

"Read captured request, response, and failure events" names a specific verb and resource, and the three event kinds make it distinguishable from siblings like get_console_logs and get_javascript_errors. It does not, however, note that it only returns data when network capture has been turned on via typora_enable_debug_network_capture.

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 explicit when-to-use guidance, no named alternatives, and no exclusions. The critical prerequisite (capture must be enabled first, per the typora_enable_debug_network_capture / typora_disable_debug_network_capture siblings) is left entirely implicit.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds almost nothing beyond that: it does not say what keypresses can trigger (form submits, destructive shortcuts), whether an element must be focused first, or how targetId/window focus interacts. With annotations carrying the safety signal, the description contributes minimal behavioral context.

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

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

A single front-loaded sentence with no wasted words. It is arguably undersized for a 6-parameter destructive tool, but as written it is tight and readable.

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, 6-parameter tool with 17% schema coverage and no output schema, one sentence leaves key gaps: target selection semantics, key format, and focus/window requirements are all unaddressed.

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

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

Schema coverage is only 17% (just targetId documented) across 6 parameters, so the description must compensate and does not. It says nothing about key syntax/format, or what ref, index, selector, and snapshotId do, nor how they select the press target.

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 (press) and resource (Playwright key) with scope (selected element or active page), which distinguishes it from siblings like click and type. It is clear but does not explicitly name those siblings or contrast behavior with them.

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

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

No guidance on when to use this versus click, type, or send_cdp_command. No prerequisites, no exclusions, no alternatives named; the agent must infer usage 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context that results are 'concise, serializable summaries' rather than full nodes, but says nothing about pagination behavior or the targetId/focus requirement that the schema hints at.

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 wasted words, though its brevity comes partly from omitting usage and behavioral detail rather than from tight editing.

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

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

With no output schema, the description carries the burden of describing returns, and it only gestures at the shape ('concise, serializable summaries'). For a read-only query tool that is minimally adequate, but the return structure and result-limiting behavior remain underspecified.

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 67%, and the description only restates the CSS-selector concept already documented in the schema. It adds no meaning for limit (default 50, max 500) or the targetId focus requirement, so it neither compensates for the gap nor extends what is there.

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 (List) and resource (summaries for elements matching a CSS selector), and 'concise, serializable summaries' implicitly distinguishes it from raw-DOM siblings like get_dom and single-element get_element. It stops short of explicitly naming those alternatives, so an agent must infer the boundary.

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 when-to-use guidance, no prerequisites, and no named alternatives despite several overlapping siblings (get_dom, get_element, typora_snapshot). The selector-matching phrasing hints at the use case but leaves selection between tools to inference.

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

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

Annotations already declare destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds that scrolling can target either an element or the page, but does not explain the non-obvious readOnlyHint=false flag, what happens at scroll boundaries, or any timing considerations.

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 well-formed sentence with the action and scope front-loaded and zero filler. It is efficient, though arguably too terse given the parameter surface, but within the conciseness dimension it reads cleanly.

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 six-parameter tool with no output schema and near-zero schema descriptions, the agent lacks guidance on parameter interactions (ref/selector/targetId), which target is scrolled by default, and delta units. The description is not sufficient to call this tool correctly in ambiguous cases.

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 17% (just targetId), yet the description only loosely maps to the parameters via 'pixel delta' (deltaX/deltaY) and 'element or page'. It says nothing about ref vs selector vs targetId selection, snapshotId semantics, or defaults, leaving most of the 6 parameters undocumented.

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 (scroll), the resource (an element or the selected Typora page), and the mechanism (a pixel delta), which makes it clearly distinct from siblings like click, type, or press_key. It does not explicitly name a sibling it must not be confused with, but the purpose is unambiguous.

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

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

There is no when-to-use or when-not-to-use guidance and no alternative tool is named. The description only implies the obvious 'scroll to change the viewport', which an agent could infer 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?

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=false, so the agent knows this is a mutating, closed-world call. The description adds the backend-availability constraint, but says nothing about what an arbitrary command can alter, error behavior, or whether it is reversible — notable for a 'destructive' 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?

A single front-loaded sentence with no filler; the availability constraint is placed immediately after the action.

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 arbitrary-command escape hatch with no output schema and partial parameter documentation, the description covers the key gating condition but omits the return shape, failure modes, and method/params usage needed to call it 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 33%: 'method' and 'params' carry no descriptions, and the description adds nothing about their format or expected values. Only 'targetId' is documented in the schema (referencing typora_status), so the description fails to compensate for the coverage gap.

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

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

Names a specific verb and resource ('Send an arbitrary Chrome DevTools Protocol command') and frames the scope around the CDP-exposing backend, which distinguishes it from the DOM/selector-oriented siblings. It stops short of explicitly naming an alternative tool for the non-CDP case.

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

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

Provides a clear when/when-not: usable 'when the selected backend exposes CDP', not available in 'standalone mode'. This is real routing guidance, though it does not point at a fallback tool for standalone scenarios.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description usefully adds that the result is a PNG image, which matters because there is no output schema. However, it says nothing about where the image is written, whether it is returned inline, or how fullPage/selector interact.

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 capture target and output format come first. It is efficiently sized, though extremely terse given the tool's three parameters.

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

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

With no output schema and 33% parameter coverage, the description should say more about the returned artifact (inline data vs. file path) and the fullPage/selector precedence. It partially compensates by naming the PNG format, but an agent still lacks enough to invoke it confidently in all cases.

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 33%: targetId is documented in the schema but fullPage and selector are not. The description implicitly covers two of three parameters ('selected page' ≈ fullPage, 'one matching element' ≈ selector), which is marginal added value over the schema but does not compensate for the undocumented fullPage behavior.

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 (Capture) and resource (selected Typora page or one matching element) plus the output format (PNG), so the agent knows exactly what the tool produces. It does not differentiate itself from nearby siblings such as typora_snapshot or get_dom, which an agent might reasonably confuse for a visual capture.

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 typora_snapshot, get_dom, or get_element, nor any prerequisite noted (e.g. that targetId comes from typora_status). The phrase 'selected Typora page' is also undefined, leaving the agent to infer what 'selected' means.

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

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

Annotations already flag destructiveHint=true, so the agent knows this mutates state. The description adds no behavioral context: it does not mention that the default clear=true overwrites existing content, nor explain permissions, targeting requirements, or failure behavior.

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

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

A single front-loaded sentence with no filler. It is well-sized for a one-line tool, though its brevity reflects under-specification rather than efficient density.

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

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

For a 7-parameter mutation tool with 14% schema coverage and no output schema, the description is far too thin. It omits the targeting hierarchy, the destructive clear default, and any return/confirmation behavior an agent needs to call it correctly.

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

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

Schema coverage is only 14% (only targetId is documented) across 7 parameters, so the description must compensate but does not. It never explains ref, selector, index, snapshotId, or the significance of the clear default, leaving most parameters semantically opaque.

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 gives a specific verb and resource ('Enter text into a selected Typora element') and names the mechanism ('through Playwright/CDP'), which separates it from siblings like click or press_key. However, 'selected element' is left undefined, so the targeting model is not fully 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?

There is no statement of when to use this tool versus alternatives such as click, press_key, or the various targeting helpers. Nothing explains how to select/populate an element or when this is preferred over other input tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description's 'without changing Typora' is largely redundant with structured data. It adds only marginal context ('explicit standalone renderer bridge') and says nothing about what constitutes a detected vs. absent bridge, or whether the check touches the filesystem or network.

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 the action front-loaded and no filler. It is appropriately sized for a simple read-only inspection tool, though it is arguably too sparse to carry the required parameter and routing information.

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

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

For a read-only status check with no output schema, annotations cover the safety profile, so the bar is low. However, the undocumented executablePath parameter and the lack of any distinction from typora_status/typora_capabilities leave real gaps for an agent choosing between these diagnostics.

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

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

There is one parameter (executablePath) with 0% schema description coverage, and the description never mentions it, so the agent has no guidance on what this path should point to or whether it is optional. The description fails to compensate for the coverage gap.

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

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

States a specific verb (Inspect) and a specific resource (the explicit standalone renderer bridge installation), so the agent knows it reports on bridge install state rather than modifying it. It does not, however, differentiate itself from sibling typora_status or typora_capabilities, which plausibly report overlapping status information.

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 'without changing Typora' implies this is the diagnostic/inspection counterpart to typora_install_bridge and typora_uninstall_bridge, so usage is implied. There is no explicit statement of when to prefer this over typora_status, nor are any prerequisites or exclusions named.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe-read profile is covered. The description adds the nuance that only "explicitly supported" capabilities are returned, which is useful, but it says nothing about return format or scope of the read.

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

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

One compact sentence that front-loads the verb and resource, with no redundant padding. Efficient and well-structured.

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

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

For a low-complexity, single-parameter read tool with annotations covering its safety profile, the definition is largely sufficient. The only minor gap is that the return shape of "capabilities" is not described, but no output schema is expected for such a simple introspection call.

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

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

The single targetId parameter is fully documented in the schema (100% coverage), and the description only alludes to it via "selected Typora target." Baseline 3 is appropriate when the schema already carries the parameter semantics.

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

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

Clear verb ("Read") plus a specific resource ("the selected Typora target's explicitly supported debugging and automation capabilities"). An agent can tell this is a capability-introspection tool, though it does not contrast itself against siblings like typora_status or typora_bridge_status.

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 "before invoking an optional operation" gives an implied sequencing cue, but it never names which operations are "optional" or lists an alternative tool. Usage is suggested rather than explicit.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds real context beyond them: a normal close surfaces unsaved prompts, whereas force termination presumably bypasses them. That is exactly the consequence an agent needs to weigh before killing the app. It stops short of saying whether the call blocks on the prompt or whether unsaved data is lost outright.

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

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

One sentence, front-loaded with the default behavior and the exception after the semicolon. No filler, no redundancy, and the destructive branch is clearly gated.

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-required-parameter lifecycle tool with no output schema, the description covers the key decision (safe close vs. kill). It could add what happens on success or if Typora isn't running, but nothing essential to correct invocation is missing.

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

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

Schema description coverage is 0% for the single boolean 'force', so the description carries the burden. It does explain that force drives force termination, but the phrasing ('force termination only when force is true') is close to circular and doesn't clarify the default (false = normal close) or the data-loss consequence.

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 ('Close Typora') and splits the behavior into two modes (normal close vs. force termination), so the agent knows exactly what the call does. It does not explicitly position itself against the adjacent sibling typora_restart, which also terminates the app, so it falls just short of full sibling differentiation.

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 clause 'force termination only when force is true' functions as conditional guidance for the force case and implies normal close is the default path. However, there is no explicit when-to-use-this-vs-typora_restart or typora_launch guidance, and no statement of prerequisites, so usage 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?

Annotations declare non-read-only, idempotent, and destructive, and the description adds meaningful context beyond them by specifying exactly what is being undone (the target's original fetch/XHR functions are restored). It does not mention side effects on already-captured data or errors if capture was never enabled, but the core behavioral disclosure is solid.

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

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

One tight sentence that front-loads the action and follows with the scoping condition. No wasted words.

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

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

For a simple toggle-style tool with a fully documented parameter and annotations covering safety and idempotency, the description is sufficient. No output schema exists, so return values need not be explained, though a note about what happens when capture was not active would complete it.

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 targetId parameter is fully documented in the schema (including its source and fallback condition). The description adds no additional parameter guidance, 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 action (restore original fetch/XHR functions) and ties it to the debug network capture context, which distinguishes it from the enable counterpart. It is slightly indirect because the name says 'disable' while the description says 'restore', but the intent is unambiguous.

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

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

The phrase 'after explicit debug network capture' gives a clear condition for when to use it, implicitly pointing at typora_enable_debug_network_capture as the prerequisite/alternative. It does not spell out exclusions or edge cases, but the trigger context is clear.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: capture is temporary and limited to fetch/XHR, explicitly excluding IPC, WebSocket, and other internal channels. It omits how long 'temporary' lasts and how capture ends, but adds real value beyond the annotations.

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

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

Two tight sentences with the capability front-loaded and the scope limitation second. Every clause earns its place; nothing is redundant or padded.

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

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

With no output schema and a rich annotation set, the description is nearly complete: it states the action, scope, and exclusions. Remaining gaps are the lifecycle of 'temporary' capture and how it interacts with the disable sibling, but an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100% and the single targetId parameter is fully documented there, so the schema carries the burden. The description's phrase 'for one standalone target' loosely echoes the targetId semantics but adds no syntax, default, or behavior beyond the schema. 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+resource (enable debug network capture) and narrows scope to fetch/XHR on one standalone target. It implicitly contrasts with its sibling typora_disable_debug_network_capture via the verb, but never names alternatives or the downstream get_network_requests, so it stops short of full sibling differentiation.

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 word 'explicitly' and 'temporary' imply this is a deliberate pre-step for capturing traffic, and the exclusion sentence tells the agent what it will not capture. However there is no explicit when-to-use instruction, no mention of when to disable, and no routing to get_network_requests as the consumer.

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

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

Annotations already declare readOnlyHint=true, so 'without modifying it' is partly redundant; however the description adds real value by specifying that this returns the *saved* source from the bridge (disk state) rather than live renderer state, and by explaining the purpose of sourceHash.

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 that packs the action, the constraint, and the verification purpose with minimal waste. Slightly dense but no filler.

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

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

With no output schema, the description should describe the return shape, but only vaguely alludes to sourceHash. The 1,000,000-char maxChars truncation behavior and the focused-window default for targetId are left unaddressed, leaving gaps for a two-parameter read tool.

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

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

Schema coverage is only 50%: targetId is documented in the schema, but maxChars is undocumented in both schema and description. The description mentions sourceHash (a return artifact, not a parameter) and says nothing about truncation semantics of maxChars or the focused-window fallback for targetId, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource (read the current saved Markdown source) and names the mechanism (standalone bridge) plus a distinguishing artifact (sourceHash). It implicitly separates itself from siblings like get_dom or typora_snapshot that expose rendered/view state, though it never names an alternative 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?

It hints at the use case (prove renderer-side code did not rewrite the file via sourceHash), which implies when you'd want it, but gives no explicit when-to-use vs when-not, no prerequisites, and never names a sibling alternative such as get_dom.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds real value beyond them by disclosing that a backup of window.html is taken first and that a Typora restart is required for the change to take effect. It does not explain what exactly is overwritten or how to recover beyond the backup.

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 tightly written sentences with the primary action front-loaded and the follow-up requirement second. No filler and every clause carries information.

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

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

For an idempotent-but-destructive install operation with no output schema, the description covers the safety net (backup) and the restart requirement, which is decent. It omits parameter purpose and any guidance on when installation is needed versus checking typora_bridge_status first.

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 67%, below the high-coverage threshold, so the description should compensate, and it does not mention token, registryDir, or executablePath at all. 'executablePath' has no schema description either, leaving it fully undocumented.

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 ('install') and resource ('standalone local renderer bridge') plus an additional concrete action (back up window.html). The pairing with the sibling typora_uninstall_bridge is inferable but never named, so it stops short of explicit sibling differentiation.

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

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

Provides a post-install directive ('Restart Typora afterward to load it'), which is useful operational guidance, but gives no when-to-use rationale, no prerequisites, and no explicit comparison to typora_uninstall_bridge or typora_bridge_status. Usage is implied rather than 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?

The annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety/idempotency profile is covered. The description adds genuine behavioral context beyond that – enabling CDP and blocking until a renderer is ready – but omits what happens if an instance is already running and how restartIfNeeded interacts with that.

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

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

A single sentence that is front-loaded and free of filler, with the primary action stated first and the readiness wait appended. It is appropriately sized for the core action it conveys.

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

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

For a 6-parameter launch tool with no output schema, the definition is too thin: it does not document parameters, describe failure/edge cases (already-running instance, launch failure), or route the agent away from typora_restart. The core action is covered but the surrounding context an agent needs is missing.

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

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

Schema description coverage is only 17% (just userDataDir documented), so the description must compensate for the five undocumented parameters. It adds no parameter-level meaning at all – 'CDP enabled' only loosely implies debugPort – leaving most fields unexplained in both schema and 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 states a specific verb and resource ('Find and launch Typora with CDP enabled') plus an operational detail ('wait until a renderer is ready'), so an agent knows what it does. However, it does not differentiate from the close sibling typora_restart, leaving the choice ambiguous without opening schemas.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives. An agent cannot tell from the text whether to call this versus typora_restart or typora_status.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description usefully adds the synchronous behavior ('wait until Typora confirms its path'), but it never discloses what the destructive effect is—e.g. that opening a document replaces the currently loaded document.

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 the core action front-loaded and no wasted words. The trailing fixture sentence is slightly ambiguous but does carry routing information.

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

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

For a destructive, no-output-schema operation, the description omits key context: what happens to the currently open document, whether permissions or a running Typora instance are required, and how 'selected renderer' is determined. Annotations cover the safety hint but not the behavioral detail an agent needs.

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%: targetId is documented in the schema (referencing typora_status), but the required path parameter has no description. The phrase 'selected renderer' loosely gestures at the renderer/targetId concept but adds no concrete guidance, so the description does not compensate for the gap.

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

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

States a specific verb (Open) and resource (existing Markdown document) plus scope (in the selected renderer), so the agent knows exactly what happens. It does not, however, explicitly distinguish itself from siblings like typora_launch or typora_run_fixture, leaving that routing to inference.

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 explicit when-to-use statement. The second sentence, 'Fixture validation uses a stricter MCP-owned launch flow,' is an indirect 'when not to use this' hint pointing at the fixture path, but no alternatives are named directly, so usage 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?

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact beyond that: standalone mode refuses location.reload, which is a failure mode not expressible in annotations. However, it never says what 'destructive' means here (e.g. unsaved editor state being discarded), leaving the biggest behavioral question unanswered.

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 action and its precondition come first, the alternative and failure mode second. Every clause carries decision-relevant information.

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

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

For a 2-parameter, no-output-schema mutation tool the description covers the routing decision well, but it omits the ignoreCache parameter entirely and never states the user-visible consequence of a reload (lost unsaved content), which matters given destructiveHint=true. 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 only 50%: targetId is documented in the schema, but ignoreCache has no description anywhere. The tool description mentions neither parameter, so it does nothing to compensate for the coverage gap or explain what targetId selection means in practice.

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 ('Reload the selected Typora renderer') and clearly separates itself from typora_restart by naming the latter for MCP-managed instances. The purpose is unambiguous, though 'selected renderer' relies on the reader knowing how selection works (typora_status/targetId).

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

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

Gives an explicit precondition ('when the selected backend supports safe renderer reload'), an explicit failure case ('Standalone mode refuses location.reload'), and routes the agent to the correct alternative ('use typora_restart for MCP-managed instances'). This is exactly the when/when-not/alternative guidance an agent needs to pick between reload and restart.

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

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

Annotations declare destructiveHint=true and idempotentHint=true, so the safety profile is partly covered. The description adds genuinely new context beyond them: the restart is bounded to MCP-launched instances and will not touch externally launched instances that may hold unsaved work. It stops short of stating that unsaved changes in the MCP-launched instance itself may be lost, which the destructive hint implies.

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

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

Two sentences, zero waste, with the scope constraint front-loaded in the first sentence and the safety guarantee second. Nothing extra to trim.

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 action tool with no output schema, the description covers what the agent needs to decide and invoke correctly. The main residual gap is what happens to unsaved work in the MCP-launched instance being restarted, and what the 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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter semantics are missing.

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 (restart) and resource (Typora instance) plus an explicit scope boundary: only instances launched by this MCP server. This distinguishes it implicitly from typora_launch/typora_close, though it doesn't explicitly contrast with those siblings.

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

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

The scope condition ('only a Typora instance launched by this MCP server') tells the agent when this tool is applicable and when it is not, which is the key selection criterion. It stops short of naming a specific alternative tool for the excluded case, so it isn't a full 5.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds meaningful behavioral context beyond them: it writes separate evidence, requires explicit opt-in for shared targets, and guarantees shared targets are never closed or restarted. This reassures about blast radius in a way the annotations alone do 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?

Two compact sentences with no filler; the core action is front-loaded and the constraint about shared targets follows. Appropriately sized for a three-parameter 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?

For a destructive, non-read-only tool with no output schema, the description covers safety-relevant behavior (opt-in, no close/restart) but does not explain what a fixture is, what 'separate evidence' consists of, or how failures surface. Adequate but with clear gaps an agent would want filled given the tool's destructive nature.

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 33% (only targetId is documented). The description indirectly illuminates allowSharedTarget via 'explicit opt-in' and shared targets, and alludes to the fixture root for fixturePath, but does not document the fixture JSON format, syntax, or the evidence location. It partially compensates but leaves gaps.

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 ('Run') and resource ('a declarative JSON fixture from the configured fixture root'), plus a side effect ('write separate evidence'). It is distinguishable from siblings like typora_snapshot or typora_launch, though it never explicitly contrasts itself with those alternatives.

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

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

Provides one conditional rule (shared targets require explicit opt-in), but does not state when to choose this tool over siblings such as typora_open_document, typora_snapshot, or typora_status. Usage is implied by the fixture concept rather than spelled out.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine context beyond that: the snapshot is 'bounded' and carries a 'short-lived' snapshotRef, which signals lifecycle/expiry behavior an agent needs to know.

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 the key intent and the HTML-alternative front-loaded. No padding, though one clause about the snapshotRef/revision lifecycle is slightly compressed.

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

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

With no output schema, six sparsely-documented parameters, and 17% schema coverage, the description carries the burden but leaves large gaps: how snapshotRef/revision are consumed, what the snapshot contains, and what the parameters bound are all unexplained.

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 17% (only targetId is documented), yet the description explains none of the five undocumented parameters (limit, maxNodes, selector, rootSelector, maxTextChars). The vague word 'bounded' gestures at limits without clarifying any parameter.

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

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

States a specific verb ('Create') and resource ('bounded structured renderer snapshot') and names the outputs (snapshotRef, revision). This clearly differentiates the tool from returning raw HTML, though it does not distinguish it from nearby siblings like get_dom or query_selector.

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?

'Prefer this over returning complete HTML' gives an implied preference but frames the choice against an abstract technique rather than a named sibling tool. No when-to-use context for selecting this over get_dom/query_selector is provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds value by spelling out exactly what facets the inspection covers, which effectively substitutes for the absent output schema. It still omits practical traits such as whether it spawns/contacts the bridge, latency, or error behavior when Typora is not running.

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

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

One front-loaded sentence with a verb-first construction and a compact comma-delimited list of inspected facets. No filler, no repetition of the tool name.

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 parameters, no output schema, and annotations covering the safety profile, the definition is nearly complete for a zero-argument diagnostic: the enumeration of inspected facets tells the agent what it will learn. A brief note on the relationship to typora_bridge_status (or behavior when Typora is not running) would close the remaining 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 per the baseline there is nothing for the description to disambiguate. No parameter semantics are needed and none are omitted.

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 (inspect) and enumerates concrete resources: Typora processes, CDP connectivity, renderer windows, current file, and latest debug event sequence. This is far more specific than a tautology, but it never distinguishes itself from the similar sibling typora_bridge_status, leaving the agent to infer which status tool to pick.

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 enumerated contents imply a diagnostic/preflight use case, but there is no explicit when-to-use guidance, no mention of typora_bridge_status as the alternative, and no statement of when not to call it. Usage is inferable rather than 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?

Annotations already declare destructiveHint, idempotentHint, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely useful context the annotations cannot: the removal is scoped (leaves everything else alone) and the first pre-install backup is retained, informing recoverability.

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 scope constraint and the retention guarantee; no filler.

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

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

For a destructive removal tool, the description covers impact scope and backup retention well; the only gap is the undocumented executablePath parameter, which matters since it is not required and not described anywhere.

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

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

There is one parameter (executablePath) with 0% schema description coverage, and the description never mentions it, so an agent gets no indication of what value it takes or whether it is required (the schema marks 0 required).

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 (Remove) and a precisely scoped resource: only the bridge injection and its bridge script. It implicitly contrasts with typora_install_bridge and with a full uninstall, though it does not name the sibling explicitly.

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

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

Usage is only implied by the scope wording ('Remove only the ... bridge injection'); there is no explicit statement of when to use this versus typora_install_bridge or a full uninstall, and no prerequisites are given.

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