Skip to main content
Glama
anythink-cloud

Anythink-MCP

Official

Workflows: disable

workflows_disable

Disable an existing workflow by its ID to stop its automated tasks and processes from running.

Instructions

Disable a workflow

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesWorkflow ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.27

TDQS

C2.9/5.0
Behavior2/5

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

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=false. The description adds nothing beyond them: it does not say whether disabling is reversible, whether it affects in-flight runs or jobs (cf. workflows_jobs), or whether it requires ownership/admin rights. With annotations present the bar is lower, but zero added context leaves the call semantics ambiguous.

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 terse sentence with no waste and the operation front-loaded. It is efficient, though arguably under-specified rather than optimally concise.

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 one-parameter toggle with no output schema, the description is minimally adequate, and annotations cover the safety profile. It still omits what disabling means operationally (reversibility, effect on runs/jobs, required permissions), which an agent invoking a mutating toggle would benefit from knowing.

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% — the single 'id' parameter is fully documented as 'Workflow ID' — so the description carries no extra burden. It adds no format hints or constraints, which matches the baseline 3 for fully covered schemas.

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 states a clear verb+resource ('Disable a workflow'), so the agent knows exactly what operation is performed. It does not, however, distinguish this from siblings like workflows_enable or workflows_delete, which operate on the same resource.

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 guidance on when to disable versus delete or update a workflow, and no mention of the obvious complementary tool workflows_enable. The agent must infer usage entirely from the name.

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

Deploy Server

Other Tools