Provides an adapter to parse and summarize errors from Biome linting and formatting output.
Provides an adapter for the Bun test runner, parsing failing test names into compact diagnostics.
Provides an adapter to parse ESLint's stylish multiline output into grouped error reports.
Supports multiple PHP testing and static analysis tools: PHPUnit, PHPStan, Pest, and PHPSpec via dedicated adapters.
Provides an adapter to parse pytest failure output, extracting failed test names and traceback blocks.
Covered by the generic adapter, parsing file:line:col message output from Ruff linter.
Provides an adapter to parse Vitest test runner output into grouped error summaries.
Provides a JUnit XML adapter to parse test report XML files into error groups.
Click on "Deploy 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., "@Signal MCP run the test suite for the backend 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.
An MCP server that sits between an AI agent and your project's developer tooling — tests, linters, type checkers, builds — and compresses noisy output into compact, actionable diagnostics.
When an AI agent runs a test suite or linter directly, it receives hundreds or thousands of lines of raw output that flood the context window. Signal solves this by running the command, storing the full log on disk, parsing errors with a language-aware adapter, grouping duplicates by normalized fingerprint, and returning only a structured summary. The model sees one line per error group instead of the full log.
huge logs → grouped errors → compact diagnostic → fewer tokensAgent → run_check("backend_test")
→ Signal runs the command
→ stores full log on disk
→ parses errors with the configured adapter (auto-detected if not set)
→ groups duplicates by fingerprint
→ returns: N failing tests, M groups + raw_tail if nothing parsed
→ Agent fixes code
→ run_check again
→ diff_runs → "2 fixed, 1 persisting"
→ doneThe model never sees the full log unless it explicitly requests a slice with get_log_slice.
Related MCP server: projscan
npm install
npm run buildSignal runs each check through the system shell, so what works depends on the OS:
Platform | Status | Notes |
macOS | ✅ Full | commands run under |
Linux (Ubuntu, Arch, Fedora, …) | ✅ Full | same as macOS |
Windows + WSL | ✅ Full | WSL is a real Linux environment |
Windows (native) | ⚠️ Partial | commands run under |
On Windows native, simple commands work (npx vitest run, cargo test, go test ./..., pytest), but any command using POSIX shell syntax — single quotes, 2>&1, &&, bash -c '...', pipes — will fail because cmd.exe doesn't understand it. If your checks use Docker or bash wrappers, run Signal from WSL instead.
Run init inside a project to scaffold a signal.config.json from what's already there:
signal-mcp init # scan the current directory
signal-mcp init --dir path/to/project --out signal.config.jsoninit reads the project's own commands — it does not invent them:
Node (package.json) → maps the test, lint, typecheck, e2e, … scripts, using the right package manager (detected from the lockfile, walking up for monorepos)
Rust (Cargo.toml) → cargo test, cargo clippy
Go (go.mod) → go test ./...
Python (pyproject.toml) → pytest, ruff, mypy if present
Ruby (Gemfile) → rspec, rubocop
It won't guess Docker container names or multi-step pipelines — review the generated file and adjust those by hand. Adapters are auto-detected at run time, so init leaves them out.
Create a signal.config.json in your project root (see signal.config.example.json for reference):
{
"projects": {
"my-project": {
"root": "/path/to/my-project",
"checks": {
"test": {
"cmd": "npx vitest run"
},
"lint": {
"cmd": "pnpm exec biome check src --reporter json 2>&1"
}
}
}
}
}The adapter field is optional — Signal auto-detects the right adapter from the command (vitest, pytest, cargo test, eslint, etc.). Set it explicitly only when auto-detection would be wrong.
node dist/index.js install --config /path/to/signal.config.jsonOr add it manually to your ~/.claude.json:
{
"mcpServers": {
"signal": {
"type": "stdio",
"command": "node",
"args": ["/path/to/signal-mcp/dist/index.js"],
"env": {
"SIGNAL_CONFIG": "/path/to/signal.config.json"
}
}
}
}Signal auto-detects the active project from the working directory — it matches any subdirectory of a configured project root.
Signal watches signal.config.json for changes and reloads it automatically — no need to restart the MCP server after adding or modifying a check. You'll see [signal-mcp] config reloaded in the server logs when it picks up a change.
Use ${VAR} in any string field of signal.config.json to avoid hardcoding machine-specific values like Docker container names or paths:
{
"projects": {
"my-project": {
"root": "/path/to/my-project",
"checks": {
"test": {
"cmd": "docker exec ${APP_CONTAINER} pytest"
}
}
}
}
}Define the variables in the MCP server registration so each developer sets their own values without touching the shared config:
{
"mcpServers": {
"signal": {
"type": "stdio",
"command": "node",
"args": ["/path/to/signal-mcp/dist/index.js"],
"env": {
"SIGNAL_CONFIG": "/path/to/signal.config.json",
"APP_CONTAINER": "my-app-container-1"
}
}
}
}If a variable is not set, the literal ${VAR} is kept unchanged. Variables without braces ($VAR) are not interpolated.
Instead of listing every variable in the MCP registration, drop a signal.env file next to your signal.config.json:
# signal.env — machine-specific, gitignored
APP_CONTAINER=my-app-container-1
NIXON_CONTAINER=nixon_devcontainer-app-1Signal auto-loads signal.env on startup. It never overwrites variables already set in the environment, so anything defined in the MCP registration still wins. Point to a different file with SIGNAL_ENV_FILE=/path/to/.env.
Tool | Description |
| List all configured checks for the current project |
| Run a check and return the compact summary directly — no polling needed |
| Run multiple checks in parallel and return all summaries at once |
| Start a check asynchronously. Returns |
| Start multiple checks in parallel asynchronously. Returns all |
| Get the status of a running or finished check |
| Compact diagnostic: error groups with file/line occurrences |
| Compare two runs by fingerprint — shows what was fixed, what's new, what persists |
| Read any line range from the raw log when more context is needed |
| List recent runs, optionally filtered by check name |
| Re-run a single failing test with verbose flags using the group fingerprint |
1. list_checks → discover available checks
2. run_check { name: "test" } → summary returned directly
3. (fix the errors)
4. run_check { name: "test" } → run again after the fix
5. diff_runs { check: "test" } → verify what changed
6. get_log_slice { run_id, stream } → zoom into raw log if neededRun frontend and backend checks simultaneously:
run_checks { names: ["frontend_test", "backend_test"] } → both run in parallel, one summary per checkFor long-running checks (E2E, integration):
1. start_check { name: "e2e" } → run_id returned immediately
2. get_run_status { run_id } → poll until status != "running"
3. get_run_summary { run_id } → read the compact diagnosticget_run_summary and run_check accept these optional parameters:
Option | Description |
| Max error groups to return (default 5) |
| Max occurrences per group (default 5) |
| Filter by |
|
|
run_check also accepts:
Option | Description |
| If the check exceeds this duration, return |
When a check fails but the adapter parses zero errors (unrecognized output format), the summary automatically includes a raw_tail field with the last 30 lines of output — so the agent always has something actionable without needing get_log_slice.
For checks where order matters (clean → prepare → test):
{
"checks": {
"full": {
"steps": [
{ "name": "clean", "cmd": "rm -rf var/cache/*", "timeout_ms": 30000 },
{ "name": "prepare", "cmd": "bin/prepare-test-db", "timeout_ms": 120000 },
{ "name": "test", "cmd": "vendor/bin/behat", "timeout_ms": 300000 }
],
"fail_fast": true
}
}
}Each step gets its own adapter (auto-detected from cmd). get_run_summary returns which step failed and grouped errors from that step.
Signal auto-detects the adapter from the command — no need to set adapter explicitly for common tools.
Adapter | Works with | Auto-detected from |
| Vitest |
|
| Jest |
|
| pytest — parses |
|
| Mocha |
|
| PHPUnit failure/error sections |
|
| PHPStan |
|
| Behat "Failed scenarios:" block |
|
| Pest PHP |
|
| PHPSpec failure blocks with spec class and line |
|
| RSpec |
|
| ESLint stylish multiline output |
|
| Biome |
|
| RuboCop |
|
| Bun test runner |
|
| Go |
|
| Rust |
|
| Rust |
|
| Playwright numbered failure blocks with browser tag |
|
| Cypress |
|
| Structured JSON logs | — |
| JUnit XML reports | — |
| Any tool emitting | fallback |
Adding an adapter is ~30–50 lines + tests. The interface is:
parse({ stdout, stderr, projectRoot }): ParsedError[]For a tool with a format no adapter covers, set a pattern — a regex with named groups. It overrides the adapter entirely:
{
"cmd": "my-custom-tool",
"pattern": "ERROR \\[(?<file>[^:]+):(?<line>\\d+):(?<col>\\d+)\\] (?<message>.+)"
}Supported named groups: file, line, col (or column), message, symbol. Without named groups, the first capture group (or the whole match) becomes the message. Each matching line is one error.
ignore_patternsSome tools flood the output with deprecation warnings or info lines. ignore_patterns (an array of regexes) strips matching lines before parsing:
{
"cmd": "npx vitest run",
"ignore_patterns": ["DeprecationWarning", "ExperimentalWarning", "node:internal"]
}Both pattern and ignore_patterns work on single-command checks and per-step in multi-step pipelines.
Errors are grouped by a 12-character SHA1 fingerprint:
If a symbol was extracted (test name, function name): type:sym:<symbol>
Otherwise: type:msg:<normalized_message> — quoted strings → <str>, paths → <path>, numbers → N
Errors that differ only in line numbers, paths, or quoted values collapse into one group. diff_runs compares fingerprints between runs to identify fixed vs. new vs. persisting errors.
.signal/runs/<check>_<timestamp>_<random>/
├── stdout.log
├── stderr.log
├── meta.json
└── steps/ # only for multi-step runs
├── 1-clean/
├── 2-prepare/
└── 3-test/run_id is validated against ^[a-zA-Z0-9_-]+$ — path traversal is rejected before any disk I/O.
Runs are cleaned up automatically after each execution: the last 20 runs per check are kept, older ones are deleted.
Field | Type | Default | Description |
| string | required | Shell command to run |
| string | auto-detected | Parser adapter name — omit to auto-detect from |
| number |
| Max execution time |
| string | project root | Working directory |
| object | — | Extra environment variables |
| string | — | Strip this prefix from file paths in errors (useful for Docker paths) |
| string | — | Command to run after a failure to capture extra context |
| string | — | Human-readable description shown in |
| string | — | Custom regex with named groups ( |
| string[] | — | Regexes to strip matching lines before parsing (filter deprecation warnings, noise) |
Field | Type | Default | Description |
| array | required | Ordered list of steps, each with per-step fields above |
| boolean |
| Stop pipeline on first failing step |
| string | — | Human-readable description shown in |
npm test # run all tests (vitest)
npm run typecheck # tsc --noEmit
npm run build # compile to dist/Tests are colocated under tests/. Each adapter has its own .test.ts file.
MIT
Unavailable: signal-mcp is not configured for this project. Call it to see why.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden, and it does reveal the key trait: the tool is not configured and is unavailable. However, it does not describe what happens when called, such as whether it returns an error, a diagnostic message, or an empty result.
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 a single front-loaded sentence that communicates the essential status and a suggested next action. There is no wasted text, and for a zero-parameter stub this is appropriately concise.
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 an unavailable tool with no parameters and no output schema, the description is complete enough: it tells the agent the tool cannot perform its normal function and what to do next. It intentionally omits details about diffing runs, which is consistent with the tool's unavailable state.
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 zero parameters and 100% description coverage, so there is nothing for the description to add about parameter meaning. The baseline of 4 is appropriate here.
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 clearly states the tool is unavailable, but it never explains what diff_runs actually does. An agent cannot tell what operation the tool performs or how it differs from siblings like run_check or get_run_summary, so the core purpose is missing.
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 tells the agent to call the tool to see why it is unavailable, which is explicit for the failure path, but it provides no guidance about normal use or when to choose alternatives. The reason is already stated in the description, making the 'call it to see why' instruction somewhat redundant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unavailable: signal-mcp is not configured for this project. Call it to see why.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It honestly discloses that the tool is unavailable and that invoking it will provide the reason, which is a meaningful behavioral trait. However, it does not specify the exact response or error format, leaving some uncertainty.
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 one short sentence with no filler, and the key action is front-loaded. It is concise and readable, although this conciseness comes at the cost of substantive functional 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 zero-parameter stub with no output schema, the description tells the caller what happens when invoked and why it happens. Yet it does not explain the tool's original purpose or how it relates to sibling tools, leaving an agent unable to judge when the tool would be relevant beyond diagnostics.
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 contains zero parameters and has 100% schema coverage, so the description has no parameter-documentation burden. The baseline of 4 applies; the description's implication that the tool can be called without arguments is consistent with the empty 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 only states that the tool is unavailable and that calling it will reveal why; it never says what get_log_slice is meant to do, such as retrieving a slice of logs. It reads as a status note rather than a tool-purpose statement and offers no differentiation from sibling run/check tools.
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 only usage guidance is the imperative to call the tool to see why it is unavailable. There is no explanation of when this tool should be used relative to the listed siblings, and no alternative tools or exclusion conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unavailable: signal-mcp is not configured for this project. Call it to see why.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose the key fact that the tool is unavailable and the reason, which is more than a generic stub. But it does not describe what the call returns, whether it errors, or what side effects, if any, occur.
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 a single front-loaded warning followed by a concrete next step. There is no wasted text, no repetition of schema fields, and it remains scannable for an agent.
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 an unavailable, parameterless stub, the description is mostly sufficient: it tells the agent not to expect normal functionality and how to learn more. However, it does not describe the expected response shape or point to a working alternative among the siblings, leaving some context 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 input schema is empty and schema description coverage is 100%, so there are no parameter semantics to document. The zero-parameter baseline of 4 applies; the description adds no parameter information, but none is 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 clearly communicates that the tool is currently unavailable due to signal-mcp not being configured, so an agent understands it is not a functional status-retrieval tool. However, it does not describe the underlying operation or distinguish it from sibling run-related tools, leaving the purpose as a diagnostic stub rather than a normal tool definition.
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 text gives an explicit diagnostic use case: 'Call it to see why.' It also implicitly tells the agent not to expect normal functionality. However, it does not name alternatives or clarify when to prefer siblings like list_runs or get_run_summary, so the usage guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unavailable: signal-mcp is not configured for this project. Call it to see why.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is unavailable, but not what happens when invoked—error message, exception, empty result, or otherwise. With no annotations, the description carries the full burden and leaves the side effects opaque.
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?
Two short sentences with the unavailability message front-loaded. It is compact and free of padding, though the second sentence is of questionable practical value.
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 that presumably would return run summaries, the description omits the core purpose, behavior, and expected output. Even with no parameters and no output schema, an agent has no way to understand what get_run_summary is for, making the context incomplete.
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 fully covers parametric information. The description adds no parameter details, but none are required; the baseline for 0 params is appropriate.
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 does not state what get_run_summary does; it only reports that signal-mcp is not configured. The name implies fetching a run summary, but the description never confirms that, so an agent cannot distinguish it from siblings like get_run_status or list_runs.
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?
No guidance on when to use this tool versus alternatives. The only instruction, 'Call it to see why,' is a diagnostic prompt rather than a use case and does not connect to the tool's apparent purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unavailable: signal-mcp is not configured for this project. Call it to see why.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It reveals only that the tool is unavailable and provides no insight into what it would do, what side effects it might have, or what output it produces.
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 text is extremely short but fails to be concise in a useful way; it is under-specified. Conciseness should preserve essential information, but here the essential information (what the tool does) is entirely absent.
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 zero-parameter tool, a description should at least name the resource or action it performs. This description only explains that the tool is not configured, leaving the agent completely in the dark about its intended function. It is not complete even for a diagnostic context.
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 zero properties, so there are no parameters to document. While a baseline of 4 might apply for zero-param tools, this description adds no semantic value at all—it merely repeats unavailability. The agent gets no understanding of what the tool would require or return.
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 does not state what the tool does; it only declares unavailability. This is an error message, not a definition of purpose. An agent cannot infer the tool's function from "Unavailable: signal-mcp is not configured for this project."
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?
No guidance is given on when to use this tool or how it relates to siblings. The instruction "Call it to see why" is not a usage guideline but a diagnostic suggestion, and it does not clarify when this tool would be the correct choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unavailable: signal-mcp is not configured for this project. Call it to see why.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose that signal-mcp is not configured and that calling the tool reveals the reason. However, it doesn't explain what the call returns or whether any actual list_runs functionality is present.
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 two short sentences with no filler, and the important status is front-loaded. Every word earns its place.
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 named list_runs with no output schema, the description fails to explain what a successful invocation would look like or what to do instead. It only instructs the agent to call it to see why, leaving the actual result and any alternative workflow unspecified.
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 input schema has zero parameters and 100% schema coverage, so no parameter-level explanation is needed. The description's lack of parameter detail is not a gap.
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 never states that list_runs lists runs or what the tool actually does; it only reports an unavailability status. This is effectively an error message rather than a functional tool definition, leaving an agent to infer the real purpose from the name.
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 only guidance is 'Call it to see why,' which tells an agent to invoke the tool to discover the reason for the unavailability. It does not specify when to choose this tool over siblings such as list_checks or get_run_status, and offers no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unavailable: signal-mcp is not configured for this project. Call it to see why.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal a key trait—the tool is unavailable because signal-mcp is not configured—and suggests that calling it produces an explanation. But it doesn't describe actual behavior if the tool were available, what the call returns, or side effects.
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 one short sentence and front-loads the key unavailability message. However, it is under-specified as a tool definition; the brevity comes at the cost of conveying the tool's actual function, so it reads more like a status stub than a useful description.
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?
Although the tool has no parameters and no output schema, the definition still fails to explain what rerun_failed does or how an agent should treat it when trying to rerun failed items. The description only signals unavailability, which is not enough context to support correct tool selection and invocation.
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 and the schema is trivially complete. No parameter documentation is needed, and the description does not need to compensate for any schema gaps. This matches the baseline for a zero-parameter tool.
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 is an availability notice rather than a functional definition. It does not state that rerun_failed reruns failed runs/checks or what its actual operation is; it only says it is unavailable and can be called to see why. This is not a tautology, but it leaves the tool's true purpose undefined.
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 minimal guidance: the tool is unavailable, and calling it reveals why. However, it provides no context about when to use rerun_failed versus sibling tools like run_checks, list_runs, or get_run_status, and it offers no alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unavailable: signal-mcp is not configured for this project. Call it to see why.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose the key trait that the tool is unavailable and why, and implies that calling it returns the reason. However, it stops short of explaining the exact return format, whether it raises an error, or any side effects.
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 two short, front-loaded sentences with no wasted words. The state ('Unavailable'), the cause ('signal-mcp is not configured'), and the intended action ('Call it to see why') are all conveyed efficiently.
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 zero-parameter diagnostic stub with no output schema, the description is largely complete: it tells the agent what is wrong, why, and what happens if the tool is called. It could add more detail about the exact response shape, but that is a minor gap for such a simple tool.
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 and the schema has 100% coverage for those zero parameters, so there is no parameter meaning to add. The description does not need to compensate for any missing schema information.
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 clearly states that the tool is currently unavailable and that invoking it will reveal why. It goes beyond a simple restatement of the name, though it does not describe a normal 'run check' operation or differentiate itself from sibling tools.
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 context: the tool is unavailable because signal-mcp is not configured, and it tells the agent to call it 'to see why.' This is clear guidance for the diagnostic use case, though it does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unavailable: signal-mcp is not configured for this project. Call it to see why.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the tool's unavailability but does not say what happens on invocation—whether it returns an error, a message, or nothing—nor what the tool would do if configured, leaving key behavioral traits undisclosed.
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 a single, front-loaded sentence with no filler. Both the unavailability notice and the call instruction earn their place, making it appropriately sized for what it conveys.
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 no-parameter stub, the description is largely complete: it states the tool is unavailable, gives the reason, and provides an explicit next action. The main gap is that it does not describe the invocation result or normal configured behavior, but the simplicity of the stub makes this a minor omission.
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?
There are zero parameters, so the empty input schema fully covers the invocation surface and no parameter documentation is needed. The instruction to call the tool is consistent with a parameterless call, making the description sufficient on this dimension.
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 communicates a status—'Unavailable: signal-mcp is not configured'—and instructs the agent to call the tool to see why, but it never states the tool's actual function of running checks. It is not a tautology, but the operational purpose is vague and undifferentiated from siblings like run_check and start_checks.
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 only guidance is 'Call it to see why,' which tells the agent when to invoke it for an explanation but provides no conditions for preferring it over alternatives or when not to use it. No exclusions or alternative routing are mentioned despite many closely related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unavailable: signal-mcp is not configured for this project. Call it to see why.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It discloses that the tool is unavailable due to missing configuration and that calling it will surface the reason, but it does not say whether the call returns an error, a message, or configuration details. This is partial transparency at best.
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 a single sentence with the key status front-loaded: 'Unavailable'. Every word contributes to the agent's understanding, and there is no fluff or redundant restatement of the tool name.
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 zero-parameter stub tool, the description is nearly sufficient: it tells the agent the tool is not configured and directs it to call for the reason. However, with no output schema, the agent is left guessing what the call will return. The lack of sibling differentiation is also noticeable, though the unavailability statement reduces that need.
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 input schema has zero parameters, so there are no parameter semantics for the description to add. The baseline for a parameterless tool is 4, and nothing here is missing in that regard.
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 identifies this as a diagnostic stub: signal-mcp is not configured and calling it reveals why. This is more specific than the bare name and not a tautology, but it never states what the tool actually does or what a successful invocation accomplishes. The purpose is implied rather than clearly defined.
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?
There is no guidance on when to use start_check versus siblings like start_checks or run_check. The sentence implies the only reason to call it is to discover why it is unavailable, but it provides no explicit context, exclusions, or alternatives. This is below the minimum viable level of usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unavailable: signal-mcp is not configured for this project. Call it to see why.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is unavailable due to missing signal-mcp configuration and that calling it will provide an explanation. This is useful, but it doesn't explicitly state what happens when called (e.g., error message, log). It adds some transparency but lacks rich behavioral detail.
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?
A single sentence that is front-loaded with the key fact 'Unavailable' and wastes no words. It immediately communicates unavailability and points to the diagnostic action.
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 tool's name and siblings, an agent would expect a tool that starts checks. The description only explains unavailability but does not describe the intended function, return behavior, or relationship to other check tools. This is insufficient for understanding normal operation.
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 description need not add parameter semantics. The empty schema already provides complete coverage, and the baseline for 0 params is 4.
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 clearly states that the tool is unavailable and that calling it will reveal why, which is a specific meta-purpose. However, it does not describe what the tool would normally do (e.g., starting checks) nor differentiate it from sibling tools like start_check or run_checks. The purpose is vague regarding the tool's intended functionality.
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention using start_check or run_checks instead, nor does it state any exclusions. The only hint is that it is unavailable, which implies it should not be relied on, but this is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0diff_runsget_log_sliceget_run_statusget_run_summarylist_checkslist_runsrerun_failedrun_checkrun_checksstart_checkstart_checksScored across 11 tools
All tool descriptions are identical unavailable messages, so disambiguation relies solely on names. start_check/start_checks and run_check/run_checks are ambiguous in scope, and start vs. run overlap heavily, making it difficult for an agent to choose the correct intent.
Tool names consistently use lowercase snake_case with a verb_noun pattern (list_checks, get_run_status, diff_runs). Minor inconsistencies exist between singular/plural variants (start_check vs. start_checks) and synonymous verbs (start/run), but the overall pattern is predictable.
11 tools is within the ideal 3-15 range for a check/run management server. Each name suggests a distinct operational purpose, and the count feels appropriately scoped without redundancy or bloat.
The tool surface covers the core lifecycle of checks and runs: listing, starting, running, status, summaries, diffs, logs, and reruns. The only notable gap is the absence of a cancel/stop or delete operation, which is a minor missing action for a management toolset.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
