FAQ

Is Signalint another linter?

No. It invokes registered diagnostic engines and normalizes, groups, ranks, caches, and tracks their output. Native engine rules and compiler configuration still determine diagnostics.

Does it fix files?

Checks request no automatic source-fix mode. Explicit apply_diagnostic_fix can write caller-provided full-file replacements after preview and confirm: true. It does not generate patches automatically, guarantee filesystem-atomic writes, or undo successful writes after failed verification; see transaction limits. fixable is metadata, not an edit patch or a safe-edit guarantee. Cache/session writes and TypeScript build-info artifacts still occur; plugins/configuration run with your permissions.

Does local mean all my data stays private?

Signalint has local stdio diagnostic transport and no hosted Signalint API or API key. Your MCP client, model, and engine plugins have their own data/network behavior. Local execution is not a blanket privacy promise or sandbox. See security.

Which languages can it check?

The project safety gate and fixed engine set target JS/TS projects. Biome can additionally contribute JSON/JSONC, CSS, and GraphQL diagnostics within that ecosystem. New library adapters normalize supplied Ruff/Mypy, Cargo/Clippy and golangci-lint reports, and MCP accepts LSP-shaped batches. It does not launch Python/Rust/Go toolchains, arbitrary engines, a watcher or a vulnerability scanner. See external diagnostics.

Are Oxlint, TypeScript, or Biome bundled?

Since 1.1.0, all three are optional peers, not required runtime dependencies. The 1.2.1 declarations are Oxlint 1.86.0, TypeScript 7.0.2, and Biome 2.5.15. Install the chosen toolchain in your project. ESLint is also project-local and is not shipped as a runtime dependency.

The resolver can still fall back to an engine actually available beside Signalint, as in the source checkout; that is not a fresh-install guarantee. If an enabled engine cannot be resolved when needed, its outcome is disabled. No successful engine means nothing_checked, not clean.

Which executable should I use?

Use signalint for explicit CLI work. Since 1.1.1 signalint-mcp also recognizes CLI verbs such as doctor/check/stats, while a normal non-TTY client launch starts stdio. A bare interactive server launch prints guidance and exits 2 rather than hanging.

Does it always save 80% of tokens?

No. Current audit measurements compare bytes, with separate standalone, MCP result, and captured response-line baselines. Repeated rules can compress well; one-off unrelated issues can have higher overhead. Neither an upstream historical percentage nor a byte/token estimate proves your model’s token cost or repair success. See benchmarks.

Is text mode the same as compact mode?

No. MCP text mode omits structured content and output-schema advertisement. Compact mode changes check keys and omits their root. structured now mirrors diagnostic JSON in its first text block and adds a second summary; it is not the lower-byte mode. That second summary can still be misleading with compact keys. Validating host behavior needs testing. Read payload modes.

Does check_files type-check only those files?

No. TypeScript still runs its configured program, then the file provider filters displayed diagnostics to requested paths. Filtered-count aliases warn about other diagnostics. The metadata fingerprint improves invalidation for some unrequested edits, not every dependency/configuration context. See caching.

Can I retrieve every omitted issue with get_issue_detail?

Detail needs a known reference. Omitted flat IDs are not listed by the check summary, but get_live_diagnostics can enumerate latest internal/buffered records. It is not historical pagination. Older retained checks remain addressable by explicit checkId until eviction/expiry; the snapshot metadata tool does not return its complete issue array. Use narrower checks/native diagnostics when needed.

Can I use one global MCP entry for every repository?

Be deliberate: a fixed project root can point diagnostics at the wrong project. Registry targets are generated configuration, not proof of every editor version’s active path/schema. Use client setup and multiple-project safety to verify the actual root.

Does doctor PASSED prove the setup is correct?

No. It now inspects all four engine package records and payload mode, but can swallow config parse errors and issue non-blocking missing-engine warnings. It does not prove native engines ran, a client handshake succeeded, or every editor setting is valid.

Does SQLite waiting guarantee concurrent agents always succeed?

No. The cache waits up to 5 seconds for locks. Longer contention can still fail, and this does not globally serialize session logging or every project operation.

Where should I start when something is wrong?

Read troubleshooting, run doctor from the intended repository, and inspect a real check’s status/outcomes. Include sanitized configuration, package/Node versions, and engine messages in an upstream issue only when appropriate; do not post secrets or private source.

Do hooks or a green delta prove the project is clean?

No. Hook thresholds currently miss clustered errors and can approve all-disabled checks. Delta advice ignores engine coverage and can treat unobserved out-of-scope issues as resolved. Inspect status, engines and scope, then run explicit required validation. See hooks and snapshots & delta.