signalint
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pingA | 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. |
| check_projectA | 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. |
| check_filesA | 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. |
| get_issue_detailA | Returns the full issue list for either one cluster ID or one issue ID for a specific checkId. Read-only; no files are written or modified. Supply checkId (required) and exactly one of clusterId or issueId — supplying both or neither returns an argument error. If the referenced checkId is unknown/expired or the issue/cluster no longer exists in that check snapshot, returns a status: "stale" response instead of an error. |
| get_loop_statusA | 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. |
| get_diagnostic_snapshotA | Retrieves the immutable diagnostic snapshot recorded for a specific checkId. Read-only; no files are modified. Returns full metadata, engine statuses, clusters, remaining issues, and performance metrics for that check run. |
| compare_diagnosticsA | Computes a deterministic diagnostic delta between two checks (baselineCheckId and currentCheckId). Read-only; no files are modified. Identifies introduced errors, resolved errors, unchanged issues, and net error delta, resilient to line shifts. |
| after_edit_checkA | Runs incremental diagnostics on specified edited files and computes a verification delta against an optional baselineCheckId. Read-only; no files are written or modified. Use this after modifying files to verify whether edits introduced or resolved diagnostics relative to the baseline check. |
| ingest_diagnosticsC | Ingests external LSP diagnostics (e.g., from VS Code or language servers), normalizes them to Signalint's unified schema, updates the active diagnostic buffer, and records an immutable snapshot. |
| get_live_diagnosticsB | Returns current bounded active diagnostics and clusters merged from both internal engines and ingested LSP sources, with clear provenance per issue. |
| preview_diagnostic_fixA | Creates an in-memory preview of proposed diagnostic fixes without touching the filesystem. Validates paths against canonical project root containment and returns a preview with a unique transactionId. |
| apply_diagnostic_fixA | Applies diagnostic modifications using per-file adjacent temporary-file replacement, pre-write drift detection, and in-process best-effort rollback for multi-file writes. Requires explicit confirm: true. If baselineCheckId is provided, it must be valid and active in the snapshot store; unknown or expired baselines abort immediately without modifying files. Does not provide persistent crash recovery if the process terminates abruptly. |
| discard_diagnostic_fixB | Discards an in-memory diagnostic fix preview by transactionId, dropping it from server storage. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools have clearly distinct purposes (check_project vs check_files vs check_project are distinguished by scope and caching; fix lifecycle tools are separated). Three tools — after_edit_check, compare_diagnostics, and ingest_diagnostics — all compute deltas or ingest diagnostics and could be confused in an agent's workflow, but descriptions clarify usage contexts well. Overall boundaries are clear enough that misselection is unlikely.
Names predominantly follow verb_noun (check_project, get_issue_detail, preview_diagnostic_fix, apply_diagnostic_fix, discard_diagnostic_fix, get_live_diagnostics), with a few noun_noun or truncated forms like after_edit_check, ping, and get_loop_status. The pattern is still very readable and mostly predictable, with minor deviations like ping (single verb) and snapshot retrieval names.
13 tools is a reasonable size for a diagnostics server that supports checking, snapshotting, comparing, previewing fixes, applying fixes, and ingesting LSP data. No tool feels redundant or trivially unnecessary, though the fix preview/apply/discard trio adds complexity that could be consolidated if needed.
The surface covers the full diagnostic lifecycle: connectivity (ping), full/incremental checking (check_project, check_files, after_edit_check), snapshot retrieval, delta comparison, live merged diagnostics, loop detection, fix preview/apply/discard, and external LSP ingestion. CRUD-like coverage for fixes and diagnostics is complete with no obvious dead ends.