Extcord

run_recipe

Read-only

Run a saved recipe (a named, parameterized pipeline, built in or published by agents) in one call; its result is checked against the recipe's expectations. version runs an earlier version from its history, checked against that version's own expect and recorded on that version. Use this when discover_ops lists a recipe for your job (see solved_before); for single pages and package lookups use read_page and read_package_info, which run the built-in recipes for you, and for your own one-off chain use run_pipeline. params must match the recipe's declared params (see discover_ops(recipe=)); defaults can be left out, and missing or unknown params return the param list. verified.correct=false means it ran but the result looks wrong (often a site changed): verified.advice names any repaired recipe. Each real run is recorded in the recipe's public run statistics (success rate, agents using it); only runs with the recipe's own example can mark it broken. dry_run runs and records nothing. Recipes that fetch count toward 60 fetches a minute. An unknown name returns a did-you-mean.

Input Schema

Name	Required	Description
`name`	Yes	Recipe name, e.g. 'page_tables'.
`terse`	No	Return only the answer (value, or handle and preview), without steps, hashes or hints.
`params`	No	Values for the recipe's params, e.g. {"url": "https://example.com"}. Params with defaults can be left out.
`dry_run`	No	Return the plan with params filled in, without running or counting anything.
`version`	No	Run this earlier version instead of the current one. discover_ops(recipe=<name>) lists the versions kept.
`inline_max_tokens`	No	Return the value itself when it's at most this many estimated tokens, else a preview. Default 300.

Output Schema

Name	Required	Description
`plan`	No	dry_run: the steps it would run, with params filled in.
`value`	No	terse: the value itself.
`handle`	No	terse, large result: its handle id.
`result`	No	The final handle, as in run_op.
`warning`	No	terse: the result ran but failed the recipe's expectations.
`verified`	No	checked, correct, and if not: problems and advice (naming any repaired recipe).

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedOct 11, 2026

addedInput schema / properties / dry_run / description

Added value: +"Return the plan with params filled in, without running or counting anything."

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"
```

changedInput schema / properties / name / description

Previous value: -"Recipe name, e.g. 'page_to_markdown'. discover() lists them."New value: +"Recipe name, e.g. 'page_tables'."

removedInput schema / properties / name / title
```
Removed value: -"Name"
```

changedInput schema / properties / params / description

Previous value: -"Values for the recipe's params, e.g. {\"url\": \"https://example.com\"}."New value: +"Values for the recipe's params, e.g. {\"url\": \"https://example.com\"}. Params with defaults can be left out."

removedInput schema / properties / params / title
```
Removed value: -"Params"
```

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"
```

addedInput schema / properties / version

Added value: +{
+  "anyOf": [
+    {
+      "minimum": 1,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Run this earlier version instead of the current one. discover_ops(recipe=<name>) lists the versions kept."
+}

removedInput schema / title
```
Removed value: -"run_recipeArguments"
```

addedOutput schema / properties

Added value: +{
+  "handle": {
+    "description": "terse, large result: its handle id.",
+    "type": "string"
+  },
+  "plan": {
+    "description": "dry_run: the steps it would run, with params filled in.",
+    "items": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "type": "array"
+  },
+  "result": {
+    "additionalProperties": true,
+    "description": "The final handle, as in run_op.",
+    "type": "object"
+  },
+  "value": {
+    "description": "terse: the value itself."
+  },
+  "verified": {
+    "additionalProperties": true,
+    "description": "checked, correct, and if not: problems and advice (naming any repaired recipe).",
+    "type": "object"
+  },
+  "warning": {
+    "additionalProperties": true,
+    "description": "terse: the result ran but failed the recipe's expectations.",
+    "type": "object"
+  }
+}

removedOutput schema / title
```
Removed value: -"run_recipeDictOutput"
```

Changed1 schema field changedOct 9, 2026

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"
+}

First observedOct 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover readOnly/openWorld/idempotent/destructive, yet the description adds substantial context beyond them: verified.correct=false semantics, verified.advice repair hints, the fact that runs are recorded in public stats and only example-bearing runs can mark a recipe broken, that dry_run records nothing, the 60-fetches/minute budget, and did-you-mean on unknown names. All are non-obvious behavioral traits.

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?

One dense block, but front-loaded with the core action and organized by concern (usage, params, verification, recording, rate limit). Every sentence carries information, though the density is high and could benefit from light segmentation.

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?

With an output schema present, return values need not be fully spelled out, yet the description still explains the key result fields (verified.correct, verified.advice). Combined with usage routing, param rules, and rate limits, an agent has everything needed to call it correctly.

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, but the description adds real meaning beyond the schema: params must match declared recipe params, defaults may be omitted, and missing/unknown params return the param list; version is tied to a version's own expect and history. Slightly above baseline.

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 ('Run a saved recipe') and immediately defines what a recipe is (a named, parameterized pipeline). It explicitly names and distinguishes siblings: read_page/read_package_info for single pages and package lookups, run_pipeline for one-off chains.

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?

Gives an explicit trigger ('Use this when discover_ops lists a recipe for your job') and a full alternative map, routing the agent to read_page, read_package_info, or run_pipeline depending on intent. Nothing about when-to-use is left to inference.

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

All Extcord tools Inspect

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

Need Help?