n8n-ops-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.14.2
Disambiguation5/5
Every tool has a clearly distinct purpose. For example, execution-related tools (n8n_execution_stats, n8n_get_execution, n8n_list_executions, n8n_search_executions) each focus on different aspects: aggregated stats, single execution detail, listing, and text search. Similarly, workflow scanning tools target different signals (disabled nodes, credential usage, node type usage). No two tools overlap in function.
Naming Consistency5/5
All tool names follow the consistent pattern `n8n_<verb>_<resource>` using snake_case and imperative verbs (e.g., list, get, check, diff, find, run, scaffold, validate). The convention is uniform and predictable, making it easy for an agent to infer purpose from the name.
Tool Count4/5
With 20 tools, the server is on the higher end but still appropriate for the broad domain of n8n operations (workflows, executions, credentials, tags, schedules, webhooks, auditing, node generation). Each tool provides distinct value, and the count reflects the complexity of the platform without being excessive.
Completeness3/5
The tool set covers inspection, auditing, validation, and comparison well, but lacks mutation tools for creating, updating, or deleting workflows and credentials. While the server's focus appears to be ops/inspection, the absence of basic CRUD operations for key resources creates notable gaps that may require agents to fall back to other means.
Average 4.2/5 across 20 of 20 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 commits in the last 12 weeks
- Last stable release on July 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Lists return fields but lacks details on side effects, permissions, or whether it is read-only.
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 fluff: first states purpose, second lists return fields. Perfectly concise and front-loaded.
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?
No output schema, but description lists all key return fields. Could mention array format or pagination, but sufficient for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions; the description adds no extra meaning beyond the schema, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool surfaces webhook and form-trigger paths and lists specific return fields, distinguishing it from sibling tools like n8n_list_workflows. The verb 'surface' is slightly vague but the description is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage as a prerequisite for n8n_trigger with mode='webhook', but does not explicitly state when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description declares 'Read-only' and describes scanning behavior (scans recent workflows when workflowId omitted, defaults to active only). This adds value beyond the schema, though limitations like 'recent' are not precisely defined.
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?
Two sentences with the main purpose front-loaded. The second sentence is packed with detail but still efficient. No filler words, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description vaguely mentions returning 'workflow context + raw rule' but lacks specifics on data structure. It covers tool purpose and parameter usage well but omits return format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The tool description does not add additional semantic details beyond what the schema already provides, so baseline score of 3 is appropriate.
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?
Description clearly states the tool surfaces schedule triggers across workflows, decodes interval rules, and returns workflow context. It distinguishes from sibling tools which focus on credentials, nodes, and executions, none of which list schedules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides context ('answer what's running at 3am?') but does not explicitly state when to use vs alternatives or when not to use. There are no direct sibling competitors, so guidance is adequate but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It explicitly states the tool is read-only ('never mutates'), details the output structure (risk reports with sections), and notes authorization requirements. This is strong transparency, though it could mention potential side effects like performance impact or rate limits.
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 is concise (4-5 sentences) and front-loads the core purpose. Every sentence adds value: main action, category details, output structure, read-only nature, and auth requirement. There is no redundancy or filler.
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?
Given the tool's complexity (3 optional parameters, no output schema), the description covers the essential output format and parameter behavior. It explains the report structure and the effect of includeDetails. However, it does not describe the default when categories is omitted or error conditions, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it reiterates category names but does not clarify values, defaults, or relationships between parameters. It is adequate but not additive.
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 clearly states the tool's action ('Generate n8n's built-in security audit via POST /audit'), specifies the resource, and describes the five risk categories. While it does not explicitly distinguish from siblings, the name and context make its purpose distinct among the listed tools (e.g., no other audit tool covers all these categories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions a prerequisite (admin/owner role) but does not specify when to choose this audit over other audit-related siblings like n8n_audit_browser_bridge_usage or n8n_check_disabled_nodes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It lists the checks performed and indicates a return list with severity, but does not explicitly state that the tool is read-only or has no side effects, though 'static checks' implies non-destructive.
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 is two sentences, front-loaded with the primary purpose, and every part adds value. There is no wasted text.
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?
Given the tool's simplicity (1 parameter, no output schema), the description covers the main behavioral aspects and return format. However, it could be slightly improved by specifying the structure of the returned issues list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter 'id' with a clear description. The tool description does not add additional meaning beyond the schema, so a baseline score of 3 is appropriate.
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 clearly states the verb 'static checks' and the resource 'workflow', and lists specific checks (deprecated node types, old Code-node API usage, etc.), distinguishing it from siblings like n8n_check_disabled_nodes which may only check for disabled nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for static analysis before deployment but does not explicitly state when to use this tool versus alternatives like n8n_check_disabled_nodes, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: read-only, returns only metadata (no data field), requires admin/owner, defensive stripping of data field, and error behavior for unauthorized users. It does not discuss rate limits or side effects, but such details are unlikely needed. Transparency is good, so score 4.
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 concise (4 sentences) and front-loaded with the core action. It avoids redundancy, though the statement about defensive stripping slightly overlaps with the 'metadata only' claim. It is efficient but not maximally concise, earning a 4.
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?
Given no output schema, the description adequately explains the return structure (each row). It covers authentication requirements, read-only nature, and defensive behavior. The tool is simple, and the description covers all necessary context for an agent to use it correctly. Score 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both limit and cursor have clear descriptions). The tool description adds no additional meaning to the parameters beyond what the schema provides. Per guidelines, baseline is 3 when coverage is high, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists credentials and returns metadata only, with a detailed row structure. It distinguishes from sibling tools implicitly by specifying the resource, but does not explicitly contrast with other list tools like n8n_list_workflows. A score of 4 is appropriate for a clear, specific purpose with slight room for sibling differentiation.
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 provides clear context: read-only, requires admin/owner permissions, and mentions the 401 error for non-admin keys. However, it does not explicitly advise when to use this tool versus alternatives like n8n_get_credential_schema or n8n_find_workflows_using_credential. The guidance is solid but lacks explicit alternatives, warranting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool is read-only (listing executions) and lists return fields. It does not mention ordering (e.g., most recent first), authentication requirements, or pagination behavior beyond the limit parameter. For a simple list tool, this is adequate but lacks some context.
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, no wasted words. The first sentence covers purpose and return fields, the second provides a direct alternative. Extremely concise and well-structured.
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?
Given no output schema, the description explicitly lists return fields. It covers the tool's core functionality and provides a clear alternative. Minor missing details like default sorting order, but overall sufficient for a simple list tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all three parameters (workflowId, status, limit). The description adds no additional parameter information beyond what's in the schema, so it meets the baseline but does not exceed it.
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 clearly states the verb 'List', the resource 'n8n executions', and the scope 'recent with optional filters'. It also specifies the exact fields returned (id, workflowId, workflowName, etc.), distinguishing it from sibling tools like n8n_get_execution and n8n_search_executions.
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 provides a clear alternative: 'Use n8n_get_execution for the full run log.' This helps the agent decide when to use this tool vs. a more detailed one. However, it does not explicitly mention when not to use it or compare with n8n_search_executions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the return schema (id, name, etc.) but doesn't mention pagination, sort order, or that it's a read-only operation. Adequate but not thorough.
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 concise sentences, front-loaded with the verb 'List'. No wasted words; every sentence earns its place.
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 covers return fields, the 4 parameters are fully described in the schema, and a sibling alternative is mentioned. However, it lacks details on default sorting or pagination beyond the limit parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 minimal extra meaning beyond the schema's own parameter descriptions, which are already clear. No parameter info in the description that isn't already in the schema.
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 clearly states the tool lists workflows with optional filters and specifies the returned fields (id, name, active state, tags, updatedAt). It explicitly distinguishes from n8n_get_workflow by directing users to that sibling for full definitions.
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 provides clear context: it lists workflows with filters and points to n8n_get_workflow when full definition is needed. While it doesn't explicitly state when not to use it or list exclusions, the alternative is clearly named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Read-only' and lists return fields, but does not mention rate limits, authentication needs, or error behavior (e.g., if workflow ID is invalid). Adequate but not rich.
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, no wasted words. Critical information is front-loaded (verb, resource, endpoint, return). Highly efficient.
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 simple read tool with one parameter and no output schema, the description covers purpose, return structure (including fields beyond id/name), endpoint path, and pairing with a sibling. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the 'id' parameter is already described in the schema. The description does not add additional meaning beyond what the schema provides, so baseline 3 is appropriate.
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 clearly states the verb 'Read' and the resource 'tags attached to a workflow', specifies the HTTP endpoint, and distinguishes from sibling n8n_set_workflow_tags by mentioning pairing.
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?
Explicitly pairs with n8n_set_workflow_tags for diffs and reattach flows, but does not contrast with n8n_list_tags (a sibling that lists all tags globally). Context is clear but not fully exclusive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Read-only' and describes concurrency behavior ('Bounded-concurrency fan-out') and error handling ('per-workflow fetch errors land in fetchErrors'). It also mentions the return structure (one finding per node and per-workflow summary). This provides adequate transparency.
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 is concise: two sentences plus a final technical note. It is front-loaded with the purpose and provides essential details without unnecessary words. Every sentence adds value.
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?
Given the complexity (7 parameters, 1 required) and no output schema, the description adequately covers the tool's behavior, concurrency, error handling, and return structure. It could be improved by stating prerequisites or permissions, but overall it is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 all parameters. The description does not add additional context beyond the schema; it focuses on overall behavior. Baseline score of 3 is appropriate.
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 clearly states the purpose: scanning workflows to surface nodes matching a given type, with concrete examples like 'n8n-nodes-base.slack' and the legacy HTTP Request node. It distinguishes itself from siblings like n8n_find_workflows_using_credential by focusing on node type, and provides a use case ('where am I calling Slack?').
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 explicit use cases ('where am I calling Slack?', 'which workflows still use the legacy HTTP Request node?') and implies when not to use (e.g., for credential search, use n8n_find_workflows_using_credential). However, it does not explicitly list alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a key behavioral trait: resolves against live workflow, not the raw entity row. However, with no annotations, it should also mention error handling, auth requirements, or rate limits. The description is adequate but not thorough.
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, no redundant information. The description is front-loaded with the core action, and every sentence serves a purpose.
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?
Given no output schema, the description hints at return values ('metadata and optionally the full node graph'), which is sufficient for a simple fetch. The context about live vs entity is valuable. Could elaborate on error responses but overall complete.
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 baseline is 3. Description adds value by explaining where to get the id ('from n8n_list_workflows') and providing usage context for includeDefinition parameter. This exceeds the baseline.
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?
Clearly states verb 'Fetch' and resource 'single n8n workflow by id'. Differentiates from sibling list/diff tools by specifying it returns metadata and optionally the full node graph.
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?
Provides guidance on when to enable includeDefinition ('when you need to inspect or edit') and notes that it resolves against the live workflow. Lacks explicit when-not-to-use or comparison with siblings like n8n_audit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool generates JSON locally without calling the n8n API, and describes two modes. It does not explicitly state how the output is delivered (e.g., stdout), but 'ready-to-paste' implies the JSON is output. The description is consistent and clear.
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 is concise with three sentences: one for main purpose, one for context, and one for mode details. It is front-loaded with the primary action and contains no filler. Every sentence earns its place.
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?
Given the tool's complexity (7 parameters, nested objects, enum), the schema provides full parameter coverage. The description adds context about the local generation and modes. It could mention the output format more explicitly, but overall it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so a baseline of 3 is appropriate. The description adds value by explaining the two modes and the default behavior, but most parameter semantics are already covered in the input schema. Little extra meaning beyond the schema.
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 clearly states the tool generates a ready-to-paste n8n node JSON for a given platform, action, and input. It specifies the resource (n8n node for browser-bridge) and verb (generate), and distinguishes from sibling tools (which are other n8n utilities not related to scaffolding).
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 implies when to use this tool: when you need to create an n8n node for browser-bridge without rediscovering the spawn/heredoc pattern. It also explains there are two modes ('code-node' and 'execute-command') with default indicated. However, it doesn't explicitly state when NOT to use it or name alternative tools, though none of the siblings are relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses that the tool is read-only and uses a heuristic matching method. It explains the matching pattern and the output structure, providing sufficient behavioral context for safe agent usage.
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 is a single focused paragraph that front-loads the core purpose and provides necessary details without redundancy. Every sentence earns its place.
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 covers the scan scope, matching method, output structure, read-only nature, and parameter defaults. It is complete enough given the moderate complexity and absence of an output schema.
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?
All six parameters have schema descriptions, and the description adds value by including default values and rationale (e.g., 'inactive workflows often hide stale browser-bridge calls'). This goes beyond the bare schema.
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 clearly states the tool scans every workflow for nodes invoking the browser-bridge CLI, and specifies the exact node types (Execute Command, Code/Function, SSH). It distinguishes from sibling tools by focusing on a specific use case: locating browser-bridge calls without grepping the database.
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 a concrete example of when to use the tool ('where am I calling Linktree sync from?'), implying usage context. However, it does not explicitly compare to siblings or state when not to use it, so it's clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is highly transparent without annotations. It declares read-only, bounded concurrency fan-out, and that per-workflow errors go to 'fetchErrors' instead of failing the scan. This fully discloses behavior.
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 well-structured and informative, though slightly longer. Each sentence adds value, and the main action is front-loaded. Could be tightened slightly but remains effective.
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?
Despite no output schema, the description clearly defines the output structure (one finding per triplet plus count) and error handling. It covers all essential aspects for a scanning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions in the schema are already detailed (e.g., maxWorkflows explains counting logic). The description adds no additional parameter-specific value beyond tool context, so baseline 3 applies.
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 clearly states the tool scans workflows and surfaces nodes with 'disabled: true'. It specifies output format (per workflowId, nodeName, nodeType plus count) and distinguishes itself from siblings by focusing on disabled nodes, which the UI doesn't surface.
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 explains why disabled nodes are important (drift signals) and that the UI doesn't list them, but does not explicitly state when not to use or name alternative tools. However, the context and sibling list imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It declares the tool is read-only, describes the output shape, and notes accepted snapshot formats. It does not mention error conditions or path restrictions explicitly, but those are covered in the schema descriptions.
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 concise sentences, front-loaded with purpose, no fluff. Every sentence adds essential information.
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?
Given the complexity (5 parameters, no output schema), the description adequately covers the return value structure and snapshot format compatibility. It could mention potential error scenarios but is sufficient for agent invocation.
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 descriptions cover 100% of parameters with detailed explanations. The description adds value by explaining that the snapshot can be in two different shapes, which is not fully captured in the schema. This goes beyond what the schema alone provides.
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 clearly states the tool compares a workflow's current state against a snapshot and returns a structured semantic diff. It explicitly lists what the diff contains (nodes added/removed/modified with per-node field paths, change flags). This distinguishes it from sibling tools which are listing, auditing, or execution-related.
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 implies usage for comparing workflow states but does not explicitly state when to use this tool vs alternatives or when not to use it. However, given the sibling tools, none perform diffing, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares itself 'composed read-only', explains pagination against /executions, mentions best-effort pagination and truncation. No annotations present, so description handles transparency well.
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?
Concise two-sentence core, followed by usage phrase and pagination note. No wasted words; front-loaded with purpose.
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?
Covers parameters, usage, behavior, and limitations. Lacks output format details (e.g., map per workflow), but acceptable for an aggregation tool without output schema.
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?
Adds context beyond schema: workflowId optional for per-instance stats, sinceHours window stops pagination, maxExecutions with truncation hint, pageSize default. Schema coverage is 100%, but description enriches understanding.
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 clearly states 'Aggregate execution stats over a recent window' and lists computed fields (counts, failure rate, runtimes, timestamps). It distinguishes from siblings like n8n_list_executions by focusing on aggregation.
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?
Provides practical use cases ('which workflows are flaky?') and pagination advice ('if truncated: true, increase maxExecutions or narrow sinceHours'). However, it does not explicitly contrast with alternatives like n8n_search_executions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: truncation of large logs with a tail hint, raw error inclusion in error executions. This goes beyond basic functionality. However, it does not explicitly state idempotency or lack of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no redundancy. It immediately states the purpose, then lists key return data and special behaviors. Every sentence adds essential information.
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?
Given no output schema and no annotations, the description adequately explains what the tool returns and its edge cases (truncation, error handling). It could be more complete by mentioning response format, but it is sufficient for a fetch operation.
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?
The schema already covers 100% of parameters with descriptions. The tool description adds extra context: for id it links to n8n_list_executions, and for includeRunData it explains the default and use case. This adds value beyond the schema.
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 clearly states the action (fetch) and resource (n8n execution by id). It lists returned fields (status, mode, timing, per-node run data), and differentiates from siblings like list/search by focusing on a single id.
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 implies usage when you have an execution id and need details. It does not explicitly state when to avoid or mention alternatives, but the context hints are clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses that the tool fetches data with includeData=true, greps specific fields, redacts API keys, and warns that credentials may appear in snippets with scope='all'. It also notes that scope='all' is slower. This covers key behavioral traits, though it doesn't mention rate limits or performance impact beyond slowness.
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 is concise (4-5 sentences) with no unnecessary words. It front-loads the core purpose and then efficiently covers scope, return format, and security notes. Every sentence adds value.
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?
Given no output schema, the description adequately explains what is returned: matched executions with workflow context and snippets, including redaction and sensitivity. However, it could benefit from a brief note on the structure of matched data (e.g., keys returned) or pagination behavior. Still, it's sufficient for the task.
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?
All 7 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds significant value beyond schema by explaining the overall flow, scope behavior, snippet content, and sensitivity implications. This enrichment justifies a 4.
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 explicitly states it performs text-search across executions, distinguishing it from simple listing tools like n8n_list_executions. It uses specific verbs ('Text-search', 'Fetches', 'greps') and resources ('n8n executions'), with clear scope differentiation ('error' vs 'all'). This separates it from siblings that list or fetch single executions.
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 explains when to use this tool (to search recent executions without paging) and provides context on scope choices and sensitivity. While it doesn't explicitly state when not to use it or compare to alternatives like list_executions, it gives enough practical guidance for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses GET method, raw JSON Schema return, error responses (404 with reason, 401 requiring admin/owner role). Suffices for agent to understand behavior.
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, first states purpose and endpoint, second gives usage and error info. No wasted words, front-loaded.
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 single-parameter tool without output schema, description covers return type, errors, usage order. Complete and sufficient.
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% with parameter description. Description adds example (freshdeskApi requires { apiKey, domain }) providing meaningful context beyond 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?
Description clearly states 'Fetch the JSON schema for a credential type', specifying the HTTP endpoint and resource. It distinguishes from sibling tools like listing or using credentials, and gives context for use before creation.
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?
Explicitly says 'Use this BEFORE calling n8n_create_credential' and mentions error responses (404, 401). Provides clear context for when to use, though no explicit alternatives for when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states read-only behavior and details the return format including pagination (nextCursor), providing full behavioral disclosure.
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 concise sentences front-load the action and return format, with no wasted words. Every sentence adds value.
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?
Given no annotations and no output schema, the description thoroughly covers purpose, usage, behavior, and output format for a list operation, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described in the input schema. The description adds value by mentioning the output's nextCursor, clarifying the cursor parameter's source, but does not significantly extend beyond the schema.
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 clearly states the verb 'List' and resource 'workflow tags', identifies the HTTP method GET /tags, and distinguishes from siblings by referencing related tools for setting and getting tags.
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 indicates it is read-only and pairs with specific sibling tools for cross-cutting workflow metadata, providing clear context. It lacks explicit when-not-to-use guidance but is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond what annotations would cover: 'Read-only. Bounded-concurrency fan-out; per-workflow fetch errors land in fetchErrors instead of failing the whole scan.' It also explains the return structure. Given no annotations, this fully informs the agent of the tool's operational characteristics.
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 well-structured and front-loaded with the main purpose. It is slightly verbose but every sentence adds necessary information. Could be trimmed slightly, but remains effective and clear.
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?
Despite lacking an output schema, the description thoroughly explains the return format: 'one finding per (workflowId, nodeName, credentialType) plus a per-workflow summary count.' It also accounts for error handling. Given the tool's complexity with 6 parameters, this is comprehensively complete.
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?
Schema description coverage is 100%, but the description adds significant value by explaining the interplay between parameters (e.g., credentialId vs credentialName) and clarifying defaults and behaviors for maxWorkflows and concurrency. For instance, it explains how maxWorkflows is counted and that concurrency has a default of 3.
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 clearly states the tool's purpose: 'Scan workflows and surface every node that references a given credential.' It also distinguishes itself from siblings by noting it 'Pairs with n8n_run_audit and is the answer to... before calling n8n_delete_credential.' This specificity helps the agent differentiate from other tools like n8n_find_workflows_using_node_type.
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 provides clear guidance on when to use the tool, instructing to pass either credentialId (preferred) or credentialName. It contextualizes usage: 'before calling n8n_delete_credential.' While it does not explicitly state when not to use it, the guidance is sufficient for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![n8nctrl MCP server](https://glama.ai/mcp/servers/lidless-labs/n8nctrl/badges/card.svg)](https://glama.ai/mcp/servers/lidless-labs/n8nctrl)

Score Badge

Copy to your README.md:

[![n8nctrl MCP server](https://glama.ai/mcp/servers/lidless-labs/n8nctrl/badges/score.svg)](https://glama.ai/mcp/servers/lidless-labs/n8nctrl)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lidless-labs/n8nctrl'

If you have feedback or need assistance with the MCP directory API, please join our Discord server