Skip to main content
Glama
IEZhu

Agents-Core

by IEZhu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Read a flow

get_flow
Read-only

Read a flow's Markdown, revision history, and saved versions before editing; view an older version to restore prior content.

Instructions

Read a flow's Markdown, revision and saved versions before editing it.

flow: a bare ID or builtin:/user:/repo:<id>. version: an entry from history,
to view or restore older text (restore = save_flow with that content).
For a local copy of a built-in, upstream holds the current built-in text.
flow.sync_conflicts: library sync could not merge two machines' versions
(reason, local_version); tell the user before editing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
flowYes
versionNoOptional version id of the flow; defaults to the current one.
workspaceNoAbsolute path of your working directory, the project this session works in. Pass it whenever you have one: one server can serve several sessions.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv26.10.14+1807

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, yet the description adds genuinely new behavioral context: the flow.sync_conflicts field indicating an unmergeable library sync, and the rule that for a local copy of a built-in the upstream value holds the current text. That is real operational guidance beyond the safety hints.

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?

Four short, front-loaded chunks with no filler: purpose first, then per-parameter semantics, then the sync_conflicts warning. The built-in/upstream sentence is slightly cryptic in isolation but short enough not to hurt.

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

Completeness4/5

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

An output schema exists, so return values need not be explained in depth, yet the description still covers flow ID forms, version semantics, restore behavior, and the sync_conflicts signal. The only gap is that the workspace parameter goes unmentioned in prose, which its schema description reasonably covers.

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 coverage is 67% and the required 'flow' parameter is undocumented in the schema, so the description has to compensate — and it does, spelling out the bare-ID vs builtin:/user:/repo: forms. 'version' is described as a history entry used to view or restore older text, mapping it to the restore path via save_flow. Only 'workspace' is left to 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 ('Read a flow') and enumerates what it returns (Markdown, revision, saved versions), which distinguishes it from list_flows, save_flow, and run_flow. The 'before editing it' framing further pins its role in the workflow.

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?

Gives clear when-to-use context ('before editing it') and explicitly routes the restore case to save_flow with the retrieved content. It does not, however, state when not to use it versus siblings like list_flows or describe_repo, so it falls short of full alternative routing.

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