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

With no annotations, the description carries the full burden and does meaningful work: it discloses the two result states ('still_failing', 'not_seen') and the important side effect that a 'not_seen' result mutates .agentsensor/status.json by moving the error from 'open' to 'resolved'. It omits whether the check is instantaneous or waits/samples the dev server, which matters for a recurrence check.

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 front-loaded with the imperative call condition, then the verification purpose, then the outcome enumeration. No filler and every clause earns its place.

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

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

There is no output schema, and the description correctly compensates by naming both return states and the underlying status.json mutation. It remains slightly incomplete about timing (does the check wait for the fix to take effect?) and the absence of an error, but an agent has enough to call it correctly.

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

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

Schema description coverage is 100%, so all three parameters (error_id, since, project) are already documented in the schema, including the 'since' fallback behavior. The description adds no parameter-level meaning beyond that, 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: verifying whether an error_id recurred after a code fix. It also names its trigger condition and the two possible outcomes, letting an agent distinguish it from resolve_error (manual resolution) and get_error_detail (inspection only) without opening any schema.

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

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

Explicitly prescribes when to call it ("ALWAYS call this after applying a code fix for an error_id"), which is strong sequencing guidance. It does not, however, clarify when to use it instead of the sibling resolve_error, which appears to have overlapping resolution semantics.

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 does well: it discloses the return shape (source-mapped stack trace, highlighted user frames, collapsed node_modules, preceding log lines, originating command/URL), implying a read-only inspection. It omits failure modes such as an unknown or expired error_id, which keeps it short of a 5.

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

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

Two sentences, zero waste: the first front-loads the calling trigger, the second enumerates exactly what comes back. 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?

With no output schema, the description must describe the return value and does so in useful detail. It is nearly complete for a two-parameter read tool, with only error/edge-case behavior left 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 coverage is 100% and both parameters are documented in the schema, including that error_id comes from get_runtime_errors, so the baseline is 3. The description reiterates the error_id source but adds no format, syntax, or project-path guidance 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 ('inspect an error_id', returns the source-mapped stack trace) and clearly distinguishes itself from get_runtime_errors (it is the follow-up drill-down) and resolve_error. An agent can tell what this tool does 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?

Explicitly says to call it immediately after get_runtime_errors, which pins down the trigger condition and the predecessor tool. It does not, however, contrast with resolve_error or say when not to use it, so it falls short of full when/when-not guidance.

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

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

With no annotations, the description carries the full behavioral burden, and it does most of that work: it discloses that only active OPEN errors are returned by default, the session/24h time window, the source coverage, and the grouping/location format. It stops short of explicitly declaring the operation is a safe read (no mutation) and says nothing about pagination or rate 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?

Two sentences, zero filler, and the imperative call-to-action is front-loaded before the return-value detail. The capitalized ALWAYS is slightly loud but functionally effective for routing.

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, all-optional, no-annotation tool with no output schema, the description supplies the essential context: trigger conditions, scope, time window, and return grouping. It is nearly complete, missing only an explicit statement that it is a non-mutating read and any note on how limit interacts with grouping.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description genuinely adds meaning by mapping its wording onto parameters: 'active OPEN' implies include_resolved defaults false, and 'current dev session (or last 24h)' clarifies the all_sessions/since_minutes behavior. That is real added semantics rather than restatement.

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 precise verb+resource and goes well beyond a label: it enumerates the error sources covered (runtime, bundler Vite/Next.js/Storybook, TypeScript, browser), the time window (current dev session or last 24h), and the return shape (grouped by signature with file:line). The 'ALWAYS CALL THIS TOOL FIRST' clause also positions it relative to the sibling set (resolve_error, check_fix, get_error_detail) as the entry point.

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

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

It gives an explicit and aggressive trigger list ('error, bug, crash, broken component/page, or asks you to fix/debug anything') and states ordering ('call this first'). What it lacks is any when-not condition or a named alternative for the follow-up case, so an agent must infer that the siblings are used after this call.

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 the state file it mutates and the non-obvious behavior that a recurring error auto-reopens, but omits permissions, behavior when the error_id is unknown, and any confirmation/return semantics.

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 filler, and the core mutation is front-loaded with the auto-reopen caveat following 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 mutation with no output schema, the description covers the action, its target state, and the important reversibility nuance. Only edge cases (unknown error_id, the 'project' parameter) are left 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 description coverage is 100%, so both parameters are already documented, including the omit-all behavior. The description restates that behavior without adding format or constraint detail, matching the baseline for high-coverage schemas.

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 ('marks ... as resolved') and resource ('error_id'), plus where the change lands ('.agentsensor/status.json'). It clearly isn't a read tool like the get_* siblings, though it doesn't name the alternatives 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 description implies when to use it (after fixing an error) and clarifies the omit-to-resolve-all case, but gives no explicit when-not guidance or comparison to check_fix, which an agent might reasonably confuse this with.

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