n8n MCP Server (Custom)

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation5/5
Each tool targets a distinct resource and action (e.g., list_workflows vs. get_workflow vs. execute_workflow). Even similar tools like get_instance_info and get_instance_version are clearly separated by their descriptions (health vs. version/settings). No two tools appear to do the same thing.
Naming Consistency5/5
All tools follow the same n8n_verb_noun pattern, with verbs like list, get, create, update, delete, execute, stop, activate, deactivate. The naming is uniform and predictable, with no mixed conventions.
Tool Count4/5
27 tools is on the higher side, but the server covers a broad domain (workflows, executions, credentials, variables, tags, node types, instance info). Each tool serves a clear purpose within that scope, so the count feels justified rather than bloated.
Completeness4/5
The toolset provides solid CRUD/lifecycle coverage for workflows, credentials, variables, and executions. Minor gaps exist, such as no create/update/delete for tags and no workflow import/export, but the core workflows an agent would need are well covered.
Average 3.2/5 across 27 of 27 tools scored. Lowest: 2/5.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only says 'create a new workflow' and gives no details about side effects, return values, default states (e.g., active=false), authentication needs, or validation behavior. This is a complete lack of behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one short sentence, but it provides almost no useful content beyond the tool name. This is under-specification rather than conciseness. It does not even mention the required parameters (name and nodes) or any operational context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 5 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what happens on success, what the response looks like, or any constraints on the workflow structure. The schema covers the fields but the tool's behavior and practical use remain unexplained.
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% coverage with descriptions for all 5 parameters, including default values (e.g., active defaults to false). The description adds no additional parameter information, but the schema already does a sufficient job. This matches 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Crear un workflow nuevo en n8n' is essentially a restatement of the tool name 'n8n_create_workflow'. It does not add any specific detail about what creating a workflow involves or how it differs from sibling tools like update or delete. This qualifies as a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as n8n_update_workflow or n8n_delete_workflow. There is no mention of prerequisites, typical scenarios, or when not to use it. The only implied usage is the obvious fact that it creates a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the deletion action, which implies a destructive operation, but it does not mention irreversible side effects, permission requirements, or behavior when the variable does not exist. The minimal phrasing leaves significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specification rather than concise. It provides no information beyond the tool's name, failing to earn its place, and does not front-load any unique value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, this description is incomplete. It lacks context about permanence, prerequisites, error handling, or what happens after deletion. For such a simple tool, more detail about the deletion's effects is needed to be 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?
The input schema already provides 100% coverage for the single parameter variable_id with a description. The tool description adds no extra meaning beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Eliminar una variable' directly translates to 'Delete a variable,' which restates the tool name n8n_delete_variable. It provides no additional scope or differentiation from siblings like n8n_delete_workflow or n8n_delete_credential, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or consequences. It simply states the action without any contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'update existing credential' without explaining side effects, partial vs. full update behavior, required permissions, or reversibility. This is nearly tautological and adds no context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence but is under-specified. It essentially restates the tool name without providing any valuable context, failing to 'earn its place' with useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update tool with no annotations and no output schema, the description is incomplete. It does not mention update semantics (e.g., whether it merges or replaces), auth requirements, or return value, leaving the agent with insufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The description adds no additional parameter meaning, but the schema already documents data, name, and credential_id adequately, so the baseline of 3 applies.
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 'Actualizar una credencial existente' clearly states the action (update) and resource (credential), distinguishing it from create, delete, and list operations. It is specific enough to identify the tool's purpose, though it lacks detail on what aspects can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_credential or delete_credential. There are no mentions of prerequisites, conditions, or scenarios that favor this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention whether creating a credential with an existing name is allowed, what happens on success/failure, or any required permissions. The description merely says 'create a new credential' without further behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but this is under-specification rather than conciseness. It says almost nothing beyond the tool's name, providing little added value for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a create operation with no output schema and no annotations, the description is inadequate. It does not explain the expected structure of the 'data' object, return values, error handling, or any validation constraints beyond the minimal schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters, resulting in 100% coverage. The description itself adds no additional meaning beyond the schema, so the baseline score of 3 applies.
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 (create) and resource (credential), making the purpose understandable. However, it does not explicitly distinguish itself from sibling tools beyond the verb, and the description is essentially a restatement of the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like n8n_get_credential, n8n_update_credential, or n8n_delete_credential. It does not mention any prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, but it only states the basic purpose. It does not reveal whether the update is a patch or full replacement, whether fields not specified are reset, error handling for nonexistent workflows, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that essentially restates the tool name. While not verbose, it lacks sufficient substance to be considered concise in a meaningful way; under-specification makes it less than effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, nested objects, and no output schema or annotations. The description provides only a one-line purpose lacking behavioral context, return value expectations, or update semantics, making it inadequate for safe and correct 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 input schema has 100% coverage, with each parameter having a brief description. The tool description itself adds no extra parameter context, so the baseline score of 3 is appropriate given the schema's completeness.
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 'Actualizar un workflow existente' clearly states the action (update) and the resource (existing workflow). It distinguishes from create/delete/get/list siblings, though it does not explicitly differentiate from activate/deactivate workflows. Overall, the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like n8n_create_workflow or n8n_activate_workflow. There is no mention of prerequisites, partial vs. full updates, or scenarios where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, and the description merely restates the tool's name ('Eliminar un workflow') without disclosing that deletion is permanent, cascades to executions, or requires special permissions. For a destructive operation, this complete lack of behavioral disclosure is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action, with no redundant words. While extremely terse, it is appropriately sized for a one-parameter delete tool, though it sacrifices informational depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a minimal description, the tool lacks important contextual details such as return values on success, possible errors, or whether the workflow must be deactivated before deletion. For a destructive operation, the description is insufficiently 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?
The schema provides 100% description coverage for workflow_id, including its type and description. The tool description adds no additional parameter details; the baseline is 3 for high coverage, and no further value is contributed.
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 uses a specific verb ('Eliminar'/'delete') and resource ('workflow'), clearly distinguishing it from sibling operations like n8n_update_workflow, n8n_activate_workflow, and n8n_get_workflow. It unambiguously identifies the action 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to delete versus deactivate a workflow, nor any prerequisites such as deactivating the workflow first. The sibling n8n_deactivate_workflow offers an alternative that is not mentioned, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action of getting a variable, without mentioning what is returned, error handling, permissions, or side effects. For a getter, the return format and behavior on missing IDs are critical but not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. There is no unnecessary information, and it is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no annotations, and no output schema. The description explains the basic action but omits the return value, error conditions, and any other behavioral context. For a get operation, this leaves the agent without sufficient information to handle the response properly.
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 fully documents the single parameter 'variable_id' with a description, achieving 100% schema coverage. The description adds only 'by its ID', which is redundant with the parameter name. The schema carries the semantic weight, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: retrieve a specific variable by its ID. It uses a specific verb 'Obtener' and identifies the resource 'variable'. It distinguishes from n8n_list_variables by emphasizing 'una variable específica' and 'por su ID', though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention that listing all variables requires n8n_list_variables, nor does it explain prerequisites such as needing a valid variable_id. No exclusionary or alternative context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely says 'update an existing variable' and does not explain partial-update semantics, what happens to omitted fields, authentication needs, or return behavior. This is a mutation tool with zero behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, and it is front-loaded with the action. However, it is underspecified for a tool with four parameters, omitting what fields can be updated and how optionality behaves, making it minimally acceptable rather than effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with four parameters and no output schema, this description is insufficient. It does not explain that key/type/value are optional, whether the update is partial or full, or what the tool returns. It lacks enough context for an agent to invoke it confidently.
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 description coverage is 100%, with each parameter labeled 'opcional' and the required variable_id explained. The description adds no parameter information, but the schema already provides the necessary semantic details, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'actualizar' and identifies the resource as 'una variable existente', clearly distinguishing this update operation from sibling tools like create, get, or delete variable. It communicates exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existente' implies the tool is for variables that already exist, but it does not explicitly state when to use it versus alternatives like n8n_create_variable or n8n_delete_variable. There is no when-not-to-use guidance, only a minimal implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action 'activate' with no mention of side effects, permissions, or state changes, leaving the agent without critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no wasted words. It front-loads the action and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a single well-documented parameter, but the description lacks context about the activation's effect, prerequisites, or response. Given no annotations and no output schema, it is minimally complete but leaves 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?
The input schema fully describes the only parameter with 100% coverage, so the description adds no additional meaning. The baseline of 3 applies because the schema handles parameter documentation.
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 uses a specific verb 'activar' and resource 'workflow', clearly indicating the tool activates a workflow. However, it does not explicitly differentiate from sibling tools like n8n_deactivate_workflow, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool or alternatives. It does not mention conditions, prerequisites, or contrast with n8n_deactivate_workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the behavioral burden. It only restates the action ('deactivate a specific workflow') without disclosing side effects, reversibility, permissions, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded and efficient. It conveys the core action without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description lacks usage guidance and behavioral context. With no annotations or output schema, it does not fully equip an agent to understand the implications of deactivation or when to choose this over related tools.
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 fully documents the single workflow_id parameter with a description (100% coverage), so the tool description adds no extra semantic value beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deactivates a specific workflow, using a precise verb and resource. This distinguishes it from sibling tools like n8n_activate_workflow and n8n_delete_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as n8n_activate_workflow or n8n_delete_workflow. No prerequisites, triggers, or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only says 'list recent executions' and 'can limit results', omitting details like the default limit, filtering by status/workflow_id (present in schema but not described), sorting, and the response structure. This is minimal for a tool with zero annotation support.
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 consists of two short sentences that are direct and free of redundant information. It front-loads the main purpose ('list recent executions') and mentions limit capability without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain the return value. It does not mention what data is returned for each execution, nor does it address pagination or the distinction from the singular execution retriever. The description leaves significant context unaddressed for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. The description only adds that results can be limited, which is already evident from the 'limit' parameter description. No extra semantic meaning is provided beyond the schema.
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 explicitly states 'Listar ejecuciones recientes' (List recent executions), providing a clear verb and resource. It distinguishes from the singular n8n_get_execution by indicating a list of executions. However, it doesn't mention the filtering capabilities (status, workflow_id) which are key to its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus n8n_get_execution or n8n_stop_execution. The plural 'ejecuciones' and 'listar' imply its use case for retrieving multiple executions, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only mentions testing connectivity and permissions, but does not explain what actions are performed, whether it makes any modifications, or what the response contains. This is minimal and lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that directly states the purpose. It is concise and front-loaded, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides a basic purpose but lacks details on what the test entails, how results are presented, or any behavioral implications. It is adequate but leaves gaps in understanding what 'connectivity and permissions' actually covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage). According to the baseline, a score of 4 is appropriate since there are no parameters to explain, and the description does not need to compensate for missing schema details.
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 tool tests connectivity and permissions with n8n, using a specific verb ('Probar' = test) and a distinct resource. It distinguishes itself from sibling tools that perform CRUD or execution operations, though it could be more specific about what exactly is tested.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It is implied as a self-test, but there is no explicit mention of scenarios, exclusions, or alternative tools for similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No hay anotaciones que cubran mutabilidad o seguridad, y la descripción no añade transparencia sobre efectos colaterales como el comportamiento ante una clave existente, permisos necesarios o reversibilidad. La única información es que crea una variable, lo cual es insuficiente para un tool de mutación sin anotaciones.
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?
La descripción es una sola frase corta, directa y sin información redundante. Cumple con la concisión deseada y está bien estructurada para su propósito.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Para una herramienta simple con esquema completo, la descripción cubre lo esencial, pero carece de orientación de uso y de detalles sobre comportamiento/permisos. No hay output schema, pero la funcionalidad es básica; aún así, los vacíos en transparencia y uso le restan completitud.
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?
El input schema ya cubre el 100% de los parámetros con descripciones, por lo que la descripción no necesita repetirlos. Sin embargo, no añade ningún matiz adicional sobre los parámetros ni ofrece ejemplos o restricciones semánticas más allá del esquema.
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?
La descripción 'Crear una nueva variable de entorno' especifica un verbo claro ('crear') y un recurso concreto ('variable de entorno'), distinguiéndose de las herramientas hermanas como listar, obtener, actualizar o eliminar variables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No se indica cuándo usar esta herramienta frente a alternativas (p. ej., listar, actualizar o eliminar), ni se mencionan restricciones, condiciones previas o situaciones en las que convendría otra herramienta. Solo se implica su uso para crear una variable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It implies a read-only operation via 'Obtener', but does not mention error handling, return format, or potential side effects. This is a minimal level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the purpose. It is front-loaded and contains no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one well-documented parameter and no output schema, the description is functional but sparse. It does not specify what information is returned or provide additional usage context. It meets the minimum bar but lacks richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the 'node_type' parameter with an example. The tool description adds no additional meaning beyond what the schema provides, so it scores at the baseline for a high schema coverage of 100%.
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 function: 'Obtener información sobre un tipo de nodo concreto' (Get information about a specific node type). The verb 'Obtener' and resource 'tipo de nodo' are specific, and the word 'concreto' distinguishes it from sibling tools like n8n_list_node_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as n8n_list_node_types. The 'concreto' hint implies a focused use, but no direct comparison, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It adds the caveat that stopping may not be permitted ('si tu instancia lo permite') and that it is an attempt ('Intentar'), which is useful context. However, it does not disclose what happens on success or failure, whether the execution must be running, or the return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that gets straight to the point. It is appropriately sized for the tool's simplicity, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but adequate for a one-parameter action: it states the action and a key caveat. However, without annotations or an output schema, it leaves the agent uncertain about the result of the call and any error handling. Given the tool's simplicity, a bit more detail on behavior after the call would improve 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 single parameter execution_id is fully documented in the schema with 100% coverage. The tool description adds no additional parameter semantics beyond what the schema already 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: try to stop a running execution. It specifies the resource (execution) and the scope ('en curso'), which helps distinguish it from sibling tools like n8n_get_execution. However, the word 'Intentar' (try) introduces slight ambiguity about whether it actually stops or just attempts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The only condition mentioned is 'si tu instancia lo permite' (if your instance allows it), which is a prerequisite, not a usage guideline. It does not reference alternative tools or scenarios where stopping an execution would be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only restates the delete action, offering no information about permanence, irreversibility, required permissions, or potential side effects. This adds no value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the verb and resource. It contains no redundant or filler content, making it appropriately concise for such a straightforward operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool is a destructive operation with no annotations and no output schema, yet the description only states the action. It fails to mention whether deletion is permanent, if any confirmation is needed, or any other behavioral context. The description is insufficient for an agent to fully grasp the operation's implications.
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 already documents the single parameter, credential_id, with a description ('ID de la credencial'), and coverage is 100%. The description does not add any extra semantic detail, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description, 'Eliminar una credencial,' clearly states a specific verb (delete) and a specific resource (credential). It unambiguously distinguishes this tool from siblings like n8n_get_credential, n8n_create_credential, and n8n_update_credential.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The usage is implied by the tool name and sibling context, but the description itself does not offer any contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only says the tool gets health information, implying a read-only operation, but it does not disclose what the response contains, whether any side effects occur, or authentication requirements. For a background read tool, this is minimal disclosure and leaves the agent guessing about the actual return payload and safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Spanish that conveys the tool's purpose without redundant wording. It is front-loaded with the key information and avoids any filler, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what information is returned (e.g., status, uptime, version, error rates). It only says 'health information' vaguely, leaving the agent uncertain about the exact response structure. Also, it does not clarify how this differs from n8n_self_test, which might also provide health diagnostics. The description is too sparse for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter semantics to clarify. The baseline for zero parameters is 4, and the description adds no unnecessary detail. The tool simply takes no inputs, which is clear from 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 'Obtener información de salud de la instancia n8n' clearly states a specific verb ('obtener') and resource ('información de salud de la instancia'). This differentiates it from sibling tools like n8n_get_instance_version (which fetches version) and n8n_self_test (which might run tests), making its purpose distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or contrast with sibling tools like n8n_self_test. There is no explicit usage context beyond the basic capability, so the agent receives no help in selecting this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action and target, but does not disclose return format, error handling, or read-only nature. This is a minimal statement with no added behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. Every word contributes meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple one-parameter schema but lacks annotations and an output schema. The description does not explain what the response will contain, how errors are handled, or differentiate usage from sibling tools. It is too thin for an agent to fully understand the tool's behavior.
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%, and the parameter description 'ID del workflow' is clear. The tool description repeats 'por id' but adds no new meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtener un workflow concreto por id' uses a specific verb (obtener/get), identifies the resource (workflow), and scopes it to a specific item by id. This clearly distinguishes it from list_workflows or other CRUD siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific workflow id is known, but it does not explicitly state when to use this tool versus alternatives like list_workflows or create/update/delete. There is no explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. However, it only states the purpose without mentioning that it is a read-only operation, what response format to expect, or any potential error conditions. Minimal value beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that is front-loaded with the action and resource. It contains no unnecessary words and effectively communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description is adequate but minimal. It does not specify what 'details' are included, any constraints, or what the return value looks like, which would improve 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 coverage is 100% with the parameter 'execution_id' described as 'ID de la ejecución.' The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Obtener' (get) with the resource 'detalles de una ejecución concreta' (details of a specific execution), clearly distinguishing it from the sibling n8n_get_executions which lists executions. It effectively communicates that this tool retrieves details for a single execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'una ejecución concreta' implies it is for a specific execution, but there is no explicit guidance on when to use this tool versus alternatives like n8n_get_executions or n8n_stop_execution. No direct alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden. The word 'obtener' (get) implies a safe read operation, but no additional behavioral context is provided, such as response structure, authentication requirements, or potential side effects. This is minimally adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It effectively communicates the tool's purpose in minimal space.
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 zero-parameter tool, the description is largely complete. It covers what the tool retrieves, though it does not differentiate from n8n_get_instance_info, leaving some ambiguity in selection. The absence of an output schema means the description should mention return values, which it partially does by naming 'version and settings.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description adds clarity about the output (version and settings), but there are no parameter semantics to explain.
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 'Obtener versión y ajustes de la instancia n8n' clearly indicates the tool retrieves version and settings, with a specific verb and resource. However, it does not distinguish itself from the sibling tool n8n_get_instance_info, which likely overlaps in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like n8n_get_instance_info. The description is purely declarative and lacks any contextual cues about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it lists workflows, but does not disclose whether this is a read-only operation, whether pagination is involved, what data fields are returned for each workflow, or any potential side effects. This is a significant gap for a tool with no other behavioral metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that effectively communicates the tool's purpose. There is no redundant or extraneous information, and it is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema and no annotations, the description is minimally viable but lacks detail about the return value. It does not specify whether the response contains full workflow objects, summaries, or just IDs, which could be important for an agent deciding how to process the result. Given the simple nature, a score of 3 reflects the clear gap in return-value information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the baseline is 4. The description adds no parameter information, but none is needed. The action 'list all' sufficiently conveys the operation without requiring parameter details.
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 'Listar todos los workflows de n8n' clearly states the tool lists all n8n workflows, using a specific verb (list) and resource (workflows). This distinguishes it from sibling tools like n8n_get_workflow, which retrieves a single workflow, and n8n_list_credentials, which lists credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that n8n_get_workflow should be used for a specific workflow, nor does it mention any exclusions (e.g., returns summaries only). The usage context is merely implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether execution is synchronous or asynchronous, what it returns, or any side effects. For a tool that triggers workflow runs, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role as an execution trigger with side effects, and the absence of an output schema and annotations, the description leaves critical questions unanswered (e.g., return value, asynchronous behavior, workflow activation requirements). It is underspecified for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for both parameters. The description adds a minor clarification ('body directo') about how the payload is sent, but does not significantly augment schema semantics.
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 ('Ejecutar un workflow') with a specific verb and resource. It is distinct from sibling tools, which focus on CRUD or listing operations. Mentioning optional input data adds further clarity.
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 phrase 'con datos de entrada opcionales (body directo)' gives context on how the payload is used. It does not explicitly name alternatives, but among siblings it is the only execute tool, making its usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must stand alone. It states the tool retrieves a specific credential but does not disclose any behavioral details such as error handling, required permissions, or whether the credential contains sensitive data. The description adds little beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Spanish, front-loaded with the verb and clear. There is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get tool, the description covers the core purpose, but with no annotations or output schema, it lacks any mention of return format or error behavior. It's minimally complete but leaves some 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?
The schema already fully describes the only parameter (credential_id) with a description, and the tool description repeats the 'by id' concept. With 100% schema coverage, the description adds minimal additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtener una credencial concreta por id' clearly states the action (obtener/get), the resource (credential), and the criterion (by id). It distinguishes from list_credentials and other get tools by emphasizing 'concreta' (specific) and 'por id' (by ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives like n8n_list_credentials. The usage is implied by the name and description – if you need a specific credential by ID – but no explicit context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action 'list all tags' but does not disclose the return format, whether it is read-only (though implied), any required permissions, or potential limitations like pagination or sorting. This is minimal behavioral disclosure for a tool with no annotation safety cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded with the action and resource. Every word contributes value, with no redundancy or filler. It is an ideal example of concise tool documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description is adequate but minimal. It states the operation and scope but does not describe the structure of tag objects or any response details, which could be helpful. Given the simplicity of the tool, the description covers the basic context, though more detail about the return shape would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to add parameter meaning because there are none. The schema already confirms no parameters, and the description's mention of 'all tags' aligns with the no-filter nature of the tool.
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 uses a specific verb 'Listar' (list) with a clear resource 'tags' and context 'configurados en n8n' (configured in n8n). It unambiguously distinguishes this from all sibling tools, as no other tool deals with tags. The inclusion of 'todos' (all) also clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to retrieve a list of all tags, but it does not provide explicit guidance on when to use it vs. alternatives. Since there are no other tag-related sibling tools, the purpose itself is the primary usage signal. No exclusions or alternative contexts are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only list operation but does not state return format, pagination, or whether node-type definitions are included. For a simple list tool, the basic behavior is evident, but disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's action and scope. No filler 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?
The tool is simple, with no parameters and no output schema. The description covers the core purpose effectively. It could be enhanced by mentioning what the returned list contains (e.g., node type IDs vs. full details), but overall it is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameters (0 params), so schema coverage is trivially 100%. The description adds no parameter-specific details, but none are needed. Per the rubric, 0 params earns a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('listar') and resource ('tipos de nodo') and clearly indicates scope ('todos los disponibles en la instancia'). This distinguishes it from the sibling n8n_get_node_type, which fetches a single node type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes plain that the tool lists all node types, but does not explicitly contrast it with alternatives like n8n_get_node_type or state when not to use it. Context is clear but exclusions/alternatives are not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. 'Listar' implies a read-only operation, but the description does not state return format, whether variables are shown with values, or any pagination/limitations. It adds minimal information beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Spanish that fully conveys the purpose without unnecessary words. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is mostly sufficient. It could mention what the list contains (e.g., variable names, values) but the core intent is clear. The minimal context is acceptable for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. The description adds no parameter-specific details, but with no parameters to explain, the baseline is 4 per the rubric. The description correctly implies that no arguments are needed.
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 function: 'Listar todas las variables de entorno configuradas en n8n.' It uses a specific verb ('list') and resource ('variables'), and the name 'n8n_list_variables' matches. It distinguishes from sibling tools like 'n8n_get_variable' (single variable) and CRUD operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—when you need to list all environment variables. However, it does not explicitly mention alternatives (e.g., 'n8n_get_variable' for a single variable) or provide exclusions. For a simple list tool, the context is clear but not fully 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?
With no annotations, the description carries the full burden. It explicitly discloses that only metadata is returned and no secrets, which is a critical behavioral trait. It does not mention pagination or authentication, but for a simple list operation 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 a single, front-loaded sentence with no wasted words. It delivers the core purpose and a key differentiator in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with no output schema, the description fully covers what it does and what it returns (metadata only, no secrets). It is appropriately complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds no parameter details because none exist, but it clarifies the nature of the returned data, which complements the schema's emptiness.
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 'Listar' (list) and the resource 'credenciales' (credentials), with the scope 'todas' (all). The parenthetical clarification 'solo metadatos, no secretos' distinguishes it from credential-specific tools like get_credential or create/update/delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'solo metadatos, no secretos' implies it is used for metadata-only listing and not for retrieving secret values, but it does not explicitly mention alternatives or when not to use this tool. Usage context is implied, not stated.
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-mcp-server-custom MCP server](https://glama.ai/mcp/servers/burnham/n8n-mcp-server-custom/badges/card.svg)](https://glama.ai/mcp/servers/burnham/n8n-mcp-server-custom)

Score Badge

Copy to your README.md:

[![n8n-mcp-server-custom MCP server](https://glama.ai/mcp/servers/burnham/n8n-mcp-server-custom/badges/score.svg)](https://glama.ai/mcp/servers/burnham/n8n-mcp-server-custom)

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/burnham/n8n-mcp-server-custom'

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