Signalint is a read-only local MCP server for JavaScript/TypeScript diagnostics that runs linters/type checkers, clusters issues, and tracks loops.
ping: Verify the server is responsive (returns pong).
check_project: Run full-project diagnostics with Oxlint, tsc, and optionally Biome; cluster issues by root cause with priorities and warnings.
check_files: Run incremental diagnostics on specified files, using content-hash caching to skip unchanged files.
get_issue_detail: Fetch full details for a cluster or issue from the latest check; returns stale if no longer present.
get_loop_status: List diagnostic signatures currently looping or file-rule churn from accumulated session history.
All tools are read-only, modify no files, and require no authentication.
Optionally runs Biome to provide linting and formatting diagnostics, with support for Biome configuration and caching.
Runs the TypeScript compiler to provide type checking and diagnostics for JavaScript and TypeScript projects, with support for project references and incremental caching.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@signalint Run lint and type checking on this project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Signalint is a reliable, read-only-by-default diagnostic intelligence layer for AI coding agents (Claude Code, Cursor, Codex, VS Code) and CI workflows.
Instead of flooding an agent's context window with thousands of raw compiler lines, Signalint normalizes diagnostics across compilers, linters, and language servers into bounded, priority-clustered issue summaries, calculates verification deltas against explicit baselines, and detects oscillating fix loops.
13 Complete MCP Tools: From incremental checks and immutable snapshots to live diagnostic ingestion and journaled transactional fix application.
Verification Deltas: Exact arithmetic on introduced, resolved, and unchanged diagnostics with semantic identity matching that survives line shifts.
Immutable Snapshots & Concurrency Safety: Isolated in-memory snapshot store keyed by checkId eliminates race collisions during concurrent checks.
Monorepo-Aware Planning: Unites package manifests (pnpm-workspace.yaml) parsed via pure-JS YAML with glob negation exclusions and TypeScript Project References, ordering checks topologically.
Multi-Source Provenance: Distinguishes compiler, linter, and editor/LSP diagnostics across JavaScript, TypeScript, Python (Ruff/Mypy), Rust (Clippy), and Go (GolangCI-Lint).
Portable Host Hooks: Native verify-after-change adapters for Claude Code, Cursor, Codex, and VS Code.
In-Memory Previews & In-Process Rollback: In-memory previews never touch disk; apply uses per-file adjacent temporary-file replacement, pre-write drift detection, and in-process best-effort rollback for multi-file writes (does not claim persistent crash recovery if aborted abruptly).
Related MCP server: agent-workspace-mcp
Node.js >= 22.12.0 (utilizes native node:sqlite).
Your project installs its own diagnostic engines (typescript, oxlint, eslint, and/or @biomejs/biome). Signalint detects project-local installations and ships no bundled engines.
npx signalint initThis detects your project's linters/compilers, generates signalint.config.json, and configures your installed MCP clients.
Add Signalint to your MCP configuration (e.g. claude_desktop_config.json, .cursor/mcp.json):
{
"mcpServers": {
"signalint": {
"command": "npx",
"args": ["-y", "signalint-mcp"]
}
}
}Signalint exposes 13 strictly typed MCP tools over stdio:
Tool | Category | Safety Annotation | Description |
| Diagnostics | Read-only ( | Verifies server responsiveness and canonical project root path. |
| Diagnostics | Read-only ( | Full project/workspace scan across all enabled engines. |
| Diagnostics | Read-only ( | Fast incremental check on specific files using content-hash caching. |
| Diagnostics | Read-only ( | Retrieves full, unomitted issue records anchored to an immutable |
| Diagnostics | Read-only ( | Returns oscillating fix signatures and rule churn detected in the session. |
| Snapshots | Read-only ( | Retrieves complete state and metrics for an immutable check snapshot. |
| Deltas | Read-only ( | Computes verification delta between a baseline check and a current check. |
| Deltas | Read-only ( | Runs incremental check on edited files and diffs against a baseline check. |
| Live / LSP | Read-only ( | Ingests external LSP or compiler diagnostics into Signalint's clustering model. |
| Live / LSP | Read-only ( | Returns active buffered diagnostics with source provenance. |
| Transactions | Read-only ( | Stages proposed code fixes in-memory. Does not write to disk. |
| Transactions | Mutating ( | Per-file adjacent temp replacement, pre-write drift check, and in-process best-effort rollback. |
| Transactions | Read-only ( | Drops an in-memory fix transaction without touching disk. |
See docs/mcp-contract.md for full JSON Schemas and error codes.
Signalint includes a comprehensive command-line interface:
# Run a project diagnostic scan:
npx signalint check .
npx signalint check src/ --format github # GitHub Actions annotations
# View session statistics and cache economics:
npx signalint stats
# Verify local engine availability and configuration:
npx signalint doctor
# Manage host verify-after-change hooks:
npx signalint hooks preview --runtime claude
npx signalint hooks install --runtime cursor --confirm
npx signalint hooks run --runtime claude --payload '<json-event>'Signalint natively understands multi-package monorepos:
Configure "monorepoMode": "auto" in signalint.config.json to detect pnpm-workspace.yaml via pure-JS YAML parsing with glob negation exclusions (!).
Strictly differentiates local workspace packages (workspace:*) from external npm registry dependencies.
Builds a topological dependency graph uniting package manifests and TypeScript project references.
Caches whole-program TypeScript builds in isolated per-package directories (.signalint/cache/tsc/<project-id>/).
Changes to a shared package automatically invalidate dependent packages while keeping independent siblings cached.
See docs/monorepo.md for configuration and architecture.
Automate post-edit verification without creating infinite agent loops:
Native adapters for Claude Code, Cursor, Codex, and VS Code.
Emits bounded context into prompt windows and blocks only on unresolved syntax/type errors.
See docs/hooks.md for setup instructions.
MIT © 2026 Tran Trong Qui
Runs Oxlint and TypeScript (and optionally Biome) lint and type diagnostics on a specific list of files, using per-engine content-hash caching to skip unchanged files. Read-only; no files are written or modified. Use this for incremental checks after editing specific files; use check_project for a full project scan. The files parameter expects relative file paths (not glob patterns) within the project directory — absolute paths or paths outside the root return an error response. Caching is file-content-hash-based: a file is re-checked only when its content or the engine's config file (e.g., .oxlintrc, tsconfig.json) has changed since the last call, not based on git status. TypeScript is a whole-program engine: it re-runs whenever any TypeScript file in the request has changed content.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes |
| Name | Required | Description |
|---|---|---|
| code | No | |
| engine | No | |
| status | Yes | |
| checkId | No | |
| engines | No | |
| message | No | |
| clusters | No | |
| truncated | No | |
| loopWarning | No | |
| projectRoot | No | |
| totalIssues | No | |
| schemaVersion | No | |
| fileRuleChurnWarning | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial non-obvious behavior: content-hash-based caching, the rule that re-checks trigger on content or config-file changes rather than git status, and the caveat that TypeScript is whole-program and re-runs when any TS file in the request changes. That is rich context beyond the structured fields.
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 the action and safety, then usage routing, then parameter constraints, then caching nuances. Each sentence carries distinct, load-bearing information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained; combined with annotations covering safety and the description covering usage, parameter constraints, and caching semantics, an agent has everything needed to invoke 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 description coverage is 0%, so the description must carry semantics, and it does: 'files' expects relative paths within the project directory, rejects globs/absolute/out-of-root paths with an error, and is bounded in practice by the checking model. It adds real meaning beyond the bare array type, though it does not restate the maxItems limit.
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 specific verbs and resources — Oxlint and TypeScript lint/type diagnostics on a specific list of files — and immediately distinguishes itself from the sibling check_project by scoping to files rather than the whole project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: 'Use this for incremental checks after editing specific files; use check_project for a full project scan.' It also states the exclusion for the files parameter (no globs, no absolute paths) and the error consequence, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs and clusters Oxlint and TypeScript (and optionally Biome) lint and type diagnostics for one or more project paths. Read-only; no files are written or modified. Paths default to the project root (".") when omitted; paths must be relative and within the project directory — absolute paths or paths outside the root return an error response. Use this for a full project scan; use check_files instead for faster incremental checks after editing specific files. Each call re-runs all enabled engines with no caching.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No |
| Name | Required | Description |
|---|---|---|
| code | No | |
| engine | No | |
| status | Yes | |
| checkId | No | |
| engines | No | |
| message | No | |
| clusters | No | |
| truncated | No | |
| loopWarning | No | |
| projectRoot | No | |
| totalIssues | No | |
| schemaVersion | No | |
| fileRuleChurnWarning | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavior: paths are validated against the project root with an error response for absolute/outside-root paths, and every call re-runs all enabled engines with no caching. That caching and error-semantics detail is exactly the kind of context annotations cannot 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?
Four sentences, front-loaded with the core action, then the read-only guarantee, then path constraints, then the sibling routing. Every sentence carries distinct information with no padding.
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 single-optional-parameter read-only scan tool, the description covers defaults, constraints, error behavior, caching semantics, and sibling routing — 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?
The single paths parameter has 0% schema description coverage, so the description must compensate, and it does: default of "." when omitted, relative-only requirement, must be within the project directory, and error behavior otherwise. It stops short of describing ordering or the 512 maxItems cap, so it is not fully 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?
States a specific verb+resource: runs and clusters Oxlint and TypeScript lint/type diagnostics over project paths. It explicitly names the sibling it is not (check_files) and defines the scope (full project scan) versus incremental checks, so an agent can disambiguate 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?
Gives explicit when-to-use (full project scan) and when-to-use-the-alternative (check_files for faster incremental checks after editing specific files). It also covers defaults when paths are omitted and the constraint that paths must be relative and inside the project root.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full issue list for either one cluster ID or one issue ID from the most recent check_project or check_files call. Read-only; no files are written or modified. Supply exactly one of clusterId or issueId — supplying both or neither returns an argument error. If the referenced cluster or issue no longer exists in the latest results (e.g., after re-running a check), returns a status: "stale" response instead of an error; call check_project or check_files again to refresh.
| Name | Required | Description | Default |
|---|---|---|---|
| checkId | No | ||
| issueId | No | ||
| clusterId | No |
| Name | Required | Description |
|---|---|---|
| code | No | |
| issues | No | |
| status | No | |
| message | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only declare readOnly/idempotent/non-destructive), the description discloses non-obvious behavior: an argument error when both or neither ID is given, and a status: "stale" response instead of an error when the entity no longer exists after a re-run. This is exactly the kind of failure-mode detail annotations cannot carry.
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, front-loaded with the core action, then constraints, then edge-case behavior. No filler; the brief redundancy about read-only is minor.
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 structure need not be explained, yet the description still flags the stale status shape. Combined with the parameter constraint and staleness recovery path, an agent has everything needed 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 description coverage is 0%, so the description must compensate. It clarifies the semantics of clusterId and issueId well (exactly-one-of, error otherwise), but the third parameter, checkId, is never mentioned in either the schema or the description, leaving a real 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 (returns) and resource (full issue list for one cluster ID or one issue ID), and explicitly ties the result to the most recent check_project or check_files call, which separates it from those siblings. An agent can distinguish it from check_project/check_files without opening a 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 prerequisite context (must follow a check_project/check_files call), the constraint that exactly one of clusterId or issueId must be supplied, and the recovery action (call check_project or check_files again) when a stale response is returned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all diagnostic issue signatures currently flagged as looping (repeatedly appearing and disappearing) in this server session. Read-only; no files are written or modified. Loop history is accumulated across all check_project and check_files calls in this process lifetime, and is restored from .signalint/session.jsonl on startup. Takes no parameters. Use this to identify which diagnostics an agent is oscillating on; use check_project or check_files to run fresh diagnostics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| looping | Yes | |
| signatures | Yes | |
| fileChurning | Yes | |
| fileRuleChurns | Yes |
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.
Checks whether the Signalint MCP server is responsive. Read-only; returns the string "pong" with no side effects. Use this to verify the server is connected before running diagnostics. Invalid arguments return an error response; no authentication is required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| pong | Yes | True when the server is responsive. |
| projectRoot | Yes | Canonical absolute project root path. |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0check_files7 fields changedOutput schema / properties / checkIdAdded value: +{
+ "type": "string"
+}Output schema / properties / engine / enumPrevious value: -[
- "oxlint",
- "tsc",
- "biome"
-]New value: +[
+ "oxlint",
+ "tsc",
+ "biome",
+ "eslint"
+]Output schema / properties / engines / properties / eslintAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "error",
+ "disabled"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}Output schema / properties / engines / requiredPrevious value: -[
- "oxlint",
- "tsc",
- "biome"
-]New value: +[
+ "oxlint",
+ "tsc",
+ "biome",
+ "eslint"
+]Output schema / properties / projectRootAdded value: +{
+ "type": "string"
+}Output schema / properties / schemaVersion / enumPrevious value: -[
- "1.2"
-]New value: +[
+ "1.3"
+]Output schema / properties / status / enumPrevious value: -[
- "clean",
- "issues_found",
- "timeout",
- "error"
-]New value: +[
+ "clean",
+ "issues_found",
+ "error"
+]check_project7 fields changedOutput schema / properties / checkIdAdded value: +{
+ "type": "string"
+}Output schema / properties / engine / enumPrevious value: -[
- "oxlint",
- "tsc",
- "biome"
-]New value: +[
+ "oxlint",
+ "tsc",
+ "biome",
+ "eslint"
+]Output schema / properties / engines / properties / eslintAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "error",
+ "disabled"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}Output schema / properties / engines / requiredPrevious value: -[
- "oxlint",
- "tsc",
- "biome"
-]New value: +[
+ "oxlint",
+ "tsc",
+ "biome",
+ "eslint"
+]Output schema / properties / projectRootAdded value: +{
+ "type": "string"
+}Output schema / properties / schemaVersion / enumPrevious value: -[
- "1.2"
-]New value: +[
+ "1.3"
+]Output schema / properties / status / enumPrevious value: -[
- "clean",
- "issues_found",
- "timeout",
- "error"
-]New value: +[
+ "clean",
+ "issues_found",
+ "error"
+]get_issue_detail2 fields changedInput schema / properties / checkIdAdded value: +{
+ "type": "string"
+}Output schema / properties / issues / items / properties / engine / enumPrevious value: -[
- "oxlint",
- "tsc",
- "biome"
-]New value: +[
+ "oxlint",
+ "tsc",
+ "biome",
+ "eslint"
+]ping2 fields changedOutput schema / properties / projectRootAdded value: +{
+ "description": "Canonical absolute project root path.",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "pong"
-]New value: +[
+ "pong",
+ "projectRoot"
+]v0.4.0check_files2 fields changedOutput schema / properties / fileRuleChurnWarningAdded value: +{
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "checkCount": {
+ "type": "integer"
+ },
+ "file": {
+ "type": "string"
+ },
+ "hint": {
+ "type": "string"
+ },
+ "rule": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "file",
+ "rule",
+ "checkCount",
+ "hint"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / schemaVersion / enumPrevious value: -[
- "1.1"
-]New value: +[
+ "1.2"
+]check_project2 fields changedOutput schema / properties / fileRuleChurnWarningAdded value: +{
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "checkCount": {
+ "type": "integer"
+ },
+ "file": {
+ "type": "string"
+ },
+ "hint": {
+ "type": "string"
+ },
+ "rule": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "file",
+ "rule",
+ "checkCount",
+ "hint"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / schemaVersion / enumPrevious value: -[
- "1.1"
-]New value: +[
+ "1.2"
+]get_loop_status3 fields changedOutput schema / properties / fileChurningAdded value: +{
+ "type": "boolean"
+}Output schema / properties / fileRuleChurnsAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "checkCount": {
+ "type": "integer"
+ },
+ "file": {
+ "type": "string"
+ },
+ "hint": {
+ "type": "string"
+ },
+ "rule": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "file",
+ "rule",
+ "checkCount",
+ "hint"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / requiredPrevious value: -[
- "looping",
- "signatures"
-]New value: +[
+ "looping",
+ "signatures",
+ "fileChurning",
+ "fileRuleChurns"
+]v0.3.7check_files1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "clusters": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "clusterId": {
+ "type": "string"
+ },
+ "fileCount": {
+ "type": "integer"
+ },
+ "issueCount": {
+ "type": "integer"
+ },
+ "priority": {
+ "type": "integer"
+ },
+ "rootCauseSummary": {
+ "type": "string"
+ },
+ "ruleIds": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sampleIssueIds": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "suggestedAction": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "clusterId",
+ "rootCauseSummary",
+ "ruleIds",
+ "issueCount",
+ "fileCount",
+ "priority",
+ "suggestedAction",
+ "sampleIssueIds"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "code": {
+ "type": "string"
+ },
+ "engine": {
+ "enum": [
+ "oxlint",
+ "tsc",
+ "biome"
+ ],
+ "type": "string"
+ },
+ "engines": {
+ "additionalProperties": false,
+ "properties": {
+ "biome": {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "error",
+ "disabled"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ },
+ "oxlint": {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "error",
+ "disabled"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ },
+ "tsc": {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "error",
+ "disabled"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "oxlint",
+ "tsc",
+ "biome"
+ ],
+ "type": "object"
+ },
+ "loopWarning": {
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "hint": {
+ "type": "string"
+ },
+ "occurrences": {
+ "type": "integer"
+ },
+ "signature": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "signature",
+ "occurrences",
+ "hint"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "message": {
+ "type": "string"
+ },
+ "schemaVersion": {
+ "enum": [
+ "1.1"
+ ],
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "clean",
+ "issues_found",
+ "timeout",
+ "error"
+ ],
+ "type": "string"
+ },
+ "totalIssues": {
+ "type": "integer"
+ },
+ "truncated": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}check_project1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "clusters": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "clusterId": {
+ "type": "string"
+ },
+ "fileCount": {
+ "type": "integer"
+ },
+ "issueCount": {
+ "type": "integer"
+ },
+ "priority": {
+ "type": "integer"
+ },
+ "rootCauseSummary": {
+ "type": "string"
+ },
+ "ruleIds": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sampleIssueIds": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "suggestedAction": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "clusterId",
+ "rootCauseSummary",
+ "ruleIds",
+ "issueCount",
+ "fileCount",
+ "priority",
+ "suggestedAction",
+ "sampleIssueIds"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "code": {
+ "type": "string"
+ },
+ "engine": {
+ "enum": [
+ "oxlint",
+ "tsc",
+ "biome"
+ ],
+ "type": "string"
+ },
+ "engines": {
+ "additionalProperties": false,
+ "properties": {
+ "biome": {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "error",
+ "disabled"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ },
+ "oxlint": {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "error",
+ "disabled"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ },
+ "tsc": {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "error",
+ "disabled"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "oxlint",
+ "tsc",
+ "biome"
+ ],
+ "type": "object"
+ },
+ "loopWarning": {
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "hint": {
+ "type": "string"
+ },
+ "occurrences": {
+ "type": "integer"
+ },
+ "signature": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "signature",
+ "occurrences",
+ "hint"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "message": {
+ "type": "string"
+ },
+ "schemaVersion": {
+ "enum": [
+ "1.1"
+ ],
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "clean",
+ "issues_found",
+ "timeout",
+ "error"
+ ],
+ "type": "string"
+ },
+ "totalIssues": {
+ "type": "integer"
+ },
+ "truncated": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}get_issue_detail1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "issues": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "clusterId": {
+ "type": "string"
+ },
+ "col": {
+ "type": "integer"
+ },
+ "engine": {
+ "enum": [
+ "oxlint",
+ "tsc",
+ "biome"
+ ],
+ "type": "string"
+ },
+ "file": {
+ "type": "string"
+ },
+ "fixable": {
+ "type": "boolean"
+ },
+ "issueId": {
+ "type": "string"
+ },
+ "line": {
+ "type": "integer"
+ },
+ "message": {
+ "type": "string"
+ },
+ "rule": {
+ "type": "string"
+ },
+ "severity": {
+ "enum": [
+ "error",
+ "warning"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "issueId",
+ "file",
+ "line",
+ "col",
+ "engine",
+ "rule",
+ "severity",
+ "message",
+ "fixable"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "stale",
+ "error"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+}get_loop_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "looping": {
+ "type": "boolean"
+ },
+ "signatures": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "hint": {
+ "type": "string"
+ },
+ "occurrences": {
+ "type": "integer"
+ },
+ "signature": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "signature",
+ "occurrences",
+ "hint"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "looping",
+ "signatures"
+ ],
+ "type": "object"
+}ping1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "pong": {
+ "description": "True when the server is responsive.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "pong"
+ ],
+ "type": "object"
+}v0.3.3check_filescheck_projectget_issue_detailget_loop_statuspingScored across 5 tools
Each tool has a clearly distinct purpose: ping for health, check_project for full scans, check_files for incremental scans, get_issue_detail for inspecting results, and get_loop_status for loop detection. Descriptions explicitly cross-reference each other (e.g., check_project vs check_files) to guide selection, leaving no meaningful overlap.
Mostly consistent verb_noun pattern with check_project, check_files, get_issue_detail, and get_loop_status. The bare 'ping' deviates slightly, but it follows standard health-check convention so it remains readable and predictable.
Five tools is well-scoped for a lint/diagnostic server, with each tool earning its place across the scan-inspect-monitor workflow. No redundant or filler tools are present.
The surface covers the core lifecycle: health check, full and incremental scans, issue detail retrieval, and loop monitoring. Minor gaps exist (e.g., no explicit tool to list all clusters or clear/reset session history), but agents can work around these via existing tools.
The official Svelte MCP server providing docs and autofixing tools for Svelte development
Lean 4 MCP server: compile, prove theorems, and formalize math with Mathlib.
A TypeScript MCP server for Home Assistant, enabling programmatic management of entities, automati…
MCP server (stdio): lint OpenAPI specs with Spectral via the AgentForge API
