Signalint es un servidor MCP local para diagnósticos de JavaScript y TypeScript. Ejecuta
Oxlint, TypeScript y, opcionalmente, Biome; almacena en caché las comprobaciones sin cambios; agrupa problemas
repetidos; y advierte cuando el mismo diagnóstico desaparece y reaparece repetidamente.
El historial de bucles se restaura desde entradas válidas de .signalint/session.jsonl cuando el servidor
MCP se reinicia; las líneas malformadas o truncadas por un bloqueo se omiten.
Listado en:
Registro oficial de MCP (listado de API)
Cuando un agente de codificación solicita diagnósticos en un proyecto, las salidas sin procesar del compilador y del linter inundan rápidamente la ventana de contexto con errores repetitivos en varios archivos. Signalint normaliza los problemas y los agrupa por causa raíz antes de devolver una respuesta acotada y ordenada por prioridad:
[
{
"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
}El agente recibe un resumen conciso con grupos ordenados por prioridad e identificadores de problemas de muestra. Cuando se necesita un detalle más profundo para un grupo o problema específico, el agente llama a get_issue_detail sin volver a ejecutar el escaneo de todo el proyecto.
Related MCP server: agent-workspace-mcp
Node.js 20.19 o posterior en la línea Node 20, o Node.js 22.12 o posterior
Un proyecto de JavaScript o TypeScript; las comprobaciones de TypeScript requieren un tsconfig.json
pnpm 11.9.0 para el desarrollo del código fuente
Instale Signalint en el proyecto que debe comprobar:
npm install --save-dev signalint-mcpEjecute el comando de configuración desde la raíz de ese proyecto. Detecta la configuración de TypeScript, Oxlint y
Biome, escribe signalint.config.json y ofrece actualizar una configuración MCP cercana de
Claude Code, Cursor, Codex CLI o Antigravity:
npx signalint-mcp initSi no se puede seleccionar ningún cliente MCP de forma segura, el comando imprime fragmentos de configuración exactos para copiar. TypeScript se habilita solo cuando existe un tsconfig.json raíz; Biome se habilita cuando existe su configuración; Oxlint es el respaldo cuando no se detecta ningún linter configurado. Para configurar Signalint manualmente, cree signalint.config.json:
{
"engines": {
"oxlint": true,
"tsc": true,
"biome": false
},
"ignore": ["node_modules/**", "dist/**", ".signalint/**"],
"timeoutsMs": {
"oxlint": 30000,
"tsc": 120000,
"biome": 30000
}
}Ejecute esto desde el proyecto comprobado. El ámbito de proyecto escribe un .mcp.json compartible:
claude mcp add --scope project signalint -- npx --no-install signalint-mcp
claude mcp get signalintEn Windows nativo, envuelva npx como lo requiere Claude Code:
claude mcp add --scope project signalint -- cmd /c npx --no-install signalint-mcp
claude mcp get signalintReinicie Claude Code si ya estaba abierto. Pídale que llame a la herramienta ping de Signalint,
luego llame a check_project con { "paths": ["."] }.
Consulte la documentación de MCP de Claude Code para obtener detalles sobre el ámbito y la resolución de problemas.
Cree .cursor/mcp.json en el proyecto comprobado:
{
"mcpServers": {
"signalint": {
"command": "npx",
"args": ["--no-install", "signalint-mcp"]
}
}
}En Windows nativo use "command": "cmd" y
"args": ["/c", "npx", "--no-install", "signalint-mcp"]. Abra la configuración de MCP de Cursor,
habilite signalint y llame a ping seguido de check_project.
Consulte la documentación de MCP de Cursor para conocer las ubicaciones de configuración y los controles de estado.
La aplicación de escritorio de ChatGPT, Codex CLI y la extensión del IDE comparten un único
archivo de configuración. El comando de adición rápida escribe en ~/.codex/config.toml
(global) automáticamente:
codex mcp add signalint -- npx --no-install signalint-mcpPara una configuración de ámbito de proyecto (solo proyectos de confianza), agregue a
.codex/config.toml en la raíz del proyecto:
[mcp_servers.signalint]
command = "npx"
args = ["--no-install", "signalint-mcp"]En Windows nativo, use cmd y pase npx como argumento:
[mcp_servers.signalint]
command = "cmd"
args = ["/c", "npx", "--no-install", "signalint-mcp"]Consulte la documentación de MCP de Codex
para conocer todas las opciones de configuración, incluyendo cwd, env y la configuración de aprobación
por herramienta.
Antigravity usa su propio archivo de configuración MCP. La ruta que se ha
verificado mediante dogfooding en Windows es:
%USERPROFILE%\.gemini\antigravity\mcp_config.json.
El comando init puede actualizar este archivo después de la confirmación. La configuración
equivalente de Windows es:
{
"mcpServers": {
"signalint": {
"command": "cmd",
"args": ["/c", "npx", "--no-install", "signalint-mcp"],
"cwd": "<absolute-path-to-your-project>"
}
}
}En macOS o Linux, use "command": "npx" y
"args": ["--no-install", "signalint-mcp"]. Reinicie o vuelva a conectar Antigravity
después de actualizar la configuración.
Nota sobre las variantes del producto Antigravity: Antigravity se ha dividido en productos
separados (IDE, CLI, SDK). Cada variante puede usar una ruta de configuración diferente: la
ruta del IDE anterior es la confirmada como funcional; otras variantes pueden usar
~/.gemini/config/mcp_config.json o un .agents/mcp_config.json de ámbito de proyecto.
Consulte antigravity.google/docs/mcp para
obtener la lista autoritativa por producto.
Los shims .cmd de Windows creados por npm link pueden exponer una ruta de unión a Node. Si
signalint-mcp termina con un error de inicialización/EOF o signalint stats sale con
código 0 pero no imprime nada, omita el shim con las rutas de punto de entrada compiladas:
node C:\absolute\path\to\Signalint\dist\src\index.js
node C:\absolute\path\to\Signalint\dist\src\cli.js statsLas compilaciones actuales canonizan las rutas vinculadas antes de decidir si iniciar, pero la invocación directa de Node sigue siendo el respaldo confiable para compilaciones antiguas o configuraciones inusuales de npm.
engines.oxlint, engines.tsc y engines.biome son booleanos. Los valores predeterminados son
Oxlint y tsc habilitados, Biome deshabilitado. Las claves de motor omitidas conservan esos valores predeterminados.
Las claves desconocidas y los valores con tipo incorrecto fallan con un error de configuración.
ignore es una matriz de globs relativos al proyecto. Signalint admite *, ** y
?, normaliza los separadores de Windows y excluye las rutas y los diagnósticos solicitados que coinciden.
Debido a que tsc es un motor de programa completo, aún recibe el programa completo de
tsconfig.json cuando se invoca; las rutas de TypeScript ignoradas no activan una
ejecución incremental de check_files y sus diagnósticos se eliminan de la respuesta.
La configuración nativa del motor permanece en archivos nativos. El hash de caché v1 reconoce
.oxlintrc, .oxlintrc.json, oxlint.json, tsconfig.json, biome.json
y biome.jsonc raíz. Cambiar uno invalida la caché del motor relacionado. Otras fuentes
válidas—incluyendo .oxlintrc.jsonc, configuraciones extendidas y configuraciones de paquetes anidados—
no forman parte del hash de caché v1; borre .signalint/ después de cambiar una de ellas.
timeoutsMs establece plazos de subproceso de enteros positivos en milisegundos. Los valores predeterminados son
30 segundos para Oxlint, 120 segundos para tsc y 30 segundos para Biome. Un motor con tiempo de espera agotado
y sus procesos secundarios se terminan. En la respuesta de comprobación del esquema 1.1, ese motor
tiene { "status": "error", "message": "tsc did not complete within 120s" }
bajo engines, mientras que los diagnósticos de los motores completados se conservan.
Signalint admite solo proyectos de JavaScript y TypeScript.
Los motores integrados son Oxlint, TypeScript y Biome; v1 no admite motores personalizados arbitrarios.
Signalint informa si un problema tiene una corrección estructurada, pero v1 no aplica correcciones.
Signalint no es un escáner SAST ni de seguridad.
Aún no hay una extensión de IDE; las integraciones usan MCP o el cliente de línea de comandos.
La detección de bucles está deliberadamente limitada a firmas de problemas de lint, tipo y prueba; no detecta bucles generales de conversación de agentes.
El adaptador de tsc requiere un tsconfig.json en la raíz del proyecto. Los monorepos deben
proporcionar una configuración raíz de estilo solución usando Referencias de Proyecto de TypeScript;
Signalint no descubre automáticamente configuraciones de paquetes independientes.
check_files trata solo los archivos pasados explícitamente a esa llamada como relevantes para
la invalidación de la caché de TypeScript. Si el archivo A cambia pero se omite mientras se comprueba el archivo B sin cambios,
y B depende de A, Signalint puede reutilizar un resultado de tsc obsoleto. Incluya
cada archivo de dependencia cambiado o ejecute check_project; la invalidación basada en el grafo de dependencias
no está implementada en v1.
ping comprueba que el servidor local esté conectado y devuelve pong.
check_project acepta { "paths": ["."] } opcional y devuelve diagnósticos agrupados.
check_files acepta { "files": ["src/file.ts"] } y usa caché incremental.
get_issue_detail acepta exactamente un clusterId o issueId de la última
comprobación exitosa y devuelve sus problemas completos, o una respuesta status: "stale".
get_loop_status devuelve las firmas de problemas actualmente marcadas como oscilantes.
Los artefactos de caché y sesión se escriben bajo .signalint/ y no deben confirmarse.
Ejecute la misma comprobación de proyecto sin un cliente MCP:
npx --no-install signalint check .Después de que las comprobaciones MCP se hayan acumulado en .signalint/session.jsonl, imprima el resumen de medición de la Fase 6:
npx --no-install signalint statsEl informe incluye la reducción promedio de carga útil JSON de sin procesar a agrupado, la tasa de aciertos de caché de archivos de motor, la latencia promedio y máxima de comprobación, y el número de firmas de problemas distintas que activaron advertencias de bucle. Una búsqueda de archivos de motor cuenta cada motor habilitado por separado, por lo que un archivo TypeScript cambiado puede fallar una vez para Oxlint y una vez para tsc. La latencia cubre el trabajo del manejador desde la entrada de la herramienta MCP hasta el trabajo de motor/caché, la agrupación y la evaluación de bucles; excluye el anexo de telemetría y el transporte stdio. Las estadísticas incluyen el registro de sesión activo y su copia de seguridad rotada .1, con su superposición retenida contada una vez. Las comprobaciones limpias con carga útil sin procesar cero se excluyen del promedio de reducción, y las comprobaciones más antiguas con métricas faltantes se siguen contando sin contribuir al agregado no disponible.
El CLI sale con código 1 cuando se encuentran problemas. Dos banderas admiten el uso en CI:
--format github imprime una anotación de GitHub Actions
(::error file=...,line=...,col=...::message o ::warning ...) por problema
en lugar de JSON, y --fail-on-priority <N> sale con código no cero solo si la
prioridad de un grupo es igual o inferior a N en lugar de hacerlo ante cualquier problema encontrado.
Para ejercitar una llamada real de MCP check_project contra el paquete instalado,
ejecute:
node node_modules/signalint-mcp/examples/check-project.mjs .action.yml en la raíz del repositorio envuelve signalint check como una acción
compuesta para CI. Instala Node, instala signalint-mcp desde npm y ejecuta
la comprobación con --format github para que los problemas aparezcan como anotaciones en línea en
el diff de la solicitud de extracción:
- uses: TranQui004/signalint@main
with:
fail-on-priority: "3"fail-on-priority tiene como valor predeterminado 5, lo que hace fallar el trabajo ante cualquier problema encontrado,
coincidiendo con el comportamiento predeterminado de signalint check sin la bandera. Los valores más bajos
solo hacen fallar el trabajo cuando un grupo es al menos tan urgente: la prioridad 1 es un
error sin corrección estructurada, y la prioridad aumenta hacia 5 a medida que los problemas
se vuelven más corregibles o más sistémicos (consulte scorePriority en
src/cluster/clusterEngine.ts).
pnpm 11.9.0 es el administrador de paquetes canónico para el desarrollo del código fuente. El repositorio
confirma pnpm-lock.yaml, declara pnpm en package.json y usa pnpm en CI.
pnpm install --frozen-lockfile
pnpm lint
pnpm typecheck
pnpm test
pnpm buildSi un shim global de npm no puede encontrar npm-cli.js, compile directamente con node node_modules/typescript/bin/tsc -p tsconfig.json.
Antes de preparar una versión, use npm pack --dry-run y verifique el tarball empaquetado
en un proyecto limpio. La publicación requiere aprobación explícita de la versión.
Consulte SECURITY.md para conocer el aviso actual de auditoría de npm, su alcance de tiempo de ejecución evaluado y las condiciones que requieren una reevaluación.
Sitio web — descripción general, documentación y ejemplos en vivo.
ARCHITECTURE.md — cómo encajan las capas y qué hace cada módulo.
CONTRIBUTING.md — configuración de desarrollo, verificación y solicitudes de extracción.
AGENTS.md — estándares de codificación para este repositorio.
SECURITY.md — modelo de amenazas, límites de confianza y estado de auditoría.
CHANGELOG.md — cambios notables por versión.
docs/history/ — plan de compilación original y registro de auditoría previo al lanzamiento.
Signalint está disponible bajo la Licencia MIT.
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
