Skip to main content
Glama

restore_flow

Idempotent

Restore a flow from trash back to active state. Flows stay in the trash for 30 days, then are permanently deleted. Use list_flows with state='trashed' to find trashed flows.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "flow_id": "<flow_id>"
    },
    "name": "restore_flow"
  }
}

Input Schema

NameRequiredDescriptionDefault
flow_idYesThe unique identifier of the trashed flow to restore.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare this is a non-destructive, idempotent mutation. The description adds meaningful behavior beyond annotations: trashed flows remain for 30 days before permanent deletion, which is useful operational context. It does not cover authorization requirements or behavior if the flow is not actually trashed.

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 compact sentences, front-loaded with the action, followed by the retention constraint and a discovery alternative. No sentence is wasted.

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

Completeness5/5

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

For a simple one-parameter restore tool with rich annotations and full schema coverage, the description covers the essential context: state transition, retention window, and how to locate a trashed flow. Missing error-state details are minor.

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%, and the schema already documents flow_id as the unique identifier of the trashed flow to restore. The description reinforces that the flow is trashed but adds no further parameter semantics beyond the schema.

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

Purpose5/5

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

States a specific verb and resource: restore a flow from trash back to active state. The state transition is clear and distinguishes it from sibling tools such as delete_flow, list_flows, and edit_flow.

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?

Explicitly says this is for trashed flows and directs the agent to list_flows with state='trashed' to find them. It does not explicitly state when not to use it, such as for active flows, but the intended context is clear.

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