Skip to main content
Glama
carlosjperez

n8n-mcp-connector

by carlosjperez

activate_workflow

Enable or disable an n8n workflow using its ID, with validation and confirmation before changing its active status.

Instructions

Activate or deactivate a workflow with validation and confirmation

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
activeYesSet workflow active status
workflowIdYesThe workflow ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.9/5.0
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 behavioral burden. It vaguely mentions 'validation and confirmation' but never says what is validated, what happens when validation fails, whether a confirmation step is interactive, or what permissions are required for a state-changing operation.

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?

A single compact sentence with no filler, and the core action is front-loaded. It is efficient, though the trailing 'with validation and confirmation' clause is too vague to earn its place.

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 two-parameter tool with full schema coverage and no output schema, the schema alone is almost sufficient. The gap is that this is a mutation with zero annotations, and the description's cryptic mention of validation and confirmation leaves the agent unsure what side effects or failure modes to expect.

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

Parameters3/5

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

Schema description coverage is 100%, so workflowId and active are already documented in the schema, which sets the baseline at 3. The description adds no format details or constraints beyond what the schema provides, so it neither helps nor hurts.

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?

States a clear verb pair (activate/deactivate) and the resource (workflow), which distinguishes it from sibling mutations like create_node or delete_connection. However, the name says only 'activate' while the description covers toggling via a boolean, and it never explains how the operation relates to execute_workflow or list_workflows.

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 indication of when to activate versus deactivate a workflow, no preconditions for the 'validation' it mentions, and no alternative tools named. The agent must infer that the boolean parameter controls direction entirely on its own.

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