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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint, so the safety profile is covered; the description reinforces it with 'Read-only; no files are written or modified.' It adds real behavioral value by explaining the delta semantics (edit-introduced vs. edit-resolved diagnostics against a baseline), which the annotations do not convey.

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

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

Three sentences, purpose front-loaded, no filler. The 'no files are written or modified' clause is mildly redundant with the readOnlyHint annotation but is short and harmless.

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?

An output schema exists, so return values need no explanation. For a two-parameter, read-only verification tool the description covers purpose, timing, and delta behavior adequately; only deeper parameter semantics are 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 0%, so the description must carry parameter meaning. It names both parameters conceptually ('specified edited files', 'optional baselineCheckId') and correctly signals baselineCheckId is optional, but gives no format, path semantics, or the 512-item limit, leaving the undocumented schema to do the rest.

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+scope: 'Runs incremental diagnostics on specified edited files and computes a verification delta against an optional baselineCheckId.' The 'incremental on edited files' framing distinguishes it from broader siblings like check_project and get_live_diagnostics, though no sibling is named explicitly.

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

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

Explicitly states when to use it: 'Use this after modifying files to verify whether edits introduced or resolved diagnostics relative to the baseline check.' Clear timing context, but it names no alternative tool nor any exclusion conditions.

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?

Goes well beyond the annotations (destructiveHint, idempotentHint=false) by disclosing the write mechanism (adjacent temp-file replacement), a pre-write drift check, in-process best-effort rollback, and an explicit limitation that there is no persistent crash recovery. That tells an agent exactly what can be lost and when.

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?

Four sentences, front-loaded with the mutation mechanism before the constraints and caveat. Dense but each sentence contributes; no filler or repetition of the schema.

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?

An output schema exists so return values need no explanation, and the description covers mechanism, atomicity limits, confirmation requirement, and baseline validation for this destructive multi-file write. The main gap is the unexplained transactionId and the absent preview-first routing.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains confirm (must be true) and baselineCheckId (must be valid/active, else abort with no file modification), but transactionId — a required parameter — is never characterized, leaving one of three params unexplained.

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 ('Applies diagnostic modifications') and characterizes the operation mechanism. It reads clearly against siblings like preview_diagnostic_fix and discard_diagnostic_fix, though it never explicitly names the apply-vs-preview distinction, leaving the sibling differentiation implicit.

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

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

Gives a hard precondition ('Requires explicit confirm: true') and a bail-out rule for invalid baselines, which is real usage context. However, it never states when to pick this tool over preview_diagnostic_fix or after_edit_check, leaving the alternative choice 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?

Goes well beyond annotations (readOnlyHint, idempotentHint) by explaining the content-hash caching mechanism, when files are re-checked vs skipped, that config file changes trigger re-checks, that TypeScript is a whole-program engine requiring re-runs, and that absolute/out-of-root paths produce errors.

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?

Front-loaded with core purpose and sibling differentiation, then caching details. Every sentence carries useful information, though the caching explanation is detailed enough to border on verbose for the general case.

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

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

Given the single complex, cache-aware parameter and rich engine behavior, the description covers usage, alternative routing, path constraints, caching semantics, and engine differences. An output schema exists, so return format need not be explained.

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

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

Schema description coverage is 0% and there is no description of the parameter within the schema. The description fully compensates: it explains the files parameter expects relative paths (not globs), rejects absolute/out-of-root paths with an error, and implicitly scopes the list to project files.

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 (runs lint and type diagnostics) on a specific resource (a list of files), names the engines (Oxlint, TypeScript, Biome), and explicitly distinguishes from the sibling check_project for full scans.

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 states when to use this tool ('incremental checks after editing specific files') versus the alternative ('use check_project for a full project scan'). The guidance is direct and actionable.

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, idempotentHint, non-destructive, and closed-world behavior, and the description reinforces read-only operation while adding useful context: no caching, re-running all enabled engines each call, optional Biome, clustering, and path-validation error responses. It does not discuss runtime cost or result shape beyond what the output schema likely covers.

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

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

The description is front-loaded with the core action and engine details, then covers behavior, parameter constraints, and the sibling alternative. Every sentence contributes directly to correct invocation or tool selection.

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

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

For a one-parameter tool with annotations covering safety and an output schema covering return values, the description supplies everything an agent needs: engine scope, read-only behavior, path rules, caching behavior, and the alternative for incremental checks.

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?

With 0% schema description coverage and one optional parameter, the description fully compensates: it explains that paths default to the project root when omitted, must be relative and within the project directory, and that absolute or out-of-root paths return an error. This adds substantial semantics beyond the bare array schema.

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

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

The description states a specific verb and resource: it runs and clusters Oxlint, TypeScript, and optionally Biome lint/type diagnostics across project paths. It also explicitly distinguishes itself from the sibling check_files tool, so an agent can select it without opening either 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?

It gives clear when-to-use guidance: 'Use this for a full project scan; use check_files instead for faster incremental checks after editing specific files.' It also states the default path behavior and the error condition for absolute or out-of-root paths.

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, idempotentHint and destructiveHint=false, so 'Read-only; no files are modified' is partly redundant. The description still adds value beyond the structured data with 'deterministic' and 'resilient to line shifts', which are meaningful behavioral traits an agent cannot read off 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, front-loaded with the verb and resource, with no filler. The 'Read-only; no files are modified' clause duplicates the annotation and is the only marginally wasteful element.

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?

An output schema exists, so return shape need not be explained, and the description still usefully previews the delta categories (introduced, resolved, unchanged, net delta). For a two-input comparison tool this is nearly complete; only the routing context is thin.

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

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

Schema coverage is 0%, so the description carries the full parameter burden. It does name both parameters and implies their roles (baselineCheckId = baseline, currentCheckId = current), which is helpful, but adds no format, validity, or ordering semantics beyond what the parameter names already suggest.

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 ('Computes') and resource ('a deterministic diagnostic delta between two checks'), which clearly separates it from read-oriented siblings like get_diagnostic_snapshot and get_live_diagnostics. It does not explicitly name or contrast against a sibling, so it stops short of a 5.

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

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

Usage is implied by the two-check framing (compare a baseline against a current run), but there is no explicit when-to-use, when-not-to-use, or alternative routing guidance. An agent can infer the context but is not steered away from overlapping 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=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description usefully clarifies that the object is an ephemeral in-memory preview held in server storage, so discarding it is not a data-loss operation — consistent with destructiveHint=false. It does not state what happens on an expired or unknown transactionId.

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 verb and resource come first and the scoping parameter follows. Efficient, though it stops short of adding the usage detail it could have carried in the same space.

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?

An output schema exists, so return values need no explanation, and the tool is simple with one required parameter. Still missing is any statement of the precondition (a live preview transaction from preview_diagnostic_fix) or behavior on an invalid/expired id.

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?

One parameter with 0% schema description coverage, so the schema contributes nothing about transactionId. The description names it and ties it to the preview ('in-memory diagnostic fix preview by transactionId'), but gives no format, origin (presumably preview_diagnostic_fix), or validity 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?

States a specific verb (discards) and resource (in-memory diagnostic fix preview), scoped by transactionId. It is distinguishable from preview_diagnostic_fix and apply_diagnostic_fix by naming convention, but the description never explicitly contrasts itself 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?

It never says when to call this versus preview_diagnostic_fix or apply_diagnostic_fix, nor that it is the cleanup step after a preview. Usage is only inferable from the tool name and the phrase 'in-memory ... preview'.

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, idempotentHint, and destructiveHint=false, so 'Read-only; no files are modified' largely restates structured data. The genuinely additive detail is 'immutable' — the snapshot cannot change after recording — which is useful context versus a live query, but return contents are covered by the output schema and permission requirements are not mentioned.

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

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

Three short sentences, front-loaded with the core action and scope. The 'Read-only; no files are modified' clause duplicates the annotations and the return-value list partly duplicates the output schema, but the overall size is appropriate and nothing is buried.

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 read tool with a rich annotation set and an output schema, the description covers purpose, scope, immutability, and return shape adequately. The missing piece is routing guidance against the many sibling diagnostic tools, but the essential call information is present.

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?

With a single required parameter and 0% schema description coverage, the description does identify the key as a specific check run's id, giving the parameter some meaning. However it adds no syntax, format, or example, so an agent still learns nothing about what a valid checkId looks like.

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 ('Retrieves the immutable diagnostic snapshot') scoped to a 'specific checkId'. The word 'recorded' plus 'checkId' distinguishes it from siblings like get_live_diagnostics and compare_diagnostics without needing their 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 explicit when-to-use or when-not guidance, and the obvious alternatives (get_live_diagnostics for current state, compare_diagnostics for cross-run comparison) are never named. The only hint is that a snapshot must already be 'recorded' for a checkId, which 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?

Annotations already declare read-only, idempotent and non-destructive, so the safety profile is covered. Beyond that, the description discloses a genuinely non-obvious behavior: an unknown/expired checkId or missing issue/cluster yields a status: "stale" response rather than an error, and supplying both or neither ID returns an argument error. These are behaviors not derivable from the annotations or 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?

Four compact sentences, front-loaded with purpose, then constraints, then error behavior; nothing is buried. The second sentence ('Read-only; no files are written or modified') largely restates the readOnlyHint annotation, which is the one mildly redundant element.

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 an output schema present, return-value documentation is unnecessary, and the description still adds the critical edge cases: mutual-exclusion enforcement and the stale-status-instead-of-error path. For a 3-parameter read tool with full annotations, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description has to carry the load, and it explains the key semantic: checkId is required and the clusterId/issueId pair is a mutual-exclusion choice whose violation is an argument error. It does not state expected value formats (e.g., ID shape) or what an ID literally is, so the compensation is solid but not exhaustive.

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 ('Returns the full issue list') plus the scoping key ('for either one cluster ID or one issue ID for a specific checkId'), so an agent knows exactly what it retrieves. The subject matter is distinct from diagnostic-snapshot siblings, though it never explicitly contrasts itself 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?

It states the invocation constraint (checkId required, exactly one of clusterId/issueId) and the error outcome of violating it, which is useful routing information. However, it never says when to reach for clusterId vs issueId or when to prefer a sibling tool such as get_diagnostic_snapshot or get_live_diagnostics, 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 readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds useful context beyond that: results are 'bounded' (implying limits) and merged from both internal engines and ingested LSP sources with per-issue provenance. It does not mention rate limits or pagination behavior, so a 3 is appropriate.

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 verb and resource. Every clause carries information (scope, sources, provenance), though the sentence is slightly jargon-heavy for its length.

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?

An output schema exists, so return-value detail is not required, and the description covers provenance and source merging. However, with 0% parameter coverage and no usage routing across a crowded sibling set, the definition is incomplete for correct invocation.

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

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

Schema description coverage is 0% for two parameters, so the description must carry the burden and does not. Neither the 'files' filter (limit 512) nor the 'severity' enum (error/warning) is mentioned or explained, leaving both parameters undocumented in any natural-language form.

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

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

States a clear verb (Returns) and resource (active diagnostics and clusters), and specifies scope ('current bounded active') plus data sources ('internal engines and ingested LSP sources'). However, it does not differentiate from close siblings like get_diagnostic_snapshot or get_issue_detail, forcing the agent to infer the distinction.

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 never says when to use this tool versus alternatives. Given siblings such as get_diagnostic_snapshot, compare_diagnostics, and get_issue_detail, an explicit routing statement is exactly what is missing, and none 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?

Although annotations already declare readOnly, idempotent, and non-destructive behavior, the description adds state-lifecycle context: loop history accumulates across all check_project and check_files calls and is restored from .signalint/session.jsonl on startup. It also confirms 'no files are written or modified,' which clarifies what the read-only hint actually guarantees.

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

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

The description is tight and efficient: it opens with the return value and risk guarantee, then gives state lifecycle, parameter count, and usage routing. Every sentence adds useful signal and no filler is present.

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

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

Given that the tool has no parameters, has an output schema, and conveys read-only behavior through annotations, the description is complete. It also clarifies how data is aggregated across sibling calls, how it is restored from session storage, and when to choose alternative tools.

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

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

The tool has 0 parameters, so the baseline is 4. The description explicitly says 'Takes no parameters' and the schema confirms an empty object with no additional properties. There is nothing further needed.

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: 'Returns all diagnostic issue signatures currently flagged as looping' and defines looping as repeatedly appearing and disappearing. It also distinguishes the tool from siblings like check_project and check_files by positioning it as the accumulated-history view rather than a fresh diagnostic runner.

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

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

It explicitly tells agents when to use it: 'identify which diagnostics an agent is oscillating on.' It also names the alternatives for fresh diagnostics: 'use check_project or check_files to run fresh diagnostics.' This is clear, direct usage guidance.

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

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

Annotations declare readOnlyHint=true (the tool does not modify its environment), but the description says it 'updates the active diagnostic buffer, and records an immutable snapshot' — i.e., it mutates server state and persists a new record. This directly contradicts the read-only annotation, so an agent trusting the hint would underestimate the tool's side effects.

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

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

A single front-loaded sentence beginning with the verb 'Ingests', with each comma-separated clause contributing a distinct fact (source examples, normalization, buffer update, snapshot). No filler, though the four-clause chain is dense.

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?

An output schema exists, so return values need not be described, and the effect chain is stated. But with 0% schema coverage for three parameters and no usage guidance, plus the unresolved conflict between the described writes and the read-only annotation, the definition is only minimally sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description carries the full burden for source, serverName, and the nested diagnostics array (file/range/message/severity/code). It only adds a loose gloss on 'external LSP diagnostics (e.g., from VS Code or language servers)' and explains none of the three parameters or the required item shape, leaving the gap largely unfilled.

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 and resource (ingest external LSP diagnostics) and enumerates the concrete effects: normalize to the unified schema, update the buffer, record a snapshot. An agent knows exactly what the tool does. It does not, however, distinguish itself from siblings such as get_live_diagnostics or get_diagnostic_snapshot, which it is implicitly the input-side counterpart of.

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. The description never says to reach for this tool only when pushing diagnostics from an external editor/language server, nor does it contrast with get_live_diagnostics (read the buffer) or get_diagnostic_snapshot (read a snapshot). Usage context must be inferred entirely.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavior: the literal return string 'pong', the error behavior on invalid arguments, and the no-authentication requirement, which is not captured by any structured field.

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

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

Three short sentences, front-loaded with the purpose before the usage hint and the operational caveats. The 'read-only... no side effects' clause partly restates the readOnlyHint/destructiveHint annotations, but the redundancy is minor and the whole entry is tight.

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 health check with an output schema, everything an agent needs is present: what it returns, that no auth is required, and how errors surface. No gaps remain that would affect a correct invocation.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics to explain beyond the note that invalid arguments produce an error response.

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 ('Checks whether the Signalint MCP server is responsive') and is immediately distinguishable from the domain-specific siblings (check_project, check_files, get_loop_status), which test application state rather than connectivity. An agent can tell this is the generic server liveness probe 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 names the use case: 'Use this to verify the server is connected before running diagnostics.' It gives clear context for when to reach for it, though it does not state when not to use it or contrast it against the sibling check_* 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 the safe read-only profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false, idempotentHint=false). The description adds genuinely new context: it is in-memory, never touches the filesystem, validates paths against canonical project-root containment, and yields a transactionId. That is meaningful behavioral detail 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 dense sentences, front-loaded with the core behavior (in-memory preview, no filesystem writes) before the secondary detail (path validation, transactionId). 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?

An output schema exists, so return values need not be spelled out, and the annotations plus description jointly cover the safety profile and the key behavior. The two real gaps are the undocumented patches parameter and the missing routing guidance for when to preview versus apply.

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

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

Schema description coverage is 0% and the single 'patches' array parameter is completely undocumented — neither the schema nor the description explains the required file/originalContent/patchedContent triple or the optional description field. The brief mention of 'paths' only loosely hints at the patch structure, leaving the agent to infer the input contract.

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: 'Creates an in-memory preview of proposed diagnostic fixes.' The phrase 'without touching the filesystem' implicitly separates it from apply_diagnostic_fix, but no sibling is named explicitly, so differentiation is inferential rather than stated.

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

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

Usage is implied — this is clearly the dry-run step before apply_diagnostic_fix — but the description never says when to use it versus applying directly, nor does it name the alternative or any prerequisites. An agent must infer the preview-then-apply workflow 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.