Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 13 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness5/5

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.

Maintenance

ActivityActive
ResponsivenessNo issues