n8n Management MCP Server

Server Quality Checklist

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

Latest release: v1.0.9
Disambiguation4/5
Most tools have distinct purposes targeting specific resources (workflows, credentials, tags, executions, users), with clear action verbs. However, some overlap exists between 'n8n_list_executions' and 'n8n_get_execution' or 'n8n_list_tags' and 'n8n_get_tag', where the list vs. get distinction might be slightly ambiguous without careful reading of descriptions. Overall, the tool boundaries are well-defined.
Naming Consistency5/5
All tools follow a consistent 'n8n_verb_noun' naming pattern with snake_case throughout. Verbs like create, get, list, update, delete, and execute are used predictably across different resource types (e.g., n8n_create_workflow, n8n_get_workflow, n8n_update_workflow). This uniformity makes the tool set easy to navigate and understand.
Tool Count3/5
With 27 tools, the count is on the high side for a single server, potentially overwhelming for an agent. While n8n is a complex automation platform requiring management of multiple resources (workflows, credentials, tags, executions, users), the tool set feels heavy and could benefit from consolidation or categorization to improve usability without sacrificing functionality.
Completeness5/5
The tool set provides comprehensive CRUD and lifecycle coverage for all core n8n resources: workflows (create, get, list, update, delete, activate/deactivate, execute, retry), credentials (create, get schema, update, delete), tags (create, get, list, update, delete), executions (get, list, delete, retry), and users (get, list, delete, update role). There are no obvious gaps, and the tools support essential operations like workflow execution and tagging management.
Average 4.3/5 across 27 of 27 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-read-only, non-destructive, idempotent operation with open-world data. The description adds valuable context beyond annotations: it explains that activation enables automatic execution for triggers, specifies the requirement for valid trigger nodes, and clarifies the purpose as 'listening' for triggers. No contradiction with annotations, as 'start' aligns with non-read-only and non-destructive hints.
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 and front-loaded, consisting of two sentences that directly explain the tool's purpose and prerequisites without unnecessary details. Every sentence adds value, making it efficient and easy to understand.
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 moderate complexity (activating workflows with triggers), rich annotations (covering safety and idempotency), and no output schema, the description is fairly complete. It covers the action, purpose, and prerequisites, but could benefit from mentioning potential side effects like resource usage or error conditions, though annotations help mitigate this gap.
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 has 100% description coverage, with the 'id' parameter fully documented. The description doesn't add any parameter-specific details beyond the schema, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to.
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 the action ('Start a workflow to listen for triggers') and resource ('workflow'), specifying it enables automatic execution when triggers are met. However, it doesn't explicitly differentiate from sibling tools like 'n8n_execute_workflow' (which likely runs a workflow immediately) or 'n8n_deactivate_workflow' (the inverse operation), missing full sibling distinction.
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 on when to use it: when you want to enable automatic execution based on triggers like webhooks or schedules, and it mentions the prerequisite that 'Workflow must have valid trigger nodes.' It doesn't explicitly state when not to use it or name alternatives, such as using 'n8n_execute_workflow' for one-time runs.
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?
Annotations already cover key behavioral traits (readOnlyHint=false, destructiveHint=false, etc.), so the bar is lower. The description adds useful context about credential types and the need to check schemas, but doesn't disclose additional behavioral details like authentication requirements, rate limits, or error handling. No contradiction with annotations.
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 efficiently structured in two sentences: the first states the purpose and parameters, the second provides crucial usage guidance. Every sentence earns its place with no wasted words, making it front-loaded and easy to parse.
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 creation tool with no output schema, the description is reasonably complete given good annotations and schema coverage. It covers purpose, parameters, and usage prerequisites, but lacks details on return values or error cases. Slightly incomplete without output information.
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%, providing full parameter documentation. The description adds minimal semantic value beyond the schema by mentioning credential types and authentication data examples, but doesn't explain parameter interactions or constraints. Baseline 3 is appropriate given high schema coverage.
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 specific action ('Store new API credentials') and resource ('for services like GitHub, Slack, or databases'), distinguishing it from siblings like n8n_update_credential or n8n_delete_credential. It precisely identifies the tool's function as credential creation with examples.
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 explicitly provides when-to-use guidance by stating 'Use get_credential_schema first to see required fields for each type,' naming an alternative tool (n8n_get_credential_schema) for prerequisite information. This gives clear context for proper usage.
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?
Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds valuable context by explaining the purpose of tags ('help filter and organize workflows'), which is not covered by annotations, though it doesn't detail potential side effects like duplicate handling or permissions.
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 front-loaded with the core purpose in the first sentence, followed by actionable guidance and benefits, with no wasted words. Every sentence contributes directly to understanding the tool's use.
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 low complexity (one parameter, no output schema) and rich annotations, the description is mostly complete, covering purpose and usage. However, it lacks details on return values or error cases, which would be helpful despite the absence of an output schema.
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 has 100% description coverage, fully documenting the single 'name' parameter. The description adds minimal semantics by suggesting examples like 'production' or 'staging', but does not provide additional details beyond what the schema already states, meeting the baseline for high schema coverage.
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 specific action ('Create new tag') and resource ('for workflow categorization'), distinguishing it from siblings like n8n_update_tag or n8n_delete_tag by focusing on creation rather than modification or deletion.
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 provides clear context for when to use the tool (creating tags for organizing workflows) and includes examples of meaningful names, but does not explicitly state when not to use it or name alternatives like n8n_update_tag for modifying existing tags.
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?
Annotations provide readOnlyHint=false (indicating mutation), openWorldHint=true (suggesting flexibility), idempotentHint=false (non-idempotent), and destructiveHint=false (non-destructive). The description adds valuable context beyond this by specifying that it 'Returns new workflow with assigned ID' (output behavior) and mentions the optional activation feature, which is not covered by annotations. No contradictions with annotations exist.
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 front-loaded with the core purpose in the first sentence, followed by parameter summary and output details in subsequent sentences. Each sentence adds essential information without redundancy, making it efficient and well-structured for quick comprehension.
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 (4 parameters with nested objects, no output schema), the description adequately covers the tool's purpose, inputs, and output behavior. However, it lacks details on error conditions, rate limits, or authentication requirements, which would be beneficial for a mutation tool with openWorldHint=true. The absence of an output schema makes the return value description ('Returns new workflow with assigned ID') particularly valuable.
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 each parameter clearly documented in the schema (e.g., 'Descriptive workflow name' for name). The description adds minimal value by summarizing parameters ('Provide workflow name, node array, and connection object') and noting the optional 'active' parameter, but does not provide additional semantic details beyond what the schema already offers.
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 specific action ('Create a new automation workflow') and resource ('workflow'), distinguishing it from siblings like n8n_update_workflow (which modifies existing workflows) and n8n_get_workflow (which retrieves workflows). It specifies the creation involves 'nodes and connections', which differentiates it from simpler creation 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 provides clear context for usage by listing required inputs (name, nodes, connections) and an optional parameter (active). However, it does not explicitly state when to use this tool versus alternatives like n8n_update_workflow or n8n_execute_workflow, nor does it mention any prerequisites or 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?
Annotations already indicate this is a non-destructive, idempotent operation with open-world semantics. The description adds valuable context beyond this: it explains that deactivation 'prevents automatic execution but preserves workflow configuration,' clarifying the behavioral outcome. No contradictions with annotations exist.
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 extremely concise (two sentences) and front-loaded with the core purpose. Every sentence earns its place: the first defines the action and effect, the second provides usage guidance. No wasted words.
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 moderate complexity (a state-change operation), rich annotations, and full schema coverage, the description is mostly complete. However, without an output schema, it doesn't clarify what the tool returns (e.g., success confirmation or updated workflow state), leaving a minor gap.
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 has 100% description coverage, fully documenting the single 'id' parameter. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline for high schema coverage without extra value.
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 specific action ('Stop a workflow from listening to triggers') and resource ('workflow'), distinguishing it from siblings like n8n_activate_workflow (which does the opposite) and n8n_delete_workflow (which removes it entirely). It precisely defines what deactivation means in this context.
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 for when to use this tool ('Use before making structure changes'), but it doesn't explicitly mention when not to use it or name alternatives like n8n_activate_workflow for reactivation. The guidance is helpful but not fully comparative.
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?
Annotations already indicate destructiveHint=true and idempotentHint=true, but the description adds valuable context beyond this: it clarifies that tag removal affects only tag associations, not workflows themselves, and specifies automatic cleanup from workflows. This enhances transparency without contradicting annotations, though it could mention permissions 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 front-loaded with the main action ('Remove tag from system') and uses two concise sentences that each add value: the first states the purpose, and the second clarifies behavioral impact. There is no wasted text, making it efficiently structured and easy to parse.
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 (destructive operation with one parameter) and rich annotations (e.g., destructiveHint, idempotentHint), the description is mostly complete. It explains the action and its effects on workflows, but lacks output details (no output schema) and doesn't cover error cases or prerequisites, 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%, with the parameter 'id' fully documented in the schema as 'Tag ID to permanently delete'. The description does not add any additional meaning or details about the parameter beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
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 specific action ('Remove tag from system') and resource ('tag'), distinguishing it from siblings like n8n_delete_workflow or n8n_delete_user by focusing on tags. It elaborates on the scope by mentioning automatic removal from workflows, making the purpose explicit and distinct.
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 for when to use this tool—to delete a tag and remove its associations from workflows—but does not explicitly state when not to use it or name alternatives. For example, it doesn't contrast with n8n_update_tag or mention if tag deletion is irreversible, leaving some guidance implicit rather than explicit.
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?
Annotations already indicate destructiveHint=true and idempotentHint=true, but the description adds valuable context beyond this: it specifies that deletion is immediate ('lose access immediately'), clarifies permission constraints ('Only available to instance owner'), and notes data persistence ('Workflows created by this user remain intact'). This enriches the behavioral understanding without contradicting annotations.
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 efficiently structured in four concise sentences, each providing critical information without redundancy. It front-loads the core action and progressively adds constraints and consequences, making every sentence earn 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 (destructive user deletion), rich annotations (covering safety and idempotency), and lack of output schema, the description is nearly complete. It covers purpose, permissions, constraints, and immediate effects, though it could mention potential recovery options or error scenarios for full completeness.
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 has 100% description coverage, clearly documenting the single parameter 'id' as 'User ID to permanently delete (not email)'. The description does not add any additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage.
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 specific action ('Remove user') and resource ('from n8n instance'), distinguishing it from siblings like n8n_update_user_role or n8n_get_user. It precisely defines the operation without being vague or tautological.
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 for when to use this tool ('Only available to instance owner') and exclusions ('Cannot delete the owner account'), but does not explicitly name alternatives like n8n_update_user_role for demoting users instead of deleting them. This gives strong guidance but stops short of full alternative specification.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds valuable context beyond this: it specifies that the action is permanent and irreversible, mentions the prerequisite of deactivation, and warns to use with caution, enhancing the agent's understanding of behavioral risks.
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 front-loaded with the core action and key warnings in three concise sentences, each earning its place by providing critical information without redundancy or unnecessary elaboration.
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 (destructive operation with prerequisites), the description is largely complete: it covers purpose, guidelines, and behavioral context. However, without an output schema, it does not describe return values or error conditions, leaving a minor gap in full contextual understanding.
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 one parameter ('id') fully documented in the schema. The description does not add any additional semantic details about the parameter beyond what the schema provides, so it meets the baseline for high schema coverage.
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 specific action ('permanently delete'), the resource ('workflow and all associated execution history'), and distinguishes it from siblings like 'n8n_deactivate_workflow' by emphasizing the irreversible nature of deletion versus deactivation.
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 provides explicit context for when to use ('Workflow must be deactivated first') and a cautionary note ('Use with caution'), but does not name specific alternatives or explicitly state when not to use it compared to other deletion tools like 'n8n_delete_execution'.
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?
Annotations cover key traits (readOnlyHint=false, destructiveHint=false, etc.), but the description adds valuable context beyond annotations: it specifies that the workflow does not need to be active, mentions the return of an execution ID for progress tracking, and clarifies the tool's utility for testing or API-driven scenarios. No contradictions with annotations are present.
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 front-loaded with the core purpose in the first sentence, followed by utility and key behavioral details, all in three concise sentences with no wasted words. Each sentence adds distinct value, making it efficient 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 the tool's moderate complexity (2 parameters, no output schema, annotations present), the description is largely complete: it covers purpose, usage context, key behavioral traits, and return value. However, it lacks details on error handling or execution limits, which could be useful given the openWorldHint annotation and lack of output schema.
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 schema already documents both parameters (id and data). The description adds minimal semantic value by noting that data is 'optional input data passed to workflow start node,' but this largely reiterates the schema. Baseline 3 is appropriate as the schema handles most parameter documentation.
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 specific action ('Manually trigger workflow execution') and resource ('workflow'), distinguishing it from siblings like n8n_activate_workflow or n8n_get_workflow by emphasizing manual triggering without requiring webhooks or active status. It explicitly mentions optional input data and returns an execution ID, making the purpose highly specific and differentiated.
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 on when to use this tool ('Useful for testing or API-driven workflows without webhooks'), but it does not explicitly state when not to use it or name alternatives. For example, it doesn't contrast with n8n_retry_execution or n8n_get_execution, leaving some ambiguity in sibling tool selection.
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?
Annotations indicate readOnlyHint=true and destructiveHint=false, which the description aligns with by describing a read operation. The description adds valuable context beyond annotations: it explains the tool's role in understanding authentication data and the output format (field names, types, required status), which is not covered by annotations. No contradictions are present.
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 and front-loaded, with two sentences that efficiently convey purpose, usage, and output. Every sentence adds essential information without redundancy, making it easy to parse and understand quickly.
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 low complexity (1 parameter, 100% schema coverage) and annotations covering safety (readOnly, non-destructive), the description is mostly complete. It explains the output format and usage context, but lacks an output schema, which might leave some uncertainty about the return structure. However, it compensates well for the absence of an output schema by describing the return content.
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 has 100% description coverage, with the parameter 'credentialType' well-documented in the schema. The description does not add specific details about the parameter beyond implying it's used to identify the credential type, so it meets the baseline of 3 where the schema does the heavy lifting without extra value.
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 with specific verbs ('Get required fields and format') and resource ('credential type'), distinguishing it from siblings like n8n_create_credential by focusing on schema retrieval rather than creation. It explicitly mentions the output ('Returns field names, types, and whether fields are required') and the context ('before creating it'), making the purpose unambiguous.
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 for usage ('before creating it') and implies an alternative (n8n_create_credential) by referencing credential creation. However, it does not explicitly state when not to use this tool or compare it to other sibling tools like n8n_get_credential (which is not listed), leaving some guidance gaps.
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?
Annotations indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds valuable context beyond this: it specifies what data is returned (node outputs, error messages, timing, full logs) and the purpose (debugging, understanding data flow), which helps the agent understand the tool's behavior without contradicting annotations.
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 core purpose and followed by usage context. Every sentence adds value: the first specifies what data is retrieved, and the second explains when to use it, with zero wasted words or redundancy.
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 (retrieving detailed execution data), annotations cover safety and scope, and the schema fully documents the single parameter. However, there is no output schema, and the description does not detail the return format (e.g., structure of logs), leaving a minor gap. It is mostly complete but could benefit from more on output specifics.
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 has 100% description coverage, with the 'id' parameter documented as 'Execution ID from list_executions'. The description does not add further meaning about the parameter, such as format examples or constraints, so it meets the baseline of 3 where the schema does the heavy lifting.
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 'Get' and the resource 'detailed execution data', specifying it includes node outputs, error messages, timing, and full execution logs. It distinguishes from siblings like n8n_list_executions (which lists executions) and n8n_delete_execution (which deletes), by focusing on retrieving detailed data for a specific execution.
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 for usage: 'Essential for debugging failed workflows or understanding data flow.' It implies when to use this tool (for detailed analysis) but does not explicitly state when not to use it or name alternatives like n8n_list_executions for overviews, which keeps it from a perfect score.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds valuable context by specifying the return type ('Returns array of tag names') and the purpose ('for categorization'), which enhances understanding beyond the annotations. No contradictions with annotations are present.
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 front-loaded with the core purpose, followed by return details and usage context in two concise sentences. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
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 low complexity (one parameter, no output schema), annotations cover safety and scope, and the description adds return type and usage context, it is mostly complete. However, without an output schema, the description could further detail the return format (e.g., array structure or error cases) for full completeness.
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 has 100% description coverage, fully documenting the single required parameter 'id' as 'Workflow ID'. The description does not add any parameter-specific details beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage without extra value.
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 specific action ('Retrieve tags assigned to a workflow') and resource ('workflow'), distinguishing it from siblings like n8n_get_workflow (which retrieves workflow details) or n8n_list_tags (which lists all tags). It precisely communicates what the tool does without being vague or tautological.
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 for when to use this tool ('to understand workflow organization before bulk operations'), which helps differentiate it from other tag-related tools. However, it does not explicitly state when not to use it or name specific alternatives, such as using n8n_get_workflow for general workflow details instead.
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?
Annotations already indicate read-only, non-destructive, and open-world behavior, which the description does not contradict. The description adds valuable context beyond annotations by specifying the return format ('execution ID, status, start time, and workflow name') and the tool's purpose for monitoring and debugging, enhancing transparency without repeating annotation information.
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 front-loaded with key information in the first sentence and uses two concise sentences that efficiently convey purpose, parameters, returns, and usage context. Every sentence adds value without redundancy, making it well-structured and appropriately sized for the tool's complexity.
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 low complexity (1 optional parameter), rich annotations (read-only, non-destructive, open-world), and no output schema, the description is mostly complete. It covers purpose, filtering, returns, and usage, but could slightly improve by mentioning pagination or limits for the list operation, though annotations provide some safety context.
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 has 100% description coverage, fully documenting the optional 'workflowId' parameter. The description mentions filtering by workflow ID but does not add significant semantic details beyond what the schema provides, such as format examples or constraints. This meets the baseline score for high schema coverage without extra value.
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 ('Retrieve execution history') and resource ('executions'), specifying what information is included ('status, timestamps, and workflow info'). It distinguishes this tool from siblings like 'n8n_get_execution' (which retrieves a single execution) and 'n8n_delete_execution' (which deletes executions), making the purpose specific and well-differentiated.
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 on when to use it ('to monitor automation performance or debug failures') and mentions filtering options ('Filter by workflow ID or get all executions'). However, it does not explicitly state when not to use it or name specific alternatives, such as using 'n8n_get_execution' for detailed single execution data, which prevents a perfect score.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds valuable context beyond this: it specifies the permission requirement ('Only available to instance owner'), lists the exact return fields, and hints at use cases ('user management and auditing'), enhancing behavioral understanding without contradicting annotations.
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 front-loaded with core functionality and constraints, using two efficient sentences with zero waste. Each sentence adds critical information (what it does, who can use it, what it returns, and usage context), making it appropriately sized 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 the tool's low complexity (one optional parameter, no output schema), the description is mostly complete: it covers purpose, constraints, return values, and usage. However, it lacks details on pagination or ordering for the list, which could be relevant for user management, leaving a minor gap in contextual coverage.
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 has 100% description coverage for its single parameter (limit), so the schema fully documents it. The description does not add any parameter-specific information beyond what the schema provides, such as default behavior details. This meets the baseline of 3 for high schema coverage.
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 specific action ('Retrieve all n8n users') and resource ('users with their roles and status'), distinguishing it from sibling tools like n8n_get_user (singular) and n8n_update_user_role (modification). It explicitly lists the returned fields (user ID, email, role, disabled status), making the purpose highly specific and differentiated.
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 for usage ('user management and auditing') and an important constraint ('Only available to instance owner'), which helps determine when to use it. However, it does not explicitly state when not to use it or name alternatives (e.g., n8n_get_user for single-user retrieval), missing full sibling 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?
Annotations already provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe, read-only operation that might return many results. The description adds value by specifying the return fields (workflow ID, name, active status, creation date, tags) and the browsing/finding use case, which gives context beyond the annotations. It doesn't mention rate limits or pagination, but with annotations covering safety, this is sufficient.
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 core purpose and return details, followed by usage context. Every sentence adds value without redundancy, making it efficient and well-structured for an agent to parse quickly.
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 (list operation with filtering), annotations cover safety and scope, and the schema fully documents parameters. The description adds return field details and usage context, which is helpful since there's no output schema. However, it could mention potential limitations like result size or pagination, but for a read-only list tool, this is mostly complete.
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 both parameters (active and tags). The description doesn't add any parameter-specific information beyond what the schema provides, such as explaining how filtering interacts with the return fields. Since the schema does the heavy lifting, the 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 'Retrieve' and resource 'all workflows' with specific details about what information is returned (status, tags, metadata, ID, name, active status, creation date). It distinguishes from siblings like n8n_get_workflow (singular) and n8n_list_executions by focusing on workflows with their metadata rather than individual workflows or 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 clear context for usage ('browse available automations or find a specific workflow by name'), which helps an agent understand when this tool is appropriate. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the siblings, such as n8n_get_workflow for detailed info on a single workflow.
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?
Annotations cover key traits (mutable, idempotent, non-destructive), but the description adds valuable context: it discloses that renaming affects all workflows using the tag automatically, which is crucial behavioral information not captured in annotations. No contradictions with annotations exist.
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 front-loaded with the core action in the first sentence, followed by a concise usage guideline. Both sentences are essential—the first defines the purpose, and the second provides context—with no wasted words.
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 moderate complexity (a mutation with two parameters) and rich annotations, the description is mostly complete. However, without an output schema, it could benefit from mentioning the return value or success indicators, though the behavioral context provided partially compensates.
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 has 100% description coverage, clearly documenting both parameters (id and name). The description does not add further meaning beyond the schema, such as format examples or constraints, so it meets the baseline for high schema coverage.
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 specific action ('Rename an existing tag') and resource ('tag'), distinguishing it from siblings like n8n_create_tag (creates new tags) and n8n_delete_tag (removes tags). It precisely defines the tool's function without ambiguity.
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 for when to use this tool ('to standardize tag naming across workflows'), but it does not explicitly mention when not to use it or name specific alternatives. For example, it doesn't contrast with n8n_update_workflow_tags for bulk updates.
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?
The description adds valuable behavioral context beyond annotations: it specifies that structure changes require deactivation first, and it mentions the return value ('Returns updated workflow'). Annotations already indicate it's not read-only, not destructive, idempotent, and open-world, so the description complements this with operational constraints and output information without contradiction.
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 appropriately sized and front-loaded: it starts with the core purpose, lists key updatable elements, states a critical prerequisite, and ends with the return value. Each sentence adds essential information without redundancy or fluff, making it efficient 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 the tool's complexity (mutation with nested objects) and rich annotations (covering safety and idempotency), the description is mostly complete. It adds important behavioral details like deactivation requirements and return values. However, without an output schema, it could benefit from more specifics on the updated workflow format, though the annotations help mitigate this gap.
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 input schema already documents all parameters (id, name, nodes, connections) thoroughly. The description does not add additional meaning or syntax details beyond what the schema provides, such as format specifics for nodes or connections, resulting in a baseline score 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 specific action ('Modify existing workflow structure or settings') and resource ('workflow'), with explicit examples of what can be updated (name, nodes, connections). It distinguishes from siblings like n8n_create_workflow (creation) and n8n_delete_workflow (deletion) by focusing on modification of existing workflows.
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 for usage by stating 'Workflow must be deactivated first for structure changes,' which is a prerequisite condition. However, it does not explicitly mention when to use this tool versus alternatives like n8n_update_workflow_tags (for tag updates only) or n8n_get_workflow (for retrieval), leaving some sibling differentiation implicit rather than explicit.
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?
The description adds valuable context beyond annotations by explicitly stating 'Permanently deletes execution data,' reinforcing the destructive nature (though destructiveHint=true already indicates this). It also mentions the storage-saving benefit and cleanup use case, which provides practical behavioral insight not covered by annotations. No contradiction with annotations exists.
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 highly concise and well-structured with three sentences that each serve a distinct purpose: stating the action and purpose, emphasizing permanence, and providing usage guidelines. There is no wasted verbiage, and key information is 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?
Given the tool's destructive nature (annotations cover safety aspects) and simple single-parameter schema, the description is mostly complete. It explains the purpose, usage context, and permanence effectively. However, without an output schema, it could benefit from mentioning what happens after deletion (e.g., confirmation message or error handling), leaving a minor gap.
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?
With 100% schema description coverage, the input schema already fully documents the single parameter ('Execution ID to permanently remove'). The description does not add any additional parameter-specific information beyond what's in the schema, so it meets the baseline expectation without extra value.
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 specific action ('Remove execution record from history') and resource ('execution record'), distinguishing it from siblings like n8n_get_execution (read) and n8n_list_executions (list). It explicitly mentions the purpose ('to save storage or clean up test runs'), making the intent unambiguous.
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 provides explicit guidance on when to use this tool ('Use after debugging or to maintain clean execution logs'), which helps differentiate it from alternatives like n8n_get_execution for viewing or n8n_retry_execution for re-running. It clearly indicates this is for cleanup purposes rather than operational use.
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?
The annotations already provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating this is a safe read operation that may return partial data. The description adds valuable context about when this tool is appropriate ('rarely needed') and its specific use case ('validating tag existence before bulk operations'), which goes beyond what annotations provide. No contradiction with annotations exists.
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 extremely concise with just two sentences. The first sentence states the purpose, the second provides usage guidance. Every word earns its place with no wasted text, and the most important information (what the tool does) comes first.
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 read operation with good annotations (readOnlyHint, openWorldHint) and complete schema coverage, the description provides appropriate context about when to use the tool and its relationship to sibling tools. The main gap is the lack of output schema, but the description compensates somewhat by indicating what information is returned ('details including ID and name').
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 has 100% description coverage, with the single parameter 'id' clearly documented as 'Tag ID from list_tags'. The description doesn't add any additional parameter information beyond what's in the schema, but with complete schema coverage, the 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 specific action ('Get tag details') and resource ('tag'), and explicitly distinguishes it from the sibling tool 'list_tags' by noting it's 'rarely needed' and that 'list_tags' should be used 'for most cases'. This provides clear differentiation from related tools.
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 provides explicit guidance on when to use this tool ('rarely needed - use list_tags for most cases') and when it is appropriate ('useful for validating tag existence before bulk operations'). It names the alternative tool ('list_tags') and gives a specific use case scenario.
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable context beyond annotations: it specifies access control ('Only available to instance owner'), describes return content ('user profile including role and account status'), and hints at a use case ('verify user details before role changes'). No contradictions with annotations exist.
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 front-loaded with the core purpose, followed by access restrictions, return details, and usage guidance in three concise sentences. Each sentence adds distinct value without redundancy, making it efficient and well-structured for quick comprehension.
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 low complexity (one parameter, no output schema) and rich annotations (readOnlyHint, openWorldHint), the description is largely complete. It covers purpose, access, return values, and usage context. A minor gap is the lack of explicit error handling or rate limit info, but overall it provides sufficient guidance 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 description coverage is 100%, with the parameter 'identifier' fully documented in the schema as 'User ID or email address'. The description adds no additional parameter details beyond what the schema provides, such as format examples or constraints, so it meets the baseline of 3 for high schema coverage.
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 specific action ('Get detailed user information'), resource ('user'), and method ('by ID or email'), distinguishing it from siblings like n8n_list_users (which lists multiple users) and n8n_update_user_role (which modifies roles). It provides a precise verb+resource combination that avoids vagueness or tautology.
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 explicitly states when to use this tool ('to verify user details before role changes'), which implies an alternative like n8n_update_user_role for role changes. It also specifies access restrictions ('Only available to instance owner'), providing clear context for usage versus other user-related tools.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe, non-destructive operation. The description adds valuable context by specifying it 'Returns full workflow JSON with node configurations and data flow', which clarifies the output format beyond what annotations cover.
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 that are front-loaded with the core purpose and efficiently convey usage guidelines without redundancy. Every sentence adds value, making it appropriately sized 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 the tool's low complexity (1 parameter, no output schema), the description is complete enough. It covers purpose, usage, and output format, though it could briefly mention error handling or permissions. With annotations providing safety context, it adequately supports agent decision-making.
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 the 'id' parameter fully documented in the schema. The description does not add any parameter-specific details beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
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 'Get' and resource 'complete workflow definition', specifying it includes 'all nodes, connections, and settings'. It distinguishes from siblings like n8n_list_workflows (which lists workflows) and n8n_execute_workflow (which runs workflows) by focusing on retrieving detailed configuration.
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?
Explicitly states 'Use this to inspect workflow logic before modifying or executing', providing clear when-to-use guidance. It implies alternatives like n8n_update_workflow for modifications and n8n_execute_workflow for execution, though it doesn't name them directly.
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?
Annotations already indicate read-only, non-destructive, and open-world behavior. The description adds valuable context by specifying the return format ('tag ID and name') and the optional limit parameter's effect ('default: all'), which clarifies retrieval behavior beyond the annotations. No contradictions with annotations are present.
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 that are front-loaded with the core purpose and efficiently convey usage guidelines. Every sentence adds value without redundancy, making it appropriately sized and well-structured for quick comprehension.
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 low complexity (one optional parameter), rich annotations (read-only, non-destructive, open-world), and no output schema, the description is largely complete. It covers purpose, usage, and return format, though it could briefly mention pagination or ordering for the list, but this is minor given the context.
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 has 100% description coverage, with the 'limit' parameter fully documented in the schema itself. The description does not add any parameter-specific details beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.
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 specific action ('Retrieve all available tags') and resource ('tags for workflow organization'), distinguishing it from sibling tools like n8n_get_tag (singular) and n8n_get_workflow_tags (tags for a specific workflow). It explicitly mentions the return format ('tag ID and name'), making the purpose unambiguous.
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 provides explicit guidance on when to use this tool: 'Use this before assigning tags to workflows or to see your tagging structure.' This clearly indicates the intended context (pre-assignment or structural review) and implicitly distinguishes it from alternatives like n8n_get_tag (for specific tags) or n8n_get_workflow_tags (for tags on workflows).
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?
Annotations provide readOnlyHint=false, destructiveHint=false, and idempotentHint=false, indicating a non-destructive, non-idempotent write operation. The description adds valuable context beyond annotations: it specifies that it 'Creates new execution while preserving original execution log', clarifying the mutation behavior and log preservation, which annotations don't cover. No contradiction with annotations.
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 sentences with zero waste: first states purpose, second provides usage context, third adds constraints. Each sentence earns its place by adding distinct value (action, use case, limitation). Front-loaded with core functionality.
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 mutation tool with no output schema, the description is reasonably complete: it covers purpose, usage, behavioral traits (creates new execution, preserves logs), and constraints. Annotations provide safety profile (non-destructive, non-idempotent). Minor gap: doesn't specify error handling or return format, but given the context, it's sufficient for agent use.
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 one parameter ('Failed execution ID to retry'), so the schema fully documents the parameter. The description doesn't add any parameter-specific details beyond what's in the schema, but it implies the 'id' must reference a failed execution, which aligns with schema. Baseline 3 is appropriate given high schema coverage.
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 specific action ('Rerun a failed execution') and resource ('execution'), distinguishing it from siblings like 'n8n_execute_workflow' (new execution) and 'n8n_get_execution' (read-only). It specifies the exact scope: only failed executions with the same input data.
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?
Explicitly states when to use ('Only works with failed executions') and provides context ('Useful for transient errors like network timeouts'). It implicitly distinguishes from alternatives like 'n8n_execute_workflow' (new execution) or 'n8n_delete_execution' (destructive).
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?
Annotations cover readOnlyHint=false (mutation), openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context about immediate propagation to workflows, which isn't captured in annotations, enhancing understanding of real-time impact. No contradiction with annotations.
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 with zero waste: the first states purpose and usage context, the second explains a critical behavioral effect. It's front-loaded and efficiently 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?
For a mutation tool with rich annotations (e.g., idempotentHint, openWorldHint) and full schema coverage, the description is largely complete. It adds practical usage context and workflow impact, though lacks output details (no output schema provided), slightly limiting completeness.
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 parameters are fully documented in the schema. The description doesn't add extra semantic details about 'id', 'name', or 'data' beyond what the schema provides, meeting the baseline for high coverage.
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 specific action ('Update credential name or authentication data') and resource ('credential'), distinguishing it from siblings like n8n_create_credential (creation) and n8n_delete_credential (deletion). It precisely defines what can be modified.
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 states when to use this tool ('when rotating API keys or changing OAuth tokens') and provides a key behavioral consequence ('Workflows using this credential will use updated auth immediately'), which helps differentiate from alternatives like n8n_create_credential for initial setup.
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?
The description adds valuable behavioral context beyond annotations: it specifies authorization requirements ('Only available to instance owner') and constraints ('Cannot change owner role'), which annotations do not cover. Annotations indicate this is a non-destructive, idempotent write operation (readOnlyHint: false, destructiveHint: false, idempotentHint: true), and the description does not contradict these, instead complementing them with practical usage details.
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 and well-structured, with four sentences that each add value: the first states the purpose, the second specifies authorization, the third explains role semantics, and the fourth sets a constraint. There is no redundant or wasted information, making it efficient and easy to parse.
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 (a mutation with authorization constraints), the description is mostly complete: it covers purpose, usage, and behavioral traits. However, without an output schema, it does not describe return values or error cases, leaving a minor gap. Annotations provide safety and idempotency hints, but the description could benefit from mentioning response format or potential errors.
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 has 100% description coverage, clearly documenting both parameters (id and role with enum values). The description adds minimal parameter semantics beyond the schema, only implying that 'role' affects permission levels (e.g., 'Admin can manage workflows and credentials. Member has view-only or limited edit access'), which provides some context but is not essential given the schema's completeness.
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 ('Change') and resource ('user permission level'), making the purpose specific and actionable. It distinguishes this tool from sibling tools like n8n_get_user (which reads user data) and n8n_delete_user (which removes users), as it focuses on modifying role permissions rather than retrieving or deleting.
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 provides explicit usage guidelines: it specifies when to use ('Change user permission level'), when not to use ('Cannot change owner role'), and prerequisites ('Only available to instance owner'). It also implicitly distinguishes from alternatives like n8n_get_user for viewing roles, offering clear context for tool selection.
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?
The description adds valuable behavioral context beyond annotations: it clarifies that tag assignment is a complete replacement ('Replaces existing tags completely'), mentions automatic creation of missing tags, and provides usage examples ('Use tags like "production", "testing", or team names'). Annotations cover idempotency and non-destructive nature, but the description enriches this with practical details.
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 efficiently structured in three sentences: purpose, behavioral detail, and usage guidance. Each sentence adds distinct value without redundancy, making it easy to parse and understand quickly.
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 mutation tool with good annotations (idempotent, non-destructive) and full parameter documentation, the description provides excellent context about behavior and usage. The main gap is the lack of output schema, but the description compensates well by explaining the operation's effect. It could slightly improve by mentioning error conditions or permissions.
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?
With 100% schema description coverage, the input schema already documents both parameters thoroughly. The description adds minor context about the 'tags' parameter being a 'complete array' and suggests example values, but doesn't provide significant additional semantic meaning beyond what's 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 specific action ('Assign tags'), target resource ('to a workflow'), and purpose ('for organization and filtering'). It distinguishes from sibling tools like n8n_get_workflow_tags (which retrieves tags) and n8n_update_workflow (which likely updates broader workflow properties).
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 provides explicit guidance on when to use this tool ('Assign tags to a workflow for organization and filtering') and when not to use it ('Replaces existing tags completely'), with clear alternatives implied through sibling tools like n8n_create_tag for tag creation and n8n_get_workflow_tags for retrieval.
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?
While annotations already indicate this is a destructive, non-readOnly operation, the description adds valuable behavioral context not covered by annotations: the constraint about active workflows, the need to deactivate workflows first, and the warning about potential workflow breakage. This goes beyond what annotations provide without contradicting them.
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 extremely concise yet information-dense. Every sentence earns its place: the first states the purpose, the second provides critical constraints, the third gives prerequisites, and the fourth warns about consequences. No wasted words, and the most important information comes first.
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 destructive operation with comprehensive annotations (destructiveHint, idempotentHint, etc.), the description provides exactly what's needed: clear purpose, usage constraints, prerequisites, and warnings. The combination of annotations and description gives complete context for this tool's use.
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 schema has 100% description coverage with the parameter 'id' clearly documented as 'Credential ID to permanently delete'. The description doesn't add any additional parameter semantics beyond what the schema already provides, so the 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 specific action ('Remove stored credential') and resource ('credential'), distinguishing it from sibling tools like n8n_create_credential or n8n_update_credential. It goes beyond just restating the name/title by specifying what type of object is being deleted.
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 provides explicit guidance on when NOT to use this tool ('Cannot delete credentials currently used in active workflows') and what prerequisites are needed ('Deactivate dependent workflows first'). It also warns about consequences ('Use with caution as this may break workflows'), giving clear context for appropriate usage.
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:

[![n8n-management-mcp-community MCP server](https://glama.ai/mcp/servers/node2flow-th/n8n-management-mcp-community/badges/card.svg)](https://glama.ai/mcp/servers/node2flow-th/n8n-management-mcp-community)

Score Badge

Copy to your README.md:

[![n8n-management-mcp-community MCP server](https://glama.ai/mcp/servers/node2flow-th/n8n-management-mcp-community/badges/score.svg)](https://glama.ai/mcp/servers/node2flow-th/n8n-management-mcp-community)

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/node2flow-th/n8n-management-mcp-community'

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