Skip to main content
Glama
duynghien

n8n-custom-mcp

by duynghien

validate_workflow_credentials

Checks workflow credentials before deployment to ensure credential IDs exist, types match node requirements, and optionally tests validity.

Instructions

Validate workflow credentials before deployment. Checks: credential IDs exist, credential types match node requirements, and optionally tests credential validity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workflowYesWorkflow object to validate
testCredentialsNoWhether to test credential validity (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.1

TDQS

A3.8/5.0
Behavior3/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 explains what is checked (credential ID existence, type matching, optional validity testing), but it omits how results are returned (success/failure, errors), whether side effects such as network calls occur, and error behavior on invalid credentials.

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

Conciseness5/5

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

Two concise sentences with the purpose front-loaded. The checks are listed in a compact, scannable manner with no filler or redundancy.

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 inputs and validation checks are adequately described for a tool of this complexity. However, with no output schema and no annotations, the description leaves out crucial details about the return format and behavior on failure, which an agent needs to invoke it correctly and interpret results.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The tool description adds meaningful detail beyond the schema by specifying what the workflow object will be validated against ('credential IDs exist, credential types match node requirements') and clarifying that testCredentials triggers validity testing, enriching the generic schema descriptions.

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?

Description states a specific verb ('Validate') and resource ('workflow credentials') with a contextual phase ('before deployment'), and enumerates concrete checks. It is clearly distinct from sibling validation tools like validate_workflow_structure and validate_workflow_expressions, though it does not name alternatives explicitly.

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?

'Before deployment' provides clear contextual guidance for when this tool is appropriate. It does not list when-not-to-use or explicit alternatives, but the described checks define its domain well enough for an agent to select it over other validators.

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