Signalint is a local MCP server that provides JavaScript and TypeScript diagnostics by running Oxlint, TypeScript, and optionally Biome, with caching, issue clustering, and loop detection. Its tools include:
ping: Verify server responsiveness.
check_project: Run and cluster diagnostics across project paths, with cache reuse.
check_files: Incremental check on specific files using per-engine caching.
get_issue_detail: Retrieve full details for a cluster or individual issue from the latest check.
get_loop_status: Inspect diagnostic signatures that are oscillating (appearing/disappearing) in the current session.
Beyond MCP tools, you can configure enabled engines, file/directory ignore patterns, and execution timeouts. A CLI (signalint check, signalint stats) allows manual checks and statistics. It integrates with GitHub Actions for CI, outputting annotations and failing jobs based on issue priority. Session artifacts and loop history can be restored across restarts from .signalint/session.jsonl.
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 "Install 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 local MCP server for JavaScript and TypeScript diagnostics. It runs
Oxlint, TypeScript, and optionally Biome; caches unchanged checks; clusters repeated
issues; and warns when the same diagnostic disappears and repeatedly returns.
Loop history is restored from valid .signalint/session.jsonl entries when the MCP
server restarts; malformed or crash-truncated lines are skipped.
Listed on:
Official MCP Registry (API listing)
When a coding agent requests diagnostics on a project, raw compiler and linter outputs quickly flood the context window with repetitive errors across multiple files. Signalint normalizes issues and clusters them by root cause before returning a bounded, priority-ranked response:
[
{
"issueId": "ts-01",
"file": "src/file01.ts",
"line": 10,
"col": 5,
"engine": "tsc",
"rule": "TS2322",
"severity": "error",
"message": "Type 'string' is not assignable to type 'number' in fixture assignment 01.",
"fixable": false
},
// ... 39 more raw normalized issues
]{
"schemaVersion": "1.1",
"status": "issues_found",
"engines": {
"oxlint": { "status": "ok" },
"tsc": { "status": "ok" },
"biome": { "status": "disabled" }
},
"totalIssues": 40,
"clusters": [
{
"clusterId": "c1",
"rootCauseSummary": "10 TS2322 issues across 10 files",
"ruleIds": ["TS2322"],
"issueCount": 10,
"fileCount": 10,
"priority": 1,
"suggestedAction": "Review the shared cause of TS2322 across 10 files",
"sampleIssueIds": ["ts-01", "ts-02"]
},
{
"clusterId": "c2",
"rootCauseSummary": "10 no-unused-vars issues across 10 files",
"ruleIds": ["no-unused-vars"],
"issueCount": 10,
"fileCount": 10,
"priority": 2,
"suggestedAction": "Review the shared cause of no-unused-vars across 10 files",
"sampleIssueIds": ["unused-01", "unused-02"]
},
{
"clusterId": "c3",
"rootCauseSummary": "10 eqeqeq issues across 10 files",
"ruleIds": ["eqeqeq"],
"issueCount": 10,
"fileCount": 10,
"priority": 5,
"suggestedAction": "Apply structured fixes for eqeqeq across 10 files",
"sampleIssueIds": ["eqeqeq-01", "eqeqeq-02"]
},
{
"clusterId": "c4",
"rootCauseSummary": "10 prefer-const issues across 10 files",
"ruleIds": ["prefer-const"],
"issueCount": 10,
"fileCount": 10,
"priority": 5,
"suggestedAction": "Apply structured fixes for prefer-const across 10 files",
"sampleIssueIds": ["const-01", "const-02"]
}
],
"truncated": false,
"loopWarning": null
}The agent receives a concise summary with priority-ordered clusters and sample issue IDs. When deeper detail is needed for a specific cluster or issue, the agent calls get_issue_detail without re-running the whole-project scan.
Related MCP server: agent-workspace-mcp
Node.js 20.19 or later in the Node 20 line, or Node.js 22.12 or later
A JavaScript or TypeScript project; TypeScript checks require a tsconfig.json
pnpm 11.9.0 for source development
Install Signalint in the project it should check:
npm install --save-dev signalint-mcpRun the setup command from that project root. It detects TypeScript, Oxlint, and
Biome configuration, writes signalint.config.json, and offers to update a nearby
Claude Code, Cursor, Codex CLI, or Antigravity MCP configuration:
npx signalint-mcp initIf no MCP client can be selected safely, the command prints exact configuration
snippets to copy. TypeScript is enabled only when a root tsconfig.json exists;
Biome is enabled when its config exists; Oxlint is the fallback when no configured
linter is detected. To configure Signalint manually, create signalint.config.json:
{
"engines": {
"oxlint": true,
"tsc": true,
"biome": false
},
"ignore": ["node_modules/**", "dist/**", ".signalint/**"],
"timeoutsMs": {
"oxlint": 30000,
"tsc": 120000,
"biome": 30000
}
}Run this from the checked project. Project scope writes a shareable .mcp.json:
claude mcp add --scope project signalint -- npx --no-install signalint-mcp
claude mcp get signalintOn native Windows, wrap npx as required by Claude Code:
claude mcp add --scope project signalint -- cmd /c npx --no-install signalint-mcp
claude mcp get signalintRestart Claude Code if it was already open. Ask it to call Signalint's ping tool,
then call check_project with { "paths": ["."] }.
See the Claude Code MCP documentation for scope and troubleshooting details.
Create .cursor/mcp.json in the checked project:
{
"mcpServers": {
"signalint": {
"command": "npx",
"args": ["--no-install", "signalint-mcp"]
}
}
}On native Windows use "command": "cmd" and
"args": ["/c", "npx", "--no-install", "signalint-mcp"]. Open Cursor's MCP
settings, enable signalint, and call ping followed by check_project.
See the Cursor MCP documentation for configuration locations and status controls.
The ChatGPT desktop app, Codex CLI, and IDE extension share a single
configuration file. The quick-add command writes to ~/.codex/config.toml
(global) automatically:
codex mcp add signalint -- npx --no-install signalint-mcpFor project-scoped configuration (trusted projects only), add to
.codex/config.toml in the project root:
[mcp_servers.signalint]
command = "npx"
args = ["--no-install", "signalint-mcp"]On native Windows, use cmd and pass npx as an argument:
[mcp_servers.signalint]
command = "cmd"
args = ["/c", "npx", "--no-install", "signalint-mcp"]See the Codex MCP documentation
for all configuration options including cwd, env, and per-tool approval
settings.
Antigravity uses its own MCP configuration file. The path that has been
verified through dogfooding on Windows is:
%USERPROFILE%\.gemini\antigravity\mcp_config.json.
The init command can update this file after confirmation. The equivalent
Windows configuration is:
{
"mcpServers": {
"signalint": {
"command": "cmd",
"args": ["/c", "npx", "--no-install", "signalint-mcp"],
"cwd": "<absolute-path-to-your-project>"
}
}
}On macOS or Linux, use "command": "npx" and
"args": ["--no-install", "signalint-mcp"]. Restart or reconnect Antigravity
after updating the configuration.
Note on Antigravity product variants: Antigravity has split into separate
products (IDE, CLI, SDK). Each variant may use a different config path — the
IDE path above is the one confirmed working; other variants may use
~/.gemini/config/mcp_config.json or a project-scoped .agents/mcp_config.json.
See antigravity.google/docs/mcp for
the authoritative list per product.
Windows .cmd shims created by npm link can expose a junction path to Node. If
signalint-mcp ends with an initialize/EOF error or signalint stats exits with
code 0 but prints nothing, bypass the shim with the compiled entrypoint paths:
node C:\absolute\path\to\Signalint\dist\src\index.js
node C:\absolute\path\to\Signalint\dist\src\cli.js statsCurrent builds canonicalize linked paths before deciding whether to start, but direct Node invocation remains the reliable fallback for older builds or unusual npm setups.
engines.oxlint, engines.tsc, and engines.biome are booleans. Defaults are
Oxlint and tsc enabled, Biome disabled. Omitted engine keys retain those defaults.
Unknown keys and incorrectly typed values fail with a configuration error.
ignore is an array of project-relative globs. Signalint supports *, **, and
?, normalizes Windows separators, and excludes matching requested paths and
diagnostics. Because tsc is a whole-program engine, it still receives the complete
tsconfig.json program when invoked; ignored TypeScript paths do not trigger an
incremental check_files run and their diagnostics are removed from the response.
Engine-native configuration remains in native files. The v1 cache hash recognizes
root .oxlintrc, .oxlintrc.json, oxlint.json, tsconfig.json, biome.json,
and biome.jsonc. Changing one invalidates the related engine cache. Other valid
sources—including .oxlintrc.jsonc, extended configs, and nested package configs—
are not part of v1 cache hashing; clear .signalint/ after changing one of them.
timeoutsMs sets positive-integer subprocess deadlines in milliseconds. Defaults are
30 seconds for Oxlint, 120 seconds for tsc, and 30 seconds for Biome. A timed-out
engine and its child processes are terminated. In the schema 1.1 check response, that
engine has { "status": "error", "message": "tsc did not complete within 120s" }
under engines, while completed engines' diagnostics are preserved.
Signalint supports JavaScript and TypeScript projects only.
The built-in engines are Oxlint, TypeScript, and Biome; v1 does not support arbitrary custom engines.
Signalint reports whether an issue has a structured fix, but v1 does not apply fixes.
Signalint is not a SAST or security scanner.
There is no IDE extension yet; integrations use MCP or the command-line client.
Loop detection is deliberately limited to lint, type, and test issue signatures; it does not detect general agent-conversation loops.
The tsc adapter requires one tsconfig.json at the project root. Monorepos must
provide a solution-style root config using TypeScript Project References;
Signalint does not auto-discover independent package configs.
check_files treats only the files explicitly passed to that call as relevant to
TypeScript cache invalidation. If file A changes but is omitted while unchanged file
B is checked, and B depends on A, Signalint can reuse a stale tsc result. Include
every changed dependency file or run check_project; dependency-graph-based
invalidation is not implemented in v1.
ping checks that the local server is connected and returns pong.
check_project accepts optional { "paths": ["."] } and returns clustered diagnostics.
check_files accepts { "files": ["src/file.ts"] } and uses incremental caching.
get_issue_detail accepts exactly one clusterId or issueId from the latest
successful check and returns its full issues, or a status: "stale" response.
get_loop_status returns issue signatures currently flagged as oscillating.
Cache and session artifacts are written under .signalint/ and should not be committed.
Run the same project check without an MCP client:
npx --no-install signalint check .After MCP checks have accumulated in .signalint/session.jsonl, print the Phase 6
measurement summary:
npx --no-install signalint statsThe report includes average normalized-raw-to-clustered JSON payload reduction,
engine-file cache hit rate, average and maximum check latency, and the number of
distinct issue signatures that triggered loop warnings. An engine-file lookup counts
each enabled engine separately, so one changed TypeScript file can miss once for
Oxlint and once for tsc. Latency covers handler work from MCP tool entry through
engine/cache work, clustering, and loop evaluation; it excludes the telemetry append
and stdio transport. Statistics include the active session log and its rotated .1
backup, with their retained overlap counted once. Clean checks with zero raw payload are excluded from the
reduction average, and older checks with missing metrics remain counted without
contributing to the unavailable aggregate.
The CLI exits with code 1 when issues are found. Two flags support CI use:
--format github prints one GitHub Actions annotation
(::error file=...,line=...,col=...::message or ::warning ...) per issue
instead of JSON, and --fail-on-priority <N> exits non-zero only if a
cluster's priority is at or below N instead of on any issue found.
To exercise an actual MCP check_project call against the installed package,
run:
node node_modules/signalint-mcp/examples/check-project.mjs .action.yml at the repository root wraps signalint check as a composite
action for CI. It installs Node, installs signalint-mcp from npm, and runs
the check with --format github so issues appear as inline annotations on
the pull request diff:
- uses: TranQui004/signalint@main
with:
fail-on-priority: "3"fail-on-priority defaults to 5, which fails the job on any issue found,
matching signalint check's default behavior without the flag. Lower values
only fail the job when a cluster is at least that urgent: priority 1 is an
error with no structured fix, and priority increases toward 5 as issues
become more fixable or more systemic (see scorePriority in
src/cluster/clusterEngine.ts).
pnpm 11.9.0 is the canonical package manager for source development. The repository
commits pnpm-lock.yaml, declares pnpm in package.json, and uses pnpm in CI.
pnpm install --frozen-lockfile
pnpm lint
pnpm typecheck
pnpm test
pnpm buildIf a global npm shim cannot find npm-cli.js, build directly with node node_modules/typescript/bin/tsc -p tsconfig.json.
Before preparing a release, use npm pack --dry-run and verify the packed tarball
in a clean project. Publishing requires explicit release approval.
See SECURITY.md for the current npm audit advisory, its evaluated runtime reachability, and the conditions that require reassessment.
Website — overview, docs, and live examples.
ARCHITECTURE.md — how the layers fit together and what each module does.
CONTRIBUTING.md — development setup, verification, and pull requests.
AGENTS.md — coding standards for this repository.
SECURITY.md — threat model, trust boundaries, and audit status.
CHANGELOG.md — notable changes by release.
docs/history/ — original build plan and pre-launch audit trail.
Signalint is available under the MIT License.
Average 4.8/5 across 5 of 5 tools scored.
Each tool has a clear, distinct purpose: ping for health, check_project for full scans, check_files for incremental scans, get_issue_detail for querying results, and get_loop_status for looping diagnostics. No two tools overlap in functionality, and the descriptions explicitly differentiate when to use check_project vs check_files.
All tool names follow a consistent verb_noun pattern using snake_case: ping, check_project, check_files, get_issue_detail, get_loop_status. The only slight deviation is 'ping' being a single verb, but it's a standard health check convention and does not break the pattern's clarity.
With 5 tools, the server is well-scoped for a linting/diagnostics service. Each tool covers a distinct aspect of the workflow (health check, full scan, incremental scan, result retrieval, loop monitoring) without unnecessary bloat, and there is no sense of missing core functionality.
The tool surface covers the primary lifecycle: run full checks, run incremental checks, retrieve issue details, and monitor recurring issues. A minor gap is the lack of a tool to list all clusters or clear session state, but the existing tools allow agents to work effectively around these omissions.
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 | |
| engines | No | |
| message | No | |
| clusters | No | |
| truncated | No | |
| loopWarning | No | |
| totalIssues | No | |
| schemaVersion | No | |
| fileRuleChurnWarning | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the annotations: content-hash-based caching, dependency on config files like .oxlintrc and tsconfig.json, and the whole-program re-run behavior of TypeScript. It also confirms no files are modified, which complements the readOnlyHint without contradicting it.
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 longer than average, but every clause earns its place: it covers purpose, usage context, path constraints, caching behavior, and engine-specific nuances. The use guidance is appropriately placed near the beginning, and the caching details are grouped logically. It is thorough but not bloated.
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 presence of a clear output schema and robust annotations, the description covers everything an agent needs to decide whether and how to call this tool: purpose, engine behavior, input constraints, error conditions, caching semantics, and sibling distinction. No critical operational context 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 schema only says 'files' is an array of non-empty strings, so the description carries the burden of explaining path semantics. It does this well by specifying relative paths, excluding glob patterns, and warning about absolute/outside-root paths. This is strong but not exhaustive; it could also clarify whether directories are accepted, though the word 'files' likely implies not.
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 opens with a specific action — running Oxlint, TypeScript, and optionally Biome diagnostics on a specific file list — and clearly distinguishes itself from check_project by framing this tool as the incremental variant. An agent can immediately understand what the tool does and how it differs from its nearest sibling.
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 instructs when to use this tool ('after editing specific files') and when to use the alternative ('use check_project for a full project scan'). It also gives concrete constraints on expected inputs, such as relative paths and no glob patterns, so an agent has actionable selection and invocation guidance.
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 | |
| engines | No | |
| message | No | |
| clusters | No | |
| truncated | No | |
| loopWarning | No | |
| totalIssues | No | |
| schemaVersion | No | |
| fileRuleChurnWarning | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, non-destructive), the description adds materially useful behavioral context: every call 're-runs all enabled engines with no caching,' paths default to the project root when omitted, and absolute/out-of-root paths 'return an error response.' It also rescans the tool's safety profile by stating 'Read-only; no files are written or modified,' which is consistent with the annotations — no contradiction.
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 concise sentences, each earning its place: purpose/engines, read-only guarantee, path constraints/default, and the sibling differentiation plus no-caching behavior. Nothing repeats the schema, no filler, and the most important information (what it runs and on what) is front-loaded.
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 only one optional parameter, read-only/idempotent annotations, and an output schema (so return values need no description), the definition covers all informational needs: scope, defaults, constraints, error cases, alternative tool routing, and runtime cost behavior. There is nothing relevant an agent would have to guess about calling this tool 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?
The schema has a single param 'paths' but 0% description coverage, so the description carries the entire burden. It adds crucial meaning: paths are 'one or more project paths,' default to the project root '.' when omitted, and must be relative — absolute or out-of-root paths return errors. That transforms what would be an opaque string array into a fully understandable parameter.
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 opens with a specific verb-resource pairing: 'Runs and clusters Oxlint and TypeScript (and optionally Biome) lint and type diagnostics for one or more project paths.' It names the exact diagnostics engines, explicitly differentiates from the sibling check_files, and clarifies the full-project scope, so an agent can distinguish it without opening any other tool.
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 gives explicit when-to-use guidance: 'Use this for a full project scan; use check_files instead for faster incremental checks after editing specific files.' It names the alternative sibling and the condition that selects it, which is the clearest possible routing for an agent.
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 |
|---|---|---|---|
| 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?
Annotations already declare read-only and idempotent behavior. The description goes further by exposing the exact error case when both or neither parameter is supplied, and the stale response and recovery path. It also explicitly states 'no files are written or modified', reinforcing and not contradicting 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?
Each sentence adds value: purpose, safety, parameter constraint, error behavior, and recovery path are all covered without unnecessary repetition. The description is structured with front-loaded actionable information.
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 tool with two parameters, oneOf constraints, and an output schema, the description covers everything needed to call it correctly: source of IDs, required exclusivity, error and stale states, resolution, and side-effect-free behavior. Nothing critical is omitted.
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%, but the description compensates by explaining that clusterId and issueId come from the most recent check_project or check_files result and that exactly one must be supplied. It doesn't fully define what an issueId vs clusterId represents or how they appear, but the connection to the previous check calls provides meaningful context beyond the raw 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 ('Returns the full issue list') and clearly delimits the input ('for either one cluster ID or one issue ID'). It also ties the tool to the results of check_project or check_files, making it easy to distinguish from its siblings even without checking 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?
The description explicitly places this tool after a check_project or check_files call and gives a concrete alternative when the result is stale: 'call check_project or check_files again to refresh.' This is a clear when-to-use and when-not-to-use distinction.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explaining the success output, error on invalid arguments, and lack of authentication. It also reinforces the read-only and side-effect-free behavior for the agent even if annotations were ignored.
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 three short, front-loaded sentences with no filler. It covers purpose, use context, output, errors, and authentication without repeating schema details.
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 trivial ping-style tool with rich annotations and an output schema, the description fully covers purpose, usage context, result, side-effect profile, error behavior, authentication, and read-only guarantee. Nothing material 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 tool has zero parameters, so the schema already establishes that no arguments are valid. The description adds useful confirmation that invalid arguments will result in an error response, which is beneficial for correct invocation.
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 uses a specific verb and resource ('Checks whether the Signalint MCP server is responsive') and names the literal output ('pong'). This clearly differentiates it from the sibling tools that check loop status, projects, files, and issue details.
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 explicitly recommends using the tool to verify the server is connected before running diagnostics. It provides clear context for when to call it, though it does not state alternatives to avoid or mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TranQui004/signalint'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
