Skip to main content
Glama

Update flow scheme

update_flow_scheme
DestructiveIdempotent

Edit a flow scheme (partial). A sent flows tree replaces the stored one entirely. Campaigns that already applied the scheme keep their own copy.

Input Schema

NameRequiredDescriptionDefault
idYesFlow scheme id
nameNo
tagsNo
flowsNoRouting tree, evaluated in order. Exactly one flow should be is_default (catch-all, no rules). On update the list is complete: rows match by id, omitted rows are deleted.
statusNo
group_idNo
auto_metricNo
descriptionNo
flow_rotationNo
auto_min_clicksNo
auto_explore_percentNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds two genuinely non-obvious consequences beyond that: a sent flows tree replaces the stored one entirely, and campaigns that already applied the scheme keep their own copy rather than inheriting changes.

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?

Three short sentences with no waste, and the highest-risk behavior (whole-tree replacement) is front-loaded immediately after the purpose statement.

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 destructive 11-parameter tool with no output schema, the description covers the single most dangerous behavior and the campaign-copy consequence. It is still thin on partial-update semantics for scalar fields and on what status=archived does, leaving meaningful gaps for an agent.

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

Parameters2/5

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

Schema description coverage is only 18%, so the description must carry the burden for the other parameters, and it largely does not. It clarifies the replacement semantics of the flows parameter, which is valuable, but says nothing about name, tags, status, group_id, auto_metric, flow_rotation, auto_min_clicks, or auto_explore_percent, which the description must carry the burden for.

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 specific verb and resource ("Edit a flow scheme") with a parenthetical scoping qualifier. An agent can distinguish it from create_flow_scheme and apply_flow_scheme from the verb alone, though no sibling is named explicitly.

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

Usage Guidelines3/5

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

"(partial)" implies that omitted fields stay untouched, which is useful context for when to use this rather than a full replacement. However, there is no explicit when-to-use/when-not guidance and no mention of the alternatives (apply_flow_scheme, clone_campaign) that an agent might confuse it with.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources