Skip to main content
Glama

Extcord

by io.extcord
OverviewDiscussionsAdmin

run_pipeline

Read-only

Chain ops in one call: each step is {op, input?, args?, as?, input_type?}, later steps refer to earlier results as "$0", "$name" or paths like "$1[0]", and only the final result comes back while intermediate data stays on the server. Use this when a job takes two or more ops (fetch, then extract, then filter); for one op use run_op, and if a saved recipe already does the job (discover_ops shows solved_before) use run_recipe. dry_run=true checks refs, arg names, types and cost without running anything. Up to 50 steps. A failing step stops the pipeline; the error names the step, reports which steps finished, and suggests the fix. Steps count toward the 1200 steps a minute limit; fetch steps also toward 60 fetches a minute. 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"}].

Input Schema

NameRequiredDescriptionDefault
stepsYesOrdered steps, 1 to 50. A literal string starting with $ is written $$.
terseNoReturn only the answer (value, or handle and preview), without steps, hashes or hints.
dry_runNoValidate and estimate without running.
result_fromNoWhich step to return, as a ref like "$2" or "$prices[0]". Default: the last step.
inline_max_tokensNoReturn the value itself when it's at most this many estimated tokens, else a preview. Default 300.

Output Schema

NameRequiredDescriptionDefault
stepsNoPer step: op, handle, type, est_tokens, ms.
validNodry_run: whether it would run.
valueNoterse: the value itself.
handleNoterse, large result: its handle id.
resultNoThe returned step's handle, as in run_op.
totalsNodry_run: the estimate: steps, cost, side effects (e.g. reads_network), deterministic.
problemsNodry_run: what would fail, per step.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema fields changed
    • addedInput schema / $defs
      Added value: +{
+  "Step": {
+    "additionalProperties": true,
+    "properties": {
+      "args": {
+        "additionalProperties": true,
+        "description": "The op's arguments; values may be refs.",
+        "type": "object"
+      },
+      "as": {
+        "description": "Name this step so later steps can use \"$name\".",
+        "type": "string"
+      },
+      "input": {
+        "description": "A ref (\"$0\", \"$page\", \"$1[0]\", \"$2.items[*].name\"), a handle id, or a literal."
+      },
+      "input_type": {
+        "description": "Override the type of a literal input.",
+        "enum": [
+          "text",
+          "html",
+          "json",
+          "list",
+          "table",
+          "number",
+          "boolean"
+        ],
+        "type": "string"
+      },
+      "op": {
+        "description": "Op id.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "op"
+    ],
+    "type": "object"
+  }
+}
    • changedInput schema / properties / dry_run / description
      Previous value: -"Check refs, args, types, cost and side effects without running anything."New value: +"Validate and estimate without running."
    • removedInput schema / properties / dry_run / title
      Removed value: -"Dry Run"
    • changedInput schema / properties / inline_max_tokens / description
      Previous value: -"Results up to this many estimated tokens include their value directly; larger ones return a preview. Default 300."New value: +"Return the value itself when it's at most this many estimated tokens, else a preview. Default 300."
    • removedInput schema / properties / inline_max_tokens / title
      Removed value: -"Inline Max Tokens"
    • removedInput schema / properties / result_from / title
      Removed value: -"Result From"
    • changedInput schema / properties / steps / description
      Previous value: -"Ordered 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."New value: +"Ordered steps, 1 to 50. A literal string starting with $ is written $$."
    • addedInput schema / properties / steps / items / $ref
      Added value: +"#/$defs/Step"
    • removedInput schema / properties / steps / items / additionalProperties
      Removed value: -true
    • removedInput schema / properties / steps / items / type
      Removed value: -"object"
    • removedInput schema / properties / steps / title
      Removed value: -"Steps"
    • changedInput schema / properties / terse / description
      Previous value: -"Return just the answer: the value if small, else a handle with a short preview."New value: +"Return only the answer (value, or handle and preview), without steps, hashes or hints."
    • removedInput schema / properties / terse / title
      Removed value: -"Terse"
    • removedInput schema / title
      Removed value: -"run_pipelineArguments"
    • addedOutput schema / properties
      Added value: +{
+  "handle": {
+    "description": "terse, large result: its handle id.",
+    "type": "string"
+  },
+  "problems": {
+    "description": "dry_run: what would fail, per step.",
+    "items": {},
+    "type": "array"
+  },
+  "result": {
+    "additionalProperties": true,
+    "description": "The returned step's handle, as in run_op.",
+    "type": "object"
+  },
+  "steps": {
+    "description": "Per step: op, handle, type, est_tokens, ms.",
+    "items": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "type": "array"
+  },
+  "totals": {
+    "additionalProperties": true,
+    "description": "dry_run: the estimate: steps, cost, side effects (e.g. reads_network), deterministic.",
+    "type": "object"
+  },
+  "valid": {
+    "description": "dry_run: whether it would run.",
+    "type": "boolean"
+  },
+  "value": {
+    "description": "terse: the value itself."
+  }
+}
    • removedOutput schema / title
      Removed value: -"run_pipelineDictOutput"
  2. Changed1 schema field changed
    • addedInput schema / properties / terse
      Added value: +{
+  "default": false,
+  "description": "Return just the answer: the value if small, else a handle with a short preview.",
+  "title": "Terse",
+  "type": "boolean"
+}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, non-destructive, openWorld), and the description adds substantial behavior beyond them: intermediate data stays server-side with only the final result returned, dry_run validates refs/args/types/cost, hard limits (50 steps, 1200 steps/min, 60 fetches/min), and precise failure semantics naming the failed step and suggesting a fix.

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-loaded with purpose, then routing, then behavioral rules, then a worked example. Dense and every sentence is informative, though the single long paragraph is slightly heavy to scan.

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?

Output schema exists so return format is covered structurally; the description still supplies error handling, rate limits, dry_run semantics, and step-count bounds. Nothing an agent needs to call this correctly is missing.

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 baseline is 3, but the description adds value through the concrete three-step example showing how op/input/args/as compose via refs like $page and $1, plus the default-return semantics. Ref syntax is partly in the schema, so this is augmentation rather than compensation.

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 ('Chain ops in one call') and immediately differentiates from siblings run_op and run_recipe. An agent can tell exactly what this does and how it differs from the alternatives without opening a schema.

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

Usage Guidelines5/5

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

Explicit when-to-use ('a job takes two or more ops') plus named alternatives with selecting conditions: run_op for one op, run_recipe when discover_ops shows solved_before. Both directions of the decision are covered with no inference required.

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

All Extcord toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources