Skip to main content
Glama

Extcord

run_pipeline

Read-only

Chain operations in one call; only the final result comes back, intermediate data stays on the server. Example steps: [{"op": "fetch", "args": {"url": "https://example.com/pricing"}, "as": "page"}, {"op": "extract_tables", "input": "$page", "args": {"index": 0}}, {"op": "to_markdown", "input": "$1"}]. Use dry_run=true first when unsure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stepsYesOrdered steps: {"op": id, "input"?: ref|handle|value, "args"?: {...}, "as"?: name}. Refer to earlier steps as "$0", "$1", "$name", or paths like "$1[0]"; refs work inside args too.
dry_runNoCheck refs, args, types, cost and side effects without running anything.
result_fromNoWhich step to return, as a ref like "$2" or "$prices[0]". Default: the last step.
inline_max_tokensNoResults up to this many estimated tokens include their value directly; larger ones return a preview. Default 300.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true and non-idempotent, so the safety profile is covered. The description adds genuinely non-obvious behavior: intermediates are kept server-side and only the final step's value is returned, plus the dry_run verification path. It does not address the mild tension between readOnlyHint=true and the schema's note that dry_run checks "side effects", which an agent chaining write-like ops would want clarified.

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?

Front-loads the core semantics (chaining, only final result returned) before the example. The inline JSON example is bulky but earns its place by illustrating the otherwise-abstract step format; nothing is redundant.

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-value documentation is unnecessary, and the description covers execution model, result scoping, and a verification mode. The one gap is sibling disambiguation against run_recipe for a tool that otherwise reads as complete.

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 100%, so the baseline is 3. The worked example goes beyond the schema by showing the exact step object shape and demonstrating implicit positional refs ("$page", "$1") in a realistic chain, which clarifies how steps compose.

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 concrete verb+resource: chaining operations into one call and returning only the final result. It is clearly distinct from discover/inspect/invoke, but it never distinguishes itself from the sibling run_recipe, which on its face sounds like a very similar batching tool.

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?

Offers one piece of real guidance ("Use dry_run=true first when unsure"), which is a useful precondition. However it gives no when-to-use versus run_recipe, invoke, or save_recipe, so an agent must guess which execution path to pick for a given task.

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