Reconstruct

List user flows

list_flows

Read-onlyIdempotent

List named user flows with provenance and evidence gaps.

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": {
      "product": "<product>",
      "version": "<version>"
    },
    "name": "list_flows"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum items returned, clamped to 1..100. Default 50.
`offset`	No	Zero-based result offset for pagination. Negative values are treated as zero; default is 0.
`product`	Yes	Product key, for example finance-ozon-ru
`version`	Yes	Exact capture version returned by list_versions. Pin the same version across related calls; do not use latest as an alias.
`environment`	No	Environment ID from the selected backend platform type in list_platforms.options.platforms[].environments[].id (backend implementation). Omit only when the version has one captured environment. Use captured pairs from list_platforms/list_versions for actual availability.

Output Schema

Name	Required	Description	Default
`gaps`	Yes
`flows`	Yes
`total`	Yes
`offset`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The phrase 'with provenance and evidence gaps' adds genuine behavioral context by signalling that returned flows may be incompletely evidenced, but the description says nothing about pagination behavior despite having limit/offset parameters, nor about how many flows typically come back.

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 front-loaded sentence with no filler or redundancy. It is efficient almost to a fault — nothing is wasted, but nothing is elaborated either.

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?

An output schema exists and the input schema is fully documented, which relieves the description of return-value and parameter duties. However, for a list tool among 60+ siblings that includes get_flow, list_versions and list_platforms, the description is thin on the prerequisite chain (product -> version -> environment) an agent must follow to call it successfully.

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 every one of the five parameters is already documented in the schema, including the version-pinning rule and the environment lookup chain. The description adds no parameter-level meaning beyond that, which is the correct baseline 3 when the schema carries the load.

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?

Names a specific verb and resource ('List named user flows') and adds the qualifiers 'provenance and evidence gaps', which tell an agent what the listing carries. The singular sibling get_flow is implicitly differentiated by the plural/listing framing, though the description never states that it enumerates flows scoped to a product and version.

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 when-to-use guidance at all: no mention of when to call this instead of get_flow, and no note that product and version must be resolved first via list_products/list_versions. The one useful routing hint (pinning the same version, not using 'latest') lives only in the version parameter's schema description, not in the tool description.

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

All Reconstruct tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?