Allows static auditing of exported n8n workflow JSON, checking for missing or duplicate node names/IDs, broken connections, and missing webhook paths.
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., "@Automation Auditor MCP audit this n8n export for broken connections"
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.
One MCP server, several real automation export formats. Built and maintained by Ahmad Yar.
This project is a starter implementation. It has not been published to PyPI or registered in the MCP Registry, and its MCP transport has not yet been end-to-end tested against a host. It performs read-only static checks on supplied text; it never reads your repo on its own, contacts automation accounts, runs JS, or connects to API endpoints.
Platform | Input | Checks | Boundary |
n8n | Exported workflow JSON | Missing/duplicate node names or IDs, broken connections, missing webhook paths | Static structure; no credential or live execution checks |
Dify | Exported workflow DSL YAML/JSON | Missing or duplicate node IDs, broken edges, start/end checks | YAML DSL varies with releases; no runtime/model validation |
Trigger.dev | Source of task definitions (TypeScript/JS) | Literal task IDs, duplicates, advisory duration notes | Heuristics only; run TypeScript and Trigger.dev build/tests |
Activepieces | Flow JSON or flow version object | Trigger presence, duplicate step names, invalid-marked steps | Common nextAction/branches only; not an exhaustive flow validator |
OpenAPI | JSON spec | Existing GPT Tools integration checker | Best effort, not complete OpenAPI schema validation |
URL preflight | HTTPS URL | Known unsafe URL schemes/addresses using GPT Tools | No DNS or fetch. "manual_review" is not "safe." |
"Any automation platform" is not possible without an adapter for its native format. Unsupported platforms are reported as unsupported, rather than passing a meaningless check. You can add adapters to the registry in core.py and corresponding tests. Make, Zapier and Pipedream are not advertised as supported in v0.1.
Related MCP server: agent-sec-mcp
Install with Python 3.11+:
pip install automation-auditor-mcpConfigure a compatible MCP client:
{
"mcpServers": {
"automation-auditor": {
"command": "uvx",
"args": ["automation-auditor-mcp"]
}
}
}uvx requires uv. The package and command are not published yet, so this configuration is illustrative until the PyPI release succeeds.
For development from source:
python -m pip install -e .
python -m unittest discover -s tests -v
automation-audit examples/n8n-valid.json --platform n8n
automation-auditor-mcpThe last command runs the MCP stdio server and waits for a connected client. Use a host or MCP Inspector to communicate with it; starting from an ordinary terminal should not print output.
audit_workflow(platform, source): Pass the full text contents of an export or Trigger.dev source file. platform is auto, n8n, dify, trigger, trigger.dev, or activepieces. Max 250,000 characters. The server does not read files by path.
audit_openapi(spec_json): JSON OpenAPI document; uses the existing ahmad-yar-gpt-tools library.
preflight_url(url): Pure URL screening; never performs DNS lookup or HTTP request. A permitted syntax becomes manual_review because real fetching requires request-time controls.
list_supported_platforms(): Exact supported formats and known limitations.
Findings include a stable rule ID, severity, location, brief message, recommendation and confidence. They intentionally do not echo node names, raw URLs, credentials or source snippets. A report of no_findings_detected is not proof of safety.
The MCP client passes exported workflow JSON to audit_workflow("n8n", source). If a connection points to a deleted node, the structured report includes rule N8N009 with severity error. The assistant can explain the error and request the user to fix it. This tool never edits workflow files itself.
python -m unittest discover -s tests -vTest fixtures use only fictional metadata; no API keys or customer information. The core format inspectors require no network and do not import MCP at test time; MCP SDK integration requires installing dependencies.
Create public GitHub repo ahamdjin/automation-auditor-mcp and push these sources.
Run all tests and check MCP Inspector tool calls in a real MCP client. Improve Trigger.dev analysis with a TypeScript AST parser before describing it as comprehensive.
Build and release a distribution on PyPI. For trusted publishing, configure your PyPI publisher correctly; package publishing requires a separate approval/credentials step.
Preserve the README marker mcp-name: io.github.ahamdjin/automation-auditor-mcp inside the PyPI long description for Registry package ownership verification.
Generate and validate server.json using the official MCP Registry publisher; set the PyPI package identifier/version and stdio transport. Log in using GitHub, then publish.
Verify the listing by querying the official Registry API. The Registry hosts metadata, not your package.
The Registry's official publishing requirements explain PyPI ownership verification.
No source content is intentionally stored, sent externally, executed, or used for model inference. The MCP host may log inputs or reports separately. YAML aliases are refused, duplicate JSON/YAML fields are rejected, and input size is bounded. Trigger.dev regex checks have low confidence; a source audit cannot guarantee runtime behavior. Never treat URL preflight as SSRF prevention.
License: Apache-2.0. Upstream ahmad-yar-gpt-tools also uses Apache-2.0.
Source (after repository creation): https://github.com/ahamdjin/automation-auditor-mcp Creator: https://www.ahmadyar.co/
Check an OpenAPI 3.x JSON spec for common tool integration mistakes.
JSON only in this v1 tool. Not a full OpenAPI validation or a security audit.
| Name | Required | Description | Default |
|---|---|---|---|
| spec_json | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says 'JSON only in this v1 tool' and excludes full validation/security audits, but it does not describe return values, severity of findings, or whether the check is purely read-only. For an audit tool with no annotations and no output schema, this is a notable gap.
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 zero wasted words. The primary purpose is front-loaded, and the limiting scope follows immediately.
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 no annotations, no output schema, and 0% schema description coverage, the description should do more to explain what an agent gets back from the audit and how findings are represented. It defines scope boundaries but not the return shape, which is important for an audit 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?
Schema description coverage is 0%, so the description must compensate for the single required 'spec_json' parameter. It adds that the tool accepts 'OpenAPI 3.x JSON' and is 'JSON only in this v1 tool,' clarifying format and version, but it does not explain whether the value is raw JSON text, a file path, or another encoding.
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: 'Check an OpenAPI 3.x JSON spec for common tool integration mistakes.' It clearly scopes the audit to integration mistakes rather than full validation or security, though it does not explicitly differentiate from siblings like audit_workflow.
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 provides boundary conditions — 'Not a full OpenAPI validation or a security audit' — which implies when not to use it. However, it does not say when to prefer this over sibling tools such as audit_workflow or preflight_url, leaving alternative selection implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only checks on n8n JSON, Dify DSL, Activepieces JSON or Trigger.dev code.
platform: n8n | dify | activepieces | trigger | auto. Paste an export/source string; no filesystem access, no external calls, no execution. Trigger.dev findings are heuristic and not a substitute for TypeScript checks.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| platform | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well: it declares read-only behavior, no filesystem access, no external calls, and no execution, and it explicitly warns that Trigger.dev findings are heuristic and not a substitute for TypeScript checks. It omits any statement about output shape or severity, which keeps it below 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded: the capability statement leads, followed by the platform vocabulary and the safety caveats. The 'platform: ...' fragment is terse but functional; little is wasted.
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 2-parameter tool with no output schema and no annotations, the description covers input expectations and safety boundaries but never hints at what the audit returns (finding structure, severity, pass/fail). An agent can call it correctly but cannot anticipate the result shape.
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 coverage is 0% and neither parameter has a description or enum, yet the description supplies the valid platform values (n8n | dify | activepieces | trigger | auto) and explains that 'source' is a pasted export/source string. That compensates for most of the schema gap, though it does not clarify format differences between platforms.
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+resource — read-only audits of workflow definitions — and enumerates the exact artifact types it accepts (n8n JSON, Dify DSL, Activepieces JSON, Trigger.dev code). It does not explicitly differentiate itself from the audit_openapi sibling, so it falls short of a 5.
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?
Usage is implied rather than stated: the agent learns it should 'paste an export/source string' and that 'auto' is an acceptable platform value, which conveys the calling context. However, there is no guidance on when to prefer this tool over audit_openapi or preflight_url, and no stated exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List exact export types and limitations; unsupported platforms are never called safe.
| 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 full behavioral burden, but it only offers a cryptic policy statement ('unsupported platforms are never called safe'). It does not disclose what the tool returns, whether it is a read operation, or any other behavioral trait.
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, short sentence with no wasted words, and the main action is front-loaded. However, the phrasing is slightly ambiguous, which keeps it from being perfect.
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 no annotations and no output schema, the description is too minimal. It does not clarify what 'export types and limitations' means for platforms, nor does it indicate what the returned list contains, leaving an agent unable to call it confidently.
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 takes zero parameters, so there are no parameter semantics to document. The baseline of 4 applies because the schema is effectively complete and the description need not add parameter 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 says 'List exact export types and limitations,' which is a verb but does not name the resource 'platforms' even though the tool name does. It fails to distinguish the tool from siblings like audit_workflow or preflight_url, leaving the actual scope vague.
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 this tool versus alternatives. No context or exclusions are provided, so the agent must infer its purpose from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate syntax and literal IP red flags without fetching a URL.
For domain names, request-time DNS and HTTP redirects remain unchecked. A manual_review result NEVER means safe to fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose meaningful behavior: no network fetch occurs, DNS/redirects are unchecked for domain names, and a manual_review verdict is not a safety guarantee. That final warning about result semantics is genuinely valuable. It stops short of describing the full result taxonomy or any rate/limit behavior.
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?
Three short sentences, front-loaded with the core action, and each sentence adds a distinct constraint (no fetch, unchecked aspects, result caveat). No filler, though the trailing caveats could be tightened into one line.
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 one-parameter tool with no annotations and no output schema, the description covers the essential limitations an agent needs before trusting the result. The main residual gap is that it only names one result value (manual_review) and does not outline the other outcomes, which matters more given there is no output schema.
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 coverage is 0% and the single 'url' parameter is undocumented in the schema. The description contextualizes what the URL is evaluated against (syntax, literal IP red flags) but adds no format, encoding, or validation guidance for the parameter itself. The parameter name is largely self-explanatory, keeping this at a baseline 3.
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?
States a specific verb and scope: 'Evaluate syntax and literal IP red flags without fetching a URL.' This clearly defines both the action and its static, non-network nature. It is distinguishable from siblings like audit_openapi, though it does not explicitly name them.
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 phrase 'without fetching a URL' implies when this is appropriate (a cheap pre-check) and the DNS/redirect caveat implicitly tells the agent when the result is insufficient. However, it never names an alternative tool or states explicitly when to prefer this over a full fetch/audit, so usage is only implied rather than directed.
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.0audit_openapiaudit_workflowlist_supported_platformspreflight_urlScored across 4 tools
Each tool targets a clearly distinct artifact or operation: workflow exports, platform capabilities, OpenAPI specs, and URL preflight. No two tools overlap in purpose, and the descriptions explicitly separate their scopes.
All tool names use lowercase snake_case with a verb_noun structure: audit_workflow, list_supported_platforms, audit_openapi, preflight_url. The pattern is predictable and consistent throughout.
Four tools is well-scoped for a focused, read-only auditor. Each tool earns its place by covering a distinct audit target without redundancy or unnecessary surface area.
The surface covers the core auditing tasks: workflow platforms, OpenAPI, and URL preflight, with a helper to list supported platforms. Minor gaps exist—no batch reporting or deeper security/runtime checks—but these are documented limitations rather than missing tools for the stated v1 purpose.
Audits any remote agent or MCP URL for JSON-RPC compliance, latency SLA, OpenAPI schema, and HTTP.
Scan text, documents, websites, and MCP metadata for prompt injection and sensitive-data risks.
Security scanner for n8n workflows + live MCP Trust-Check. 18 rules, OWASP mapped. Paid x402 API.
Statically audits MCP tool surfaces for token cost, schema quality, and design issues.
