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

Annotations already declare readOnlyHint and idempotentHint. Description adds substantial behavioral context: token estimates for detail levels, mode behaviors, and default values. 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.

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

Three sentences, front-loaded with purpose, then detail and mode explanations, ending with usage tips. Every sentence adds value; no redundancy.

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

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

Covers key output characteristics (token estimates) and mode behaviors. Could mention response format or structure, but given read-only nature and no output schema, it is sufficiently complete for an info-retrieval tool.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by clarifying token estimates for detail levels and usage advice for modes (e.g., 'standard=essential properties (recommended)'), exceeding minimal schema info.

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

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

The description clearly states 'Get node info' with specific verb and resource. It distinguishes from sibling tools like search_nodes and validate_node by focusing on retrieving schema info with detail levels and modes.

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

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

Provides explicit guidance for mode usage: 'Use format="docs" for readable documentation, mode="search_properties" with propertyQuery for finding specific fields.' Does not explicitly exclude scenarios, but context is clear.

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

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

Annotations declare readOnlyHint and idempotentHint, indicating safe, read-only behavior. The description adds detail about mode options, which is consistent and useful beyond what schema provides.

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

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

Two sentences: first states purpose, second explains mode. No redundancy, front-loaded, and every word adds value.

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

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

For a simple retrieval tool with two parameters and no output schema, the description is adequate. It covers purpose and parameter usage. Could mention permissions or return format, but not critical given annotations.

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

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

Schema coverage is 100% with descriptions. The description adds a concise summary of mode options with their meanings, supplementing the enum descriptions.

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

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

The description clearly states the tool retrieves a template by ID, with a specific verb and resource. It distinguishes from sibling tools like n8n_deploy_template or validate_workflow, which have different purposes.

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

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

The description provides guidance on using the 'mode' parameter to control response size, but does not explicitly state when to use this tool over alternatives. However, the purpose is clear enough.

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

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

Annotations confirm read-only, idempotent, and non-destructive behavior. The description adds value by detailing the deep workflow scanning (50+ regex patterns), checks (unauthenticated webhooks, etc.), and output format (markdown report). No contradictions 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.

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

The description is two sentences long, front-loaded with the tool's purpose, and provides specific details without unnecessary words. Every sentence adds value.

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

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

Given 4 parameters, no output schema, and a complex tool, the description covers the audit scope, checks, and output type. It mentions remediation using sibling tools, which aids completeness. Could include more on output structure, but sufficient for an audit tool.

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

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

All 4 parameters have schema descriptions (100% coverage). The description mentions 'all 5' and 'all 4' default checks, which is already in the schema. It does not add significant meaning beyond the schema, earning the baseline 3.

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

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

The description clearly states 'Security audit of n8n instance' and lists specific areas (credentials, database, nodes, instance, filesystem) and custom checks. It distinguishes from sibling tools by focusing on auditing and remediation, not workflow management or creation.

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

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

The description mentions returning an actionable markdown report with remediation steps using sibling tools, implying when to use it (for security audit). However, it does not explicitly state when not to use it or provide alternatives, though the read-only nature suggests safe usage anytime.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false, consistent with a non-destructive fixer. The description adds that fixes can be previewed or applied, and lists specific issue types. No contradictions.

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

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

The description is concise, front-loading the action and purpose in a single short paragraph. Every sentence adds value without redundancy.

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

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

The description covers what the tool does and lists fix types, but does not describe the output format or return value. Given no output schema, this is a gap for agents needing to parse results.

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

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

Schema coverage is 100%, so baseline 3. The description lists fixTypes but does not add significant meaning beyond the enum values. Parameters are adequately described in the schema.

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

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

The description clearly states the tool automatically fixes common workflow validation errors, with explicit examples of fix types (expression format, typeVersion, etc.). It distinguishes from sibling tools like validate_workflow by mentioning both preview and apply modes.

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

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

The description implies usage for fixing validation errors but does not provide explicit when-to-use vs when-not-to-use guidance or compare with alternatives like manual updates via n8n_update_*. No exclusions mentioned.

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

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

The description meaningfully supplements the annotations: it states the workflow is created inactive, requires the three core fields up front so an agent won't attempt degenerate calls, and notes the ID is returned. It also preserves schema nuances like nodeGroups being dropped on older versions in the schema itself. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

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

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

The description is terse and front-loaded: the verb, the object, and the essential requirements appear in the opening sentence, with the outcome (inactive, gets ID) in a single follow-up. Every sentence earns its place; no redundant prose.

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

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

For a create action with a rich input schema and clear annotations, the description plus schema fully cover what an agent needs: required fields, optional settings, folder placement, enterprise projectId, behavior (inactive), return value, and version-specific caveats like nodeGroups and parentFolderId. No output schema is present, but the description explicitly states the returned workflow includes an ID, which is sufficient for a create call.

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

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

Schema description coverage is 100%, so the baseline is 3. The description itself mostly recaps the required names, while the schema already explains nodes, settings, projectId, nodeGroups, parentFolderId, and connections. The only added context is 'Created inactive' and the return of the workflow ID. The schema does the heavy lifting, so no more than a 3 is warranted.

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

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

The description states a clear verb and resource ('Create workflow') and enumerates requirements, which distinguishes it from update/delete/list siblings. It lacks an explicit differentiator naming which sibling to use instead, but the action is unambiguous enough for an agent to route correctly.

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

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

The description implies when to use: when creating a new workflow, and the schema clarifies required fields. It doesn't explicitly contrast with n8n_update_full_workflow or n8n_update_partial_workflow, nor mention validation steps like validate_workflow. Context is present but exclusions/alternatives are left to inference.

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

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

The description reinforces the destructive hint from annotations by stating 'cannot be undone', but adds no new behavioral details beyond what annotations already provide.

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

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

Extremely concise with two sentences, no superfluous information, and the key point is front-loaded.

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

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

For a simple deletion tool with one parameter and annotations covering destructiveness, the description is adequate; however, it does not specify return value or confirmation behavior.

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

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

Schema coverage is 100% and the description adds no extra meaning to the single parameter (id) beyond its schema documentation.

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

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

The description clearly states the action (permanently delete) and the resource (workflow), distinguishing it from sibling tools like creation or listing.

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

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

No guidance on when to use this tool versus alternatives, no conditions or prerequisites mentioned, and no indication of when deletion is appropriate.

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

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

Annotations indicate it's a write operation (readOnlyHint: false) and not destructive. The description adds context: deploys first then auto-fixes common issues, and returns workflow ID, required credentials, and fixes applied. This adds value beyond annotations.

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

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

Description is concise with two sentences: first states the main action, second summarizes key feature and output. No unnecessary words.

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

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

Given five parameters and no output schema, the description lacks details on parameter behavior (e.g., what happens if autoFix is false), error cases, or prerequisites. It covers the core but leaves gaps.

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

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

Schema coverage is 100% and each parameter is well-described in the schema. The description does not add meaningful detail beyond what the schema provides, so baseline 3 is appropriate.

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

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

Description clearly states the tool deploys a workflow template from n8n.io to the instance, with specific verb 'deploy' and resource 'workflow template from n8n.io'. It distinguishes from siblings like n8n_create_workflow or n8n_update_full_workflow by focusing on marketplace templates.

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

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

The description implies usage for deploying marketplace templates but does not explicitly state when to use this versus n8n_create_workflow or other sibling tools. No guidance on prerequisites or exclusions.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses version gating, API key scope requirements, the need for workflow:execute permission, and a performance warning for list_cases ('paginate - cases can be large'). It also explains what cancel does ('stop a running run'). 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.

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

The description is three sentences, front-loaded with a clear summary and then requirements and an action list. Every sentence carries substantive information (prerequisites, action semantics, pagination warning) with no filler or repetition.

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

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

Given no output schema, the description explains key return concepts: 'aggregated metrics' for get_run, 'per-case results' for list_cases, and 'list runs for a workflow' for list_runs. It also covers prerequisites, action semantics, and pagination guidance. This is complete for a multi-action tool with six parameters.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining run requires an evaluation trigger, get_run returns aggregated metrics, and list_cases can be large and needs pagination, which enriches the meaning of the action parameter and relates to limit/cursor. It does not cover all parameters, but it goes beyond the schema.

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

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

The description opens with 'Run and read evaluation test runs for a workflow,' which is a specific verb+resource statement. It clearly distinguishes this tool from siblings like n8n_executions and n8n_test_workflow by focusing on 'evaluation' test runs, and then enumerates the five actions.

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

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

The description provides explicit context for when the tool can be used, including version requirements (n8n >= 2.30 for reading, >= 2.32 for run/cancel) and permission requirements (API key scope, workflow:execute). It does not name alternative tools for exclusion, but the 'evaluation' qualifier and action list make the intended use clear.

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

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

Annotations already indicate destructive behavior and non-read-only status. The description adds value by specifying that delete 'removes the execution record' and clarifying the get/list/delete semantics. It does not contradict annotations, though it could further explain consequences like irreversibility.

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

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

The description is concise: two sentences front-load the core purpose and then give the primary action routing. Every sentence earns its place without redundancy or filler.

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

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

Given the high schema coverage and the tool's moderate complexity, the description is largely complete. It could add a note about response shape or mention that the delete action is irreversible, but the schema supplies the major parameter details and the description covers action selection.

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

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

All 16 parameters have thorough descriptions in the schema, including enum values and per-action meaning, so the baseline is 3. The tool description itself does not add parameter-level detail beyond the action mapping, which the schema already covers.

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

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

The description clearly identifies the resource (workflow executions) and enumerates the supported operations: get details, list, and delete. It also maps each action to its purpose, making the tool's scope unambiguous and distinct from sibling workflow management tools.

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

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

The description gives explicit guidance on when to use each action, including the default action and the role of 'id'. It does not explicitly compare against sibling tools or state when not to use this tool, but the action-level routing is clear and actionable.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds useful behavioral context beyond this by noting that it uses an instance credential, that it requires N8N_MCP_ACCESS_TOKEN, and that it calls live resource resolution rather than returning static definitions. 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.

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

The description is two dense, purposeful sentences. It front-loads the core action and examples, then immediately gives prerequisite lookup instructions. There is no filler or redundant repetition of the schema.

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

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

Given the tool's complexity (10 parameters, no output schema), the description is quite complete: it names the credential requirement, the two resolution modes, and the source tools for required parameters. It could go slightly further by describing the response shape (label/value items) and pagination behavior, but the schema covers paginationToken and the purpose is unambiguous.

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

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

Schema description coverage is around 90%, so the schema carries most paramater meanings. The description adds value by explaining where to find methodName/methodType and credentialId, and by connecting currentNodeParameters to loadOptionsDependsOn with an example. This goes beyond the raw schema.

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

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

Description names a specific verb and resource: 'Resolve the real options behind a node's dynamic dropdown (loadOptions) or resource-locator search (listSearch)'. It distinguishes itself from get_node by explaining that this tool resolves live options rather than returning the node definition, and gives concrete examples including Slack channels and Google Sheets tabs.

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

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

It clearly conveys when to use the tool (when workflow configs need real IDs behind dynamic dropdowns/listSearch) and tells the agent where to obtain prerequisites: methodName/methodType from get_node output and credentialId from n8n_manage_credentials list. However, it doesn't explicitly state when-not-to-use or compare against alternative tools beyond these references.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds valuable context: explains the n8n draft/publish model, what each mode returns, and that active mode requires a live version. No contradictions 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.

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

The description is a single paragraph with no wasted sentences. It is well-organized, starting with the core purpose, then explaining the draft/publish model, then listing modes compactly. Every sentence adds value.

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

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

Given the tool's complexity (multiple modes, draft/publish model), the description covers key aspects. It explains what each mode returns, though a brief example of the output structure would enhance completeness. No output schema exists, but the description adequately hints at return types.

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

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

Schema has 100% coverage, so baseline is 3. The description adds meaning beyond schema: explains the draft/publish model, clarifies that mode='active' returns published graph, and suggests using mode='structure' first to discover node names for mode='filtered'.

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

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

The description clearly states 'Get workflow by ID with different detail levels.' It specifies the verb (Get), resource (workflow), and the key differentiator (different detail levels). This distinguishes it from sibling tools like get_node or get_template.

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

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

The description provides explicit context for each mode (e.g., 'use mode='active' to see the published graph', 'use mode='filtered' to read one heavy node'). It also warns that mode='active' errors if no live version. It could be improved with a more explicit 'use this when... and not when...' but is still clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and no destructive effects. Description adds minimal extra behavioral context beyond purpose, but does not contradict annotations.

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

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

Two sentences, front-loaded with key purpose, no unnecessary words.

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

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

No output schema, and description does not mention return values. For a health check tool, missing output details reduces completeness, but basic usage is clear.

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

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

Schema coverage is 100% and well-described. Description adds value by explaining diagnostic mode includes env vars and tool status, but does not elaborate further, keeping it at baseline level.

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

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

Clearly states the tool checks n8n instance health and API connectivity. Distinguishes two modes. No sibling tool with similar purpose.

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

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

Explicitly recommends using diagnostic mode for detailed troubleshooting, providing context for when to choose that mode. However, no guidance on when not to use the tool or alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral detail beyond these: it reads the Public API first and falls back to n8n's MCP server only when team projects are not licensed and N8N_MCP_ACCESS_TOKEN is set. This documents an important environment-dependent behavior.

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

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

Two sentences with no filler. The main action and scope are front-loaded, and the second sentence provides the fallback behavior without unnecessary wording. Every sentence earns its place.

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

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

For a read-only list tool with three simple parameters, annotations covering safety, and no output schema, the description is complete. It covers what is listed, why projects matter, and the auth/fallback path an agent needs to anticipate. An agent can correctly select and invoke this tool with the information provided.

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

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

Schema description coverage is only 33%, so the description must compensate. It does add useful semantics for 'kind' by explaining that projects include the personal project marker and are needed as projectId for agents/data tables. The 'query' parameter is already described in the schema, and 'limit' has clear bounds. This is partial but adequate compensation.

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

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

The description uses a specific verb ('List') and resource ('instance-level catalog entries'), then enumerates exactly what is returned: projects or tags. It also clarifies why projects are useful ('needed as projectId for agents and data tables'), distinguishing this from siblings like n8n_list_workflows or n8n_manage_datatable.

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

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

The description gives clear context: use this to obtain project IDs or tags at the instance level. It does not explicitly name an alternative tool or state when not to use it, but the 'instance-level' scope and projectId use case provide enough guidance for an agent to select it appropriately.

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

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

Annotations already provide readOnlyHint and idempotentHint. The description adds value by clarifying the minimal metadata return and pagination behavior (hasMore/nextCursor). No contradictions.

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

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

Two concise sentences, front-loaded with the main purpose. Every sentence adds value with no wasted words.

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

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

For a read-only list tool with no output schema, the description fully covers return fields, pagination, and metadata scope. No additional details are needed.

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

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

Schema coverage is 100% with descriptions for all 6 parameters. The description does not add new parameter details beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states it lists workflows with minimal metadata, specifies returned fields (id/name/active/dates/tags), and mentions pagination. This distinguishes it from sibling tools like n8n_get_workflow.

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

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

The description implies usage for listing workflows with limited data and pagination, but does not explicitly state when to avoid or use alternatives. The mention of minimal metadata helps agents infer appropriate context.

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

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

Annotations already mark this as destructive and open-world, but the description adds crucial context: required N8N_MCP_ACCESS_TOKEN, n8n >= 2.34, real credentials and tools for call, and the approvals[] human-decision requirement. 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.

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

The description is dense but front-loaded with purpose and prerequisities, followed by action list, workflow, and safety caveats. The action enum is partially redundant with the schema, but each sentence contributes actionable guidance.

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

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

For a tool with 15 actions and no output schema, it covers auth, version requirements, invocation order, destructive and publish caveats, call behavior, and sibling differentiation. The instruction to start with reference makes the tool effectively self-documenting for remaining details.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds value by explaining action semantics (e.g., 'call runs the agent with real credentials', 'always with the latest configHash'). However, per-action args are deferred to tools_documentation, so it doesn't fully document all parameters.

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

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

Description states a specific verb and resource: 'Manage n8n Agents' and clarifies what an Agent is. It explicitly distinguishes itself from the AI Agent workflow node with 'This is not the AI Agent workflow node; use get_node for that.' This makes sibling differentiation clear.

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

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

Provides an explicit recommended sequence: reference → discover_assets → create → mutate → validate. Also gives conditional guidance such as 'publish only when the user explicitly asks' and warns against approving approvals[] on the user's behalf, plus an explicit alternative for the AI Agent node.

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

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

Description includes delete action, which is destructive, but annotations set destructiveHint: false. This contradiction undermines transparency. However, the description itself is otherwise detailed about behaviors like NOT_SUPPORTED errors and security logging.

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

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

Single paragraph with key info front-loaded. Somewhat dense but efficient for the complexity. Could benefit from bullet points but still readable.

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

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

Covers usage guidelines, edge cases (NOT_SUPPORTED), pagination, security, and parameter interactions. Lacks output format details but no output schema exists. Adequately complete for a multi-action tool.

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

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

Schema coverage is 100%, yet description adds significant value: explains cursor origin, includeUsage behavior (full scan, ignores limits), getSchema for data fields. This goes well beyond the schema descriptions.

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

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

The description clearly states the tool manages n8n credentials and lists all actions (list, get, create, update, delete, getSchema). It differentiates from sibling tools which handle templates, health, workflows, etc., making the purpose distinct and specific.

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

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

Provides explicit guidance: use getSchema before create, pagination with cursor for list, and notes on deployment compatibility affecting list/get. Does not explicitly state when not to use the tool, but contextual hints are sufficient.

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

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

The annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds meaningful behavioral context: the public API cannot change table columns after creation, so those operations are routed through n8n's own MCP server with a token and version requirement. This gives the agent useful constraints beyond the structured annotations.

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

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

The description is compact and front-loaded: it states the scope, lists all actions, then explains the key API split. The action list is long but necessary for a multi-action tool, and there is no filler.

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

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

For a 13-action, 17-parameter tool, the description is adequate at an overview level and the schema fills in parameter details. However, with no output schema, it does not explain return formats, error behavior, or broader usage boundaries, so the agent still has to infer several operational details.

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

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

Schema description coverage is 100%, with every parameter already documented in the input schema. The description itself adds no parameter-level meaning beyond the schema, 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.

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

The description states the resource ('n8n data tables, rows and columns') and enumerates 13 concrete actions, so an agent can see this is a broad CRUD hub for data tables. 'Manage' is generic, but the action list and resource make the purpose clear and distinguish it from sibling tools like n8n_manage_folders or n8n_manage_credentials.

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

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

The description gives an important internal routing rule: column actions require N8N_MCP_ACCESS_TOKEN and n8n 2.34+, while all other actions use the public API. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, leaving usage mostly implicit in the tool's name and description.

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

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

Annotations already indicate destructive behavior (destructiveHint=true) and non-read-only. The description adds n8n version requirements, the projectId default to 'personal', and the critical limitation that folder contents are only visible as counts. 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.

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

The description is four information-dense sentences, front-loaded with purpose and version requirements. Every sentence adds value and there is no filler or repetition.

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

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

For a complex 10-parameter tool with no output schema, the description plus schema covers actions, requirements, defaults, cross-tool relationships, and a key API limitation. Minor omissions like error handling or permission requirements are not critical given the schema's richness.

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

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

Schema description coverage is 100%, so baseline 3. The description repeats the projectId default and mentions parentFolderId in other tools, but adds no new parameter semantics beyond what the schema already provides.

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

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

The description clearly states the tool manages workflow folders and enumerates six specific actions (create, list, get, rename, move, delete). The note that the API cannot report which folder a workflow is in further distinguishes this tool's scope from sibling workflow-management tools.

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

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

It explicitly directs workflow-folder placement to n8n_create_workflow and n8n_update_partial_workflow, clarifying the boundary between folder management and workflow-to-folder association. It also gives version/instance requirements and warns about the API limitation, providing strong context. It could be more explicit about 'when not to use' but the guidance is solid.

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

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

The annotations only flag non-read-only, open-world, and potentially destructive behavior; the description adds the auth prerequisite (N8N_MCP_ACCESS_TOKEN), the side effect of toggling the persistent 'Available in MCP' setting with explicit user confirmation, the read-only nature of prepare, and the failure mode where auto reports that it cannot be triggered. No contradiction with annotations — the per-method read-only qualifier is consistent with a whole-tool destructiveHint=true.

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

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

Three sentences carry the whole method model, the default behavior, and the auth prerequisite, front-loading 'Run a workflow' and method=auto. The middle sentence is dense with three methods packed into one clause, but for a 16-param, 5-method tool every clause earns its place and nothing is wasted.

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

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

For a tool this complex, the description plus a 100%-covered schema resolve almost every invocation decision: method selection, auth, prerequisites, and side-effect confirmation are all present. The notable gap is return-value semantics — with no output schema, the agent never learns what a run returns (execution ID? result data? error shape?), which matters when a workflow run starts a chained task.

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

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

Schema coverage is 100%, so every parameter already carries a precise semantic description, including pinData's wrapping rule, the timeout vs timeoutMs scoping, and executionMode's 'never chosen implicitly' caveat. The description adds the connecting glue — the method model and auth context — but the schema does the heavy lifting, so baseline 3 applies.

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

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

'Run a workflow' pairs a specific verb with a clear resource and is immediately differentiated from the 28 siblings (create/get/update/delete/list workflows). The method breakdown makes explicit that this tool executes, never manages, workflow definitions, and the trigger/HTTP vs MCP-server distinction removes ambiguity about what 'run' means here.

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

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

The description gives explicit routing logic: workflows with webhook/form/chat triggers use auto/trigger over HTTP, while triggerless workflows require prepare/pinned/direct through n8n's MCP server. It also states the fallback behavior (use exposeToMcp when n8n refuses) and the prepare-first requirement before pinned. It doesn't name exclusion conditions against sibling tools, but within the tool the when-to-use decision is unambiguous.

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

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

The description implies a full replacement behavior by requiring complete nodes and connections, which adds some context beyond annotations. However, it does not elaborate on side effects, return values, or error scenarios. Annotations cover read-only and destructive hints, so the bar is lowered, but the description still contributes limited behavioral detail.

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

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

The description is a single, well-structured sentence that front-loads the purpose, states the key requirement, and names the alternative. Every word adds value with no redundancy or filler.

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

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

Given the tool's 7 parameters and nested objects, the description is brief, but the schema provides rich parameter details and the description successfully conveys the critical distinction from the partial update tool. It lacks explicit mention of return behavior and the effect of omitting optional fields, but overall it is sufficiently complete for an agent given the schema richness.

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

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

The schema has 100% parameter coverage with descriptive text for each field, including 'Complete array of workflow nodes' and 'Complete connections object'. The description merely repeats the completeness requirement without adding new meaning, so it stays at the baseline 3.

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

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

The description clearly identifies the action as a 'Full workflow update' and specifies the resource. It explicitly distinguishes itself from the sibling tool by naming n8n_update_partial_workflow, making its purpose unambiguous and distinct.

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

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

It provides explicit guidance by stating 'Requires complete nodes[] and connections{}' and directing users to the partial update tool for incremental changes. This gives clear when-to-use and when-not-to-use context.

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

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

The description goes beyond annotations by enumerating all operation types and detailing specific requirements for patchNodeField, setNodeGroups, and moveToFolder (including version note). This enriches the behavioral profile significantly, though it omits return format and potential side effects of removal operations. The annotation destructiveHint=false is not directly contradicted because the description does not explicitly claim non-destructive behavior.

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

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

The description is dense but well-structured: one clear opening sentence, a list of operation types, and three specific clarifications. Every sentence adds value, and the final pointer to tools_documentation avoids redundancy. It is slightly long but appropriate for the tool's complexity.

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

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

For a tool this complex, the description covers the main operation categories and critical constraints, including version requirements. However, it lacks specification of return values and error/atomicity behavior (though continueOnError is in the schema). The explicit reference to tools_documentation for full details partially compensates, but the absence of output description is a gap.

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

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

Schema coverage is 100%, giving baseline 3, but the description markedly enhances parameter understanding: it clarifies that operations must have a 'type' field and provides concrete shapes for key operations (e.g., patchNodeField with fieldPath and patches, setNodeGroups with name/nodeNames). This is far more informative than the generic array description in the schema.

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

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

The description starts with 'Update workflow incrementally with diff operations,' clearly stating the specific verb (update), resource (workflow), and mode (incremental diff). This distinguishes it from sibling tools like n8n_update_full_workflow and n8n_create_workflow, making its purpose immediately obvious.

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

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

The phrase 'incrementally' implies usage for partial changes, contrasting with full replacement, but the description does not explicitly state when to use this tool over n8n_update_full_workflow or provide exclusions. It conveys clear context without naming alternatives or when-not cases.

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

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

Annotations already provide read-only, open-world, and idempotent hints. Description adds that it returns errors/warnings/suggestions but does not elaborate on response structure or edge cases.

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

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

Two concise sentences conveying core purpose and output. No redundant information, well front-loaded.

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

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

No output schema, so description should detail return format. Lacks explanation of validation profiles, which are documented only via enum values. Does not address potential confusion with sibling 'validate_workflow'.

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

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

Schema coverage is 100% with detailed property descriptions. Description restates the parameters' purpose without adding new meaning or examples.

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

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

Description clearly states it validates a workflow by ID, checking nodes, connections, expressions, and returning results. However, it does not differentiate from the sibling 'validate_workflow', which may cause confusion.

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

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

No guidance on when to use this tool versus alternatives like n8n_audit_instance or n8n_health_check. Does not specify prerequisites or when not to use.

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

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

Annotations already flag destructive behavior, and the description goes further by disclosing side effects: rollback creates a backup first, delete and prune are local-only, prune retains 10 most recent versions automatically, and exposeToMcp is a visible persistent workflow setting requiring user confirmation. This exceeds what annotations alone provide and helps agents anticipate consequences.

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

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

The description is well-structured with a clear first sentence, a compact mode list, and a source comparison section. It is longer than average, but the tool has 12 parameters and multiple modes, and every sentence contributes operational detail without repetition or filler.

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

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

The description covers modes, sources, prerequisites, side effects, and source-specific constraints, which is strong for a complex tool. It does not describe return value shapes or error conditions, and with no output schema present, some of that burden falls on the description; however, the core invocation context is nearly complete.

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

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

Schema description coverage is 100%, so the input schema already documents all 12 parameters, including mode-specific behavior and defaults. The description adds high-level source semantics but does not meaningfully enrich individual parameter meanings beyond what the schema 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.

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

The description opens with a specific verb and resource: 'Manage workflow version history, rollback, comparison, and cleanup.' It then enumerates six precise modes, making the tool's scope unmistakable. This clearly distinguishes it from sibling workflow tools like n8n_create_workflow or n8n_update_partial_workflow.

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

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

The description provides clear context for when to use the tool via its six modes and explains the critical distinction between the 'local' and 'native' sources. It does not explicitly name sibling alternatives or state when not to use this tool, but the mode breakdown leaves little ambiguity about intended usage.

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

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

Annotations declare readOnlyHint and idempotentHint, which the description aligns with by describing a read-only search operation. The description adds value by specifying the maximum result limit (20) and the token impact of includeOperations ('~100-300 tokens per result'), going beyond what annotations provide. No contradictions.

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

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

The description is extremely concise: three short sentences that front-load the main purpose, provide example usage, and state key behavior. Every sentence is necessary and informative with zero waste.

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

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

There is no output schema, so the description should explain the return structure. It only mentions 'Returns max 20 results' but does not specify what fields each result contains (e.g., node name, description, type). Given the tool has 6 parameters, this lack of return value detail makes it somewhat incomplete.

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

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

Schema description coverage is 100%, so baseline is 3. The description contributes little extra meaning beyond the schema; it gives an example query ('query="webhook"') and mentions the token cost for includeOperations, but these are minor additions. Adequate but not exceptional.

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

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

The description clearly states the tool searches n8n nodes by keyword, provides example queries, and distinguishes itself from siblings like get_node (which retrieves a specific node) and search_templates (which searches templates). The verb 'Search' with resource 'n8n nodes' is specific and unambiguous.

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

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

The description gives clear usage instructions: pass a query string, returns up to 20 results, and explains when to use optional parameters like includeExamples and includeOperations. It provides context for when to use this tool versus alternatives (e.g., search vs. get_node), though it does not explicitly state when not to use it.

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

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

Annotations indicate readOnlyHint and idempotentHint, which the description supports. It adds behavioral context like 'lightweight workflow pattern summaries mined from 2700+ templates,' 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.

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

The description is two sentences, front-loaded with the main purpose, and efficiently covers five modes without waste. Every sentence adds value.

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

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

No output schema is provided, and the description does not detail return values beyond mentioning 'lightweight workflow pattern summaries' for one mode. While parameters specify filtering, the response format is unclear, leaving some gaps.

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

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

Schema coverage is 100%, and the description adds value by explaining how parameters are used in different modes (e.g., 'task' for by_task vs patterns). This supplements the schema descriptions well.

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

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

The description clearly states 'Search templates with multiple modes' and enumerates five distinct modes, making the tool's purpose specific and differentiating it from sibling tools like search_nodes.

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

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

The description explicitly lists when to use each search mode (e.g., 'use searchMode=''keyword'' for text search'), providing clear context for selection. It does not explicitly state when not to use this tool, but the guidance is sufficient.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds context about parameter effects (quick start vs specific docs, depth levels), which goes beyond annotations and helps the agent understand behavior.

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

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

Three sentences, no wasted words. The first sentence states the purpose, followed by usage guidance. Perfectly front-loaded and concise.

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

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

The description covers purpose and usage but does not mention the output format (e.g., returns text/markdown). However, given the tool's simplicity and no required parameters, it is mostly complete. An explicit note about return type would raise it to 5.

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

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

Schema coverage is 100%, with both parameters documented. The description adds usage patterns: 'Call without parameters for quick start guide' and specific parameter uses, enriching the schema meaning with real-world invocation scenarios.

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

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

The description uses the specific verb 'Get documentation' for 'n8n MCP tools', clearly defining the tool's purpose. It distinguishes from sibling tools by being a meta-documentation tool, not a node or workflow tool.

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

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

The description provides clear usage patterns: 'Call without parameters for quick start guide', 'Use topic parameter to get documentation for specific tools', and 'Use depth="full" for comprehensive documentation'. It doesn't explicitly state when not to use this tool or mention alternatives, but the guidance is sufficient for typical use.

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

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

Annotations already declare readOnlyHint and idempotentHint, so safety is clear. The description adds behavioral context by explaining the modes and profiles, and includes an example. No contradictions. It could mention that it doesn't modify state, but annotations already cover that.

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

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

Two sentences and an example. First sentence states purpose, second gives usage guidance. No redundancy. The example is placed at the end for reference. Every part earns its place.

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

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

Given the existence of an output schema (not shown) and the detailed parameter descriptions, the description is largely complete. It explains modes and profiles. It could mention the output structure (errors/warnings/suggestions) but that is covered by the output schema. Overall sufficient for the complexity.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds an example and hints about simple vs complex nodes, but the schema already provides detailed descriptions for each parameter. The added value is moderate.

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

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

The description clearly states the tool validates n8n node configuration, specifies two modes (full/minimal), and provides a concrete example. This distinguishes it from sibling validation tools like validate_workflow by focusing on node-level validation.

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

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

The description gives explicit guidance on when to use each mode ('full' for comprehensive, 'minimal' for quick check). It does not explicitly exclude alternatives or state when not to use it, but the context implies it's for node config vs workflow validation. A clear use case is provided.

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

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

Annotations already declare readOnlyHint and idempotentHint, indicating safe, repeatable usage. The description adds value by stating that it returns errors/warnings/fixes, providing behavioral context beyond annotations.

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

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

Two sentences that are front-loaded with the purpose, clearly stating the scope, return type, and usage context. Every sentence earns its place with no waste.

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

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

Given the complexity (nested parameters, output schema), the description covers the core purpose, validation scope, and return type. It could mention validation profiles but that is covered by the schema, so overall complete.

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

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

Schema coverage is 100% with descriptions for all parameters. The description lists validated categories (structure, connections, expressions, AI tools) which map to the schema's options but adds no essential meaning beyond what the schema provides.

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

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

The description starts with 'Full workflow validation' and specifies the validated aspects: structure, connections, expressions, AI tools. It clearly distinguishes from sibling tools like deploy or health check by stating 'Essential before deploy'.

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

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

The description provides clear context by stating 'Essential before deploy', guiding the agent to use this tool before deployment. It does not explicitly state when not to use or list alternatives, but the context is sufficient.

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