Which integrations are available for this server?

Analyzes Make blueprint exports for silent-failure risks, provides explanations of findings, compares scenario versions, and lists recognized checks and protections. Analyzes n8n workflow exports for silent-failure risks, provides explanations of findings, compares workflow versions, and lists recognized checks and protections.

How do I use @still-running/mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@still-running/mcp analyze this n8n workflow for silent-failure risks" 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.

@still-running/mcp

by still-running-dev

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

@still-running/mcp

An MCP server that puts stillrunning.dev's workflow-analysis engine inside the tool you're already using to build or debug an n8n workflow or Make scenario — Claude Desktop, Claude Code, or Cursor.

The analysis itself is @still-running/health-check, pinned to an exact published version: static analysis of the exported workflow JSON, no execution, no network call, no storage. Same zero-network rule as the still-running CLI that package ships — this server just puts an MCP tool interface on top of the same engine, plus a couple of tools (explain_finding, compare_workflows, list_rules) that only make sense in an interactive, conversational tool.

Tools

`analyze_workflow`

Checks an n8n workflow or Make blueprint export for silent-failure risks. Takes workflow (a JSON string or an already-parsed object — either the whole exported file). Returns the full AnalysisResult: findings, what's protecting the workflow already, and a few counters.

`explain_finding`

Explains one of the four check types in general — what it looks for, why it matters, its severity range, known limitations. Takes checkId (the same string every finding from analyze_workflow carries: zero-write, credential-expiry, no-cadence, or error-handling). A finding's own ifItGoesQuiet/detail/howToCheck fields already explain that specific instance — this is for the check's general methodology instead.

`compare_workflows`

Runs analyze_workflow on two versions of the same workflow (e.g. before/after a fix) and reports which findings were added, removed, unchanged, or changed severity. Takes before and after, same shape as analyze_workflow's workflow argument. Findings are matched by check + node — documented as a heuristic in the tool's own output, not oversold as a perfect diff.

`list_rules`

Lists every check and every "protection" (the positive-signal side of the same analysis) the engine recognizes, with no input needed. Useful context to pull once at the start of a conversation rather than calling explain_finding four times.

Related MCP server: n8n Workflow Builder

Setup

Requires Node.js 18 or later. Every client below runs the server the same way — npx -y @still-running/mcp — Claude Desktop, Claude Code, and Cursor each just need to be told to run that command over stdio.

Claude Desktop

Edit your config file — quit Claude Desktop fully and reopen it afterward, a reload isn't enough:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "still-running": {
      "command": "npx",
      "args": ["-y", "@still-running/mcp"]
    }
  }
}

Claude Code

From the CLI, in a project you want it available in:

claude mcp add still-running -- npx -y @still-running/mcp

To make it available in every project instead of just this one, add --scope user:

claude mcp add --scope user still-running -- npx -y @still-running/mcp

Or edit the JSON directly — .mcp.json in a project root (commit it to share with your team), or ~/.claude.json for user scope:

{
  "mcpServers": {
    "still-running": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@still-running/mcp"]
    }
  }
}

Verify with claude mcp list.

Cursor

Global (all projects), ~/.cursor/mcp.json — or per-project, .cursor/mcp.json in the project root:

{
  "mcpServers": {
    "still-running": {
      "command": "npx",
      "args": ["-y", "@still-running/mcp"]
    }
  }
}

Local development

npm install
npm run build
npm run typecheck
npm test

npm run build compiles src/ to dist/ — the published package ships only dist/ and this README (see files in package.json).

Resources

stillrunning.dev
@still-running/health-check — the analysis engine this server wraps
Model Context Protocol

Available Tools

4 tools

analyze_workflowAnalyze WorkflowA

Checks an n8n workflow or Make blueprint export for silent-failure risks — steps that can finish "successful" while quietly doing nothing, credentials with no visible expiry, missing cadence, missing error handling. Static analysis only: reads the graph shape and node settings, never executes anything, never makes a network call, never sees or needs credentials. Tells you what CAN happen silently, never what DID — that distinction is load-bearing, see each finding's own text.

ParametersJSON Schema

Name	Required	Description	Default
`workflow`	Yes

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden, and it delivers: never executes, never makes a network call, never sees or needs credentials, and reports what CAN happen rather than what DID. This is exactly the behavioral disclosure an agent needs to avoid assuming side effects or secret access.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences with no filler: purpose and risk categories, behavioral constraints, then a critical semantic caveat. The structure front-loads the verb and resource while keeping the safety-critical distinctions visible.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter static analysis tool, the description covers input, safety boundaries, and the nature of the output ('findings'). It does not describe the finding structure or explicitly route to siblings, and there is no output schema to fill that gap, so it is not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description names the expected subject ('workflow or blueprint export') but does not compensate for the reported 0% schema coverage by explaining accepted formats such as raw JSON string vs. parsed object. The nested schema descriptions do document these forms, but the description itself adds no parameter-level guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Checks an n8n workflow or Make blueprint export for silent-failure risks'), then names concrete risk categories. It also draws a clear boundary with 'Static analysis only,' which separates it from execution-oriented or diagnostic tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use this when you need to inspect a workflow/blueprint for silent-failure risks without executing it. It does not explicitly name sibling alternatives or provide when-not-to-use conditions, so it falls just shy of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compare_workflowsCompare WorkflowsA

Runs analyze_workflow on two versions of the same workflow (e.g. before/after a fix) and reports which findings were added, removed, unchanged, or changed severity between them. Matches findings by checkId + nodeId — a heuristic (see the tool's own notes in the result), not a guaranteed-stable diff key.

ParametersJSON Schema

Name	Required	Description	Default
`after`	Yes	The later version of the workflow export.
`before`	Yes	The earlier version of the workflow export.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the disclosure burden. It reveals that matching is based on checkId+nodeId, is a heuristic rather than a stable diff key, and points to the tool's own notes in the result. It does not detail side effects or error behavior, but the comparison behavior is transparently described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The main purpose and output categories are front-loaded, and the caveat is placed at the end without obscuring the core behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is sufficient for an agent to invoke the tool correctly: both parameters are fully schema-documented, and the output categories are stated even without an output schema. The heuristic caveat and pointer to result notes strengthen completeness, though an explicit response shape or error-handling note would push it higher.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds important relational semantics: the two parameters must be versions of the same workflow, and the before/after ordering maps to a fix scenario, which the schema alone does not fully convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific operation (runs analyze_workflow on two versions and reports diff categories) and a specific object (the workflow versions). It clearly differentiates from sibling analyze_workflow, which would analyze a single workflow, by stating the comparison output explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the intended scenario: two versions of the same workflow, e.g. before/after a fix. This clearly implies single-workflow analysis should use analyze_workflow, though it does not explicitly name an exclusion or alternative condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

explain_findingExplain FindingA

Explains one of @still-running/health-check's check types in general — what it looks for, why it matters, its severity range, and known limitations. Takes a checkId (the same string every Finding from analyze_workflow carries), not a full Finding object — a Finding's own ifItGoesQuiet/detail/howToCheck fields already explain that specific instance; this is for the check's general methodology instead.

ParametersJSON Schema

Name	Required	Description	Default
`checkId`	Yes	The checkId from a Finding returned by analyze_workflow or compare_workflows.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It clearly discloses the tool's behavior—it provides an explanation of a check type with specific content areas (what it looks for, why it matters, severity range, limitations). It also states what the tool does not do (does not explain a specific instance). This conveys a read-only, informational nature. However, it does not explicitly mention output format or any operational constraints, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences and front-loaded with the core purpose. It efficiently packs the function, parameter nuance, and usage contrast without unnecessary fluff. It could be trimmed slightly (e.g., rephrasing the second sentence), but it is appropriately sized for the necessary disambiguation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter tool with no output schema or annotations, the description covers the purpose, parameter provenance, and when to use it. It explains what the returned explanation will contain (looks for, why it matters, severity, limitations) but does not describe the output's format or structure. Given the simplicity, this is nearly complete; a note on return format would make it perfect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes the checkId parameter as coming from analyze_workflow or compare_workflows. The description adds valuable extra meaning by clarifying that checkId is not a full Finding object and that it identifies a check type, not an instance. This goes beyond the schema's own description, earning a slightly above-baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it explains a check type in general, covering what it looks for, why it matters, severity range, and limitations. It explicitly contrasts with the per-instance explanation provided by a Finding's own fields, clearly distinguishing this tool from any sibling that might operate on individual findings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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 check's general methodology, not for a specific finding instance. It names the alternative (the Finding's ifItGoesQuiet/detail/howToCheck fields) and clarifies the expected input (a checkId from analyze_workflow). This gives the agent a clear decision rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_rulesList RulesA

Lists every check @still-running/health-check's analyze_workflow runs (what it looks for, why it matters, its severity range) and every "protection" it recognizes — the positive-signal side of the same analysis. No input needed. Call this before explain_finding if you want the full picture rather than one checkId at a time.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It plainly frames the tool as a list/read operation with a defined scope and no input parameters, which makes a read-only nature practically unambiguous. It stops short of explicitly stating 'no side effects' or describing the return format, which would have earned a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description packs the tool's scope, the data returned, and a usage hint into two concise sentences, with the most important information front-loaded and no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter listing tool with no output schema, the description covers purpose, scope, and when to call it relative to a sibling, leaving no ambiguity for an agent deciding to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has zero parameters, so coverage is trivially 100%. The description adds 'No input needed,' reinforcing that the call requires no arguments, which is more explicit than the empty schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Lists') and a precise resource: every check analyze_workflow runs plus every 'protection' it recognizes. It even details what each entry contains (what it looks for, why it matters, severity range), which unmistakably distinguishes it from siblings that execute or explain individual findings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs the agent to call this before explain_finding when a full picture is desired, and states 'No input needed.' This gives clear when-to-use guidance and an explicit alternative relationship with a sibling tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Sep 20, 2026
- First observedanalyze_workflow
- First observedcompare_workflows
- First observedexplain_finding
- First observedlist_rules

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.6/5.0

Scored 2026-09-20 22:10 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role: analyze_workflow inspects a single export, compare_workflows diffs two exports, explain_finding details one check type, and list_rules enumerates all checks. There is no functional overlap or ambiguity between them.

Naming Consistency5/5

All four tools follow a consistent verb_noun snake_case pattern: analyze_workflow, compare_workflows, explain_finding, list_rules. The only minor irregularity is singular vs plural on the noun, but this is natural and does not create inconsistency.

Tool Count5/5

Four tools is a well-scoped set for this server's purpose: one primary analysis operation, one comparison operation, one reference listing, and one explanation helper. Every tool serves a distinct function and none feel like filler.

Completeness5/5

The domain is static analysis of workflow exports for silent-failure risks, and the surface covers the full workflow: analyze a workflow, compare versions, list available checks, and explain individual check methodology. No obvious dead ends or missing operations for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

fde-agent A
io.github.minjikim89
Diagnose AI workflows for failure, security, and handoff risks — RED/AMBER/GREEN per node.
Monitoring Observability
12
FlowSentry A
io.github.vasilicasijarvis
Security scanner for n8n workflows + live MCP Trust-Check. 18 rules, OWASP mapped. Paid x402 API.
Penetration Testing Security Testing & QA Tools
1
NoCrash
io.nocrash
Know when your n8n workflows, URLs, and AI apps break, before your customers do.
Monitoring Observability
2
toolforte A
io.github.Toinedotcom
Exact IBAN, VAT, cron, regex answers; HTML/URL to hosted PDF or screenshot; agent memory; workflows.
Developer Tools
141

Related MCP Servers

n8n MCP Server
App Automation Developer Tools
Octavian-Labs
A
license
Not graded
quality
D
maintenance
Enables management of n8n workflow automations through natural language, supporting creation, execution, updates, and deletion of workflows, along with node discovery and execution status monitoring.
Updated a year ago (2025-09-30 01:50 UTC)
MIT
n8n Workflow Builder
App Automation Developer Tools Workplace & Productivity
danilonovaisv
A
license
Not graded
quality
D
maintenance
Enables AI assistants to manage n8n automation workflows through natural language commands, including creating, executing, monitoring, and organizing workflows with full CRUD operations and execution management.
Updated a year ago (2025-10-21 01:55 UTC)
95 npm
2
MIT
n8n Architect MCP Server
App Automation Workplace & Productivity Developer Tools
SrAndres629
F
license
Not graded
quality
D
maintenance
Enables orchestration and management of n8n workflows through tools for creating, updating, diagnosing failed executions, auto-fixing workflows, and installing community nodes.
Updated 9 months ago (2026-01-06 12:14 UTC)
-
n8n Workflow Builder
App Automation Developer Tools
Schimmilab
A
license
Not graded
quality
A
maintenance
Enables AI-powered building, optimization, debugging, and management of n8n workflows directly from Claude. Features workflow analysis, execution monitoring, security audits, drift detection, and intelligent error debugging with best practices guidance.
Updated a month ago (2026-09-01 19:00 UTC)
1
MIT