Agent utilities: read big pages without filling context, exact math, dates, parsing. Free.
Scored across 11 tools
Most tools have clearly distinct roles, and the descriptions actively disambiguate overlapping ones (e.g. read_page vs read_package_info, run_op vs run_pipeline vs run_recipe, calculate_expression vs calculate_date). The main risk is the run_* family and the read_* family where boundaries require reading the guidance, but the descriptions consistently state when to use which. No two tools appear to do the same thing.
Every tool follows a clean verb_noun pattern: calculate_date, calculate_expression, read_page, read_package_info, read_handle, run_op, run_pipeline, run_recipe, save_recipe, delete_recipe, discover_ops. Convention is applied uniformly with no camelCase/snake_case mixing or stray vague verbs.
11 tools is a well-scoped set for a general-purpose compute/web/recipe server. Each tool earns its place (front-door helpers, raw op execution, pipeline chaining, catalog discovery, recipe lifecycle), with no obviously redundant entries.
Strong coverage: discovery, single-op and multi-op execution, a full recipe lifecycle (save with versioning, run, delete), plus read/compute front doors. Minor gaps exist (no explicit recipe listing/update tool, and delete_recipe requires the one-time edit_key), but discover_ops and versioned save_recipe largely close them.
Get the current date and time, or do calendar math exactly, DST-aware. action=now: the current time in tz. action=add: shifts date by the add object, e.g. {"months": 1} or {"business_days": 10}; month ends are clamped (Jan 31 + 1 month = Feb 28). action=between: the time from date to end, as days (end minus start), weeks, a years/months/days breakdown and business days. Business days are Monday to Friday counted after the start day, with no holidays. If end is earlier, the numbers are negative and the result says "direction": "backward". action=info: weekday, week number and quarter of date, converted to to_tz if given. A date with its own offset keeps it; others are read in tz. Use this instead of guessing today's date or counting days yourself; use calculate_expression for plain numbers. Dates in almost any format are accepted; ambiguous ones like 03/04/2026 are read month-first unless dayfirst=true, and notes say how input was read. Missing or unreadable inputs return an error naming the parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | now: the zone to answer in. Others: the zone of dates that don't state one. IANA ("Asia/Tokyo"), offset or abbreviation. Default UTC. | |
| add | No | add (required): years, months, weeks, days, hours, minutes, seconds or business_days; negative to subtract. | |
| end | No | between: the end date (required). | |
| date | No | add, between (start), info: required. e.g. "2026-10-07" or "Oct 7 2026 9am". | |
| to_tz | No | info: convert to this zone. | |
| action | Yes | ||
| dayfirst | No | Read 03/04/2026 as 3 April. |
| Name | Required | Description |
|---|---|---|
| notes | No | How an ambiguous input was read. |
| value | Yes | now/add/info: iso, date, weekday, time, tz, utc_offset, iso_week, quarter. between: days, weeks, breakdown, business_days, direction (forward or backward). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safe-read profile (readOnlyHint=true, destructiveHint=false), and the description still adds substantial behavior: DST-awareness, month-end clamping (Jan 31 + 1 month = Feb 28), the Monday–Friday/no-holidays business-day rule, negative/backward results when end < start, month-first parsing of ambiguous dates unless dayfirst=true, and error behavior that names the malformed parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single dense paragraph where nearly every sentence maps to an action or an edge case, so little is wasted and the main use case is front-loaded. It could be tightened with action-keyed fragments, but length is proportionate to four modes and seven parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 annotations cover the safety profile. For a four-mode, seven-parameter tool the description covers mode selection, required inputs, edge cases, parsing ambiguity and failure behavior — nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 86%, yet the description meaningfully extends it: the shape of the add object with worked examples, the clamping rule, what tz means for now vs. other actions, when dayfirst applies, and which parameters each action requires. This goes well beyond restating the schema strings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('get the current date and time, or do calendar math exactly, DST-aware') and then enumerates the four action modes, each with its own semantics. It explicitly separates itself from the sibling calculate_expression ('use calculate_expression for plain numbers'), so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the operative context directly ('use this instead of guessing today's date or counting days yourself') and names the alternative tool and the condition that selects it. Each action (now/add/between/info) is described with its required inputs, which functions as per-mode usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate an arithmetic expression exactly: + - * / // % ** use rational numbers, not floats, so 0.1 + 0.2 = 0.3, and money strings like "$1,200.50" read as numbers. Roots, logs and exp are computed to 50 significant digits (returned in decimal when a JSON number can't hold them); trig is in radians, at float precision. Use this instead of doing math in your head; use calculate_date for anything with dates or times, and run_op("stats") to summarize a column of data. Pure computation: no network, same answer every time. Unknown names, syntax errors and results over 5,000 digits are refused with a suggested fix. Example: expr="price * qty * (1 + tax/100)", vars={"price": "$19.99", "qty": 3, "tax": 8.25}, places=2 gives 64.92.
| Name | Required | Description | Default |
|---|---|---|---|
| expr | Yes | Python-style arithmetic; ** is power (^ is refused). Functions: pct(p, x) = p% of x, pct_change(old, new) = (new - old) / old * 100, round(x, places) half-up, floor, ceil, int, abs, sqrt, exp, ln, log(x) natural or log(x, base), log10, log2, pow, factorial, gcd, lcm, comb(n, k), perm(n, k), sin, cos, tan, asin, acos, atan, atan2(y, x), sum, mean, median, min, max. Constants: pi, e, tau, true, false. | |
| vars | No | Values for the names used in expr: numbers or numeric strings like "$1,200.50". Any name in expr must be here. | |
| places | No | Round the result to this many decimals, half-up. |
| Name | Required | Description |
|---|---|---|
| exact | No | Every digit of an integer too large for a JSON number. |
| value | Yes | The result: a number, or true/false for comparisons. |
| decimal | No | Up to 50 significant digits, when value (a JSON number) holds fewer. |
| fraction | No | The exact fraction of a repeating decimal, like 1/3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add the traits that actually matter here: exact-vs-float semantics, 50-significant-digit precision for roots/logs/exp with decimal fallback, radians for trig at float precision, deterministic/pure execution, and the three refusal conditions (unknown names, syntax errors, >5,000 digit results) each returning a suggested fix.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and numeric semantics, then routing, then safety, then error behavior, then a worked example — a sound information hierarchy. It is dense (roughly 120 words) and duplicates a few details the schema already carries, such as the money-string coercion and the function catalogue, but every sentence contributes something.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return formatting need not be explained; the description instead covers the gaps that schema cannot: numeric representation (rational vs float vs decimal string), precision bounds, units for trig, error/refusal behavior, and determinism. 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.
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 earns extra by disambiguating parameter interaction rather than restating fields: it states that every name in expr must appear in vars, that money strings like "$1,200.50" are coerced to numbers, and it supplies a worked example tying expr + vars + places together into a concrete result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Evaluate an arithmetic expression exactly') and immediately pins the semantic regime: exact rational arithmetic, not floating point. It names its neighbors (calculate_date, run_op) explicitly, so an agent can route without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives positive usage ('use this instead of doing math in your head') and explicit exclusions with the alternative for each: calculate_date for anything with dates/times, run_op("stats") to summarize a column of data. This is exactly the when/when-not/alternatives pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a recipe you saved, with its version history and track record, using the edit_key from its first save. Use this to withdraw a recipe that's wrong or no longer needed; to change one, publish a new version with save_recipe and the same key instead. Other agents can no longer run it. Recipes that repaired it stay published and are listed in the reply. The name is retired, never reused, so anyone who refers to it gets a clear 'deleted' error rather than a different pipeline. Built-in recipes can't be deleted; a wrong key, or a name that doesn't match exactly, returns an error and changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The recipe's name. | |
| edit_key | Yes | The edit key returned when you first saved it. |
| Name | Required | Description |
|---|---|---|
| deleted | Yes | The recipe that was removed. |
| still_available | No | Recipes that repaired it; they stay published. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, but the description goes well beyond them: it discloses that version history and track record are destroyed, other agents can no longer run it, repaired recipes stay published and are listed in the reply, the name is permanently retired, built-in recipes are protected, and a wrong key or mismatched name errors without side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action and key requirement are front-loaded in the first sentence, and each following sentence carries distinct behavioral information (mutation alternative, downstream effects, name retirement, built-in protection, failure behavior) with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, no-output-reliance tool with an output schema present, the description covers everything an agent needs: consequences, sibling routing, edge cases, and even the partial return content. No relevant decision factor is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented and the baseline is 3. The description adds genuine meaning on top: edit_key is clarified as the key from the first save, and name must match exactly or the call fails, which refines how each argument must be supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Permanently delete a recipe you saved") plus the exact mechanism ("using the edit_key from its first save"). It explicitly distinguishes itself from the sibling save_recipe by naming it and describing the alternative path for modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ("withdraw a recipe that's wrong or no longer needed") and when-not, routing the agent to save_recipe with the same key to change a recipe instead. Nothing is left to inference about choosing between the two.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the op or recipe for a job, or read the details of one. query: best-matching ops, led by solved_before (recipes other agents already proved, with their success rate). op: that op's full contract (args schema, behavior, worked examples). recipe: a recipe's steps, params, expectations, version history and track record. No arguments: every op by category with a one-line intent. Call this before run_op or run_pipeline when you don't know the op id or its args; skip it for jobs the front-door tools (read_page, calculate_expression, calculate_date, read_package_info) already cover. Reads only this server's catalog: no network, no side effects. An unknown op or recipe returns a did-you-mean suggestion. Pass one of query, op or recipe (if several, op wins, then recipe); accepts filters ops by input type, alone or with query. To read everything at once instead, use the resource extcord://catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| op | No | An op id, e.g. 'extract_tables', for its full contract. | |
| query | No | Words describing the job, e.g. 'html table to rows' or 'decode base64'. | |
| recipe | No | A recipe name, e.g. 'page_tables', for its definition and track record. | |
| accepts | No | With or without query: only ops that take this input type (text, html, json, list, table, number, boolean). |
| Name | Required | Description |
|---|---|---|
| op | No | op: its contract (args_schema, behavior, examples). |
| ops | No | query: matching ops (id, intent, accepts, returns). |
| track | No | recipe: status, success_rate, runs and agents in 30 days. |
| recipe | No | recipe: steps, params, example, expect, history. |
| solved_before | No | query: recipes that already did this, with their track record. |
| ops_by_category | No | No arguments: every op id and intent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent and closed-world, but the description adds real behavioral context: reads only this server's catalog with no network or side effects, unknown ids return a did-you-mean suggestion, and filters can't be combined with the wrong argument. It stops short of describing result size or pagination for the no-argument catalog dump.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely dense but front-loaded: purpose first, then per-mode semantics, then routing advice and edge cases. Every sentence carries information, though the long running sentences make it slightly harder to scan than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all three modes, their outputs at a conceptual level, argument precedence, filter interaction, failure behavior, and the bulk alternative. Since an output schema exists, return-value detail is correctly omitted, leaving nothing an agent needs missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 goes further by explaining what each mode yields (query is ranked and led by solved_before recipes with success rates; op returns the full contract with args schema and examples; recipe returns steps, params and track record) and how accepts combines with query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (find/read) plus resource (op or recipe) and enumerates the three lookup modes with what each returns. It also explicitly distinguishes itself from run_op/run_pipeline and the front-door read tools, so an agent can place it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('Call this before run_op or run_pipeline when you don't know the op id or its args'), when-not ('skip it for jobs the front-door tools ... already cover'), and an alternative for bulk reading (the extcord://catalog resource). Argument precedence (op wins, then recipe) is also spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a stored result (handle) without running anything: view=summary for its type, size, est_tokens and suggested next ops; view=value for the data itself one page at a time (follow next_offset); view=provenance for the ops, args and source URLs that produced it. Use this when a result came back as a preview and you need more of it. Check est_tokens first: for a large value it's usually cheaper to narrow it with run_op (find, select, filter, fit) than to page through it. Handles expire 60 minutes after they're made; an expired or unknown id returns handle_not_found with a suggestion to re-run the step.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | summary | |
| limit | No | value: page size. Default 4000 characters or 50 items. | |
| handle | Yes | A handle id like h_3f9a1c2b7e, from any earlier result. | |
| offset | No | value: where to start, in characters for text or items for lists. Use next_offset from the previous page. |
| Name | Required | Description |
|---|---|---|
| chain | No | provenance: ops, args, inputs and sources, oldest first. |
| value | No | summary: the value if small. value: this page of it. |
| handle | Yes | The handle id. |
| next_offset | No | value: offset of the next page; null at the end. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, but the description adds material behavior the annotations cannot: a 60-minute handle TTL, the handle_not_found error contract, and the cost trade-off between paging and re-filtering. That is real operational context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and the three view modes, then usage guidance, then expiry semantics. Dense but every clause carries information; the opening sentence runs long, which is the only cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description still conveys enough for correct invocation: what each view yields, how to page, when to prefer run_op, and what an expired handle produces. Nothing an agent needs is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% and limit/offset/handle are already documented in the schema, so the baseline is 3. The description goes further by explaining what each enum value of 'view' actually returns and how next_offset drives paging, adding meaning the schema's bare enum does not carry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource ('Read a stored result (handle) without running anything') and immediately enumerates the three view modes, which lets an agent distinguish it from run_op, read_page and run_pipeline. The scope ('without running anything') is exactly the boundary an agent needs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('when a result came back as a preview and you need more of it') and names the alternative path with the condition that selects it: check est_tokens first, and prefer narrowing with run_op (find, select, filter, fit) over paging. It also covers the failure case (expired/unknown id) and the remedy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a package's latest release from PyPI, npm or crates.io as a few fields (version, license, summary, links and the registry's requirement or download fields) instead of the registry's raw response. Latest release only: there is no version parameter. Use this for those three registries; for any other site use read_page. Reads the live registry each call. Fetches are limited to 60 a minute per client. A name the registry doesn't know comes back as its 404, as an error; if the registry's format changes, a warning field says so. Each call runs a built-in recipe and is recorded in its public run statistics; otherwise nothing is kept except the result's handle, for 60 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name, e.g. requests, express, @types/node (scoped), serde. PyPI and crates.io ignore case and treat - and _ alike; npm names must match exactly. | |
| ecosystem | Yes | pypi (Python), npm (JavaScript) or crates (Rust). |
| Name | Required | Description |
|---|---|---|
| value | No | name, version, released (pypi), license, summary or description, requires_python (pypi) or node (npm), downloads and updated (crates), links. |
| handle | No | Handle id of the result, usable with run_op or read_handle. |
| warning | No | The registry's answer is missing fields it normally has (its format may have changed). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only open-world operation, and the description adds substantive behavior beyond them: live registry reads on each call, a 60/minute per-client rate limit, 404-style errors for unknown names, a warning field on format changes, and a 60-minute handle retention policy. This is unusually complete operational disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded and each subsequent sentence carries distinct operational information (registry scope, rate limit, error semantics, retention). It is dense but nothing is redundant; only the bundled final clauses could be split for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return formatting need not be spelled out, yet the description still enumerates the fields returned. Combined with error, rate-limit, and retention behavior, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the two parameters are already documented, setting a baseline of 3. The description nevertheless adds meaning by ruling out a version parameter and framing both params as registry-scoped, which prevents a plausible invocation error.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (Get) and resource (a package's latest release) and scopes it to three named registries. It also distinguishes itself from the sibling read_page, so an agent can route correctly without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit selection criteria: 'Use this for those three registries; for any other site use read_page.' It also pre-empts a common misuse by stating that only the latest release is available and there is no version parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public web page and return only the part you need instead of the raw HTML. view: markdown (main content, navigation and boilerplate removed), outline (headings), links (all links; query keeps those whose URL or text contains it), tables (one table, chosen by table, as a markdown table), find (only passages mentioning query; query required). Use this for any single page; use read_package_info for PyPI, npm and crates.io, and run_pipeline for multi-step extraction (e.g. filtering a table's rows). Reads the live page each call and doesn't run JavaScript, so pages built in the browser may come back thin. Only public http(s) addresses. Fetches are limited to 60 a minute per client. Errors (unreachable site, non-HTML content, no table at that index) come back with a suggested fix. Each call runs a built-in page recipe and is recorded in its public run statistics; otherwise nothing is kept except the result's handle, for 60 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL of the page. | |
| view | No | markdown | |
| query | No | find: the word or phrase to look for (required). links: keep links whose URL or text contains it. | |
| table | No | tables: which table, 0 = first, -1 = last. | |
| max_tokens | No | Most tokens to return. markdown is trimmed (and marks the cut); other views return a preview and handle instead. |
| Name | Required | Description |
|---|---|---|
| value | No | markdown/outline: text. links: [{href, text}]. tables: markdown table. find: [{match, context, line, offset}]. |
| handle | No | Handle id (h_...) of the full result, for run_op or read_handle. |
| preview | No | Instead of value, when the result is over max_tokens. |
| warning | No | The result looks wrong for this view, e.g. empty. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already covering the safety profile, the description adds substantial behavioral context the annotations cannot: it reads the live page (not cached), does not execute JavaScript so browser-built pages come back thin, only accepts public http(s), is rate limited to 60 fetches/minute per client, returns errors with suggested fixes, and runs a public recipe recorded in run statistics with only the result handle retained for 60 minutes. This is unusually rich disclosure of constraints, failure modes, and data retention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and the view-mode semantics before constraints, and essentially every sentence carries non-redundant information. It is a dense single paragraph rather than a broken-up list, which slightly raises scan cost, but there is no filler to cut.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 restated. Combined with coverage of rate limits, JS limitations, error behavior, and handle retention, the description gives an agent everything needed to call this correctly on the first attempt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, but the `view` enum has no per-value schema description, and the description fills exactly that gap by defining what markdown/outline/links/tables/find each return and noting that find requires `query`. It also clarifies the `table` index convention and the trimming behavior of max_tokens, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Fetch a public web page') plus a distinct value proposition ('return only the part you need instead of the raw HTML'). It names the sibling tools it is not (read_package_info, run_pipeline), so an agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this for any single page' and then names the alternatives with the exact condition that selects each: read_package_info for PyPI/npm/crates.io, run_pipeline for multi-step extraction like filtering table rows. When-to-use and when-not-to-use are both present with concrete examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one of the 43 ops by id: returns the value, or for large results a preview and a handle id (h_...) to pass as the next op's input. Ops by category: data: json_parse, get, filter, pick, pluck, sort, unique, count_by, stats; format: to_markdown, to_csv, to_text, join, template; compute: calc, now, date_info, date_add, date_diff, encode, decode, url_parse, validate; html: html_clean, html_to_text, select, extract_links, extract_tables, extract_meta; structure: outline; network: fetch; text: find, contains, slice, fit, chunk, replace, split, regex_extract, normalize, count, diff; integrity: hash. Use this for a single step on data you already have; chain two or more with run_pipeline (only the final result comes back). For a standalone answer prefer the front-door tools: calculate_expression over calc, calculate_date over now and date_*, read_page over fetch. Unsure of an op's args? discover_ops(op=). Handles are kept for 60 minutes. Only fetch touches the network (public addresses only, 60 a minute per client); all ops share a limit of 1200 steps a minute. Wrong arg names or types return the op's expected args and a did-you-mean. Example: run_op(op="json_parse", input="{'a': 1,}", args={"lenient": true}).
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Op id from the list above, e.g. 'html_to_text'. | |
| args | No | The op's arguments, e.g. {"url": "https://example.com"} for fetch. | |
| input | No | The data to work on: a handle id (h_...) from an earlier result, or a literal value. Omit for ops that take none (fetch, calc, now). | |
| terse | No | Return only the answer (value, or handle and preview), without steps, hashes or hints. | |
| input_type | No | Override the inferred type of a literal input, e.g. 'html' for markup passed as a string. | |
| inline_max_tokens | No | Return the value itself when it's at most this many estimated tokens, else a preview. Default 300. |
| Name | Required | Description |
|---|---|---|
| value | No | terse: the value itself. |
| handle | No | terse, large result: its handle id. |
| result | No | The handle: id, type, size, est_tokens, value or preview, next ops. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, openWorld, non-idempotent). The description adds genuinely useful operational context: handle TTL of 60 minutes, rate limits (fetch 60/min, all ops 1200 steps/min), network restricted to fetch, and the wrong-arg error/typo-suggestion behavior. However, the preview/handle mechanics are largely restated by the input schema's inline_max_tokens, so this sits above baseline rather than maximal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then return behavior, routing, op catalog, limits, and an example. Dense and nearly waste-free, though the inline 43-op catalog makes it long; that catalog is arguably discover_ops territory but does save a round trip.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value details need not be repeated, yet the description still covers the preview/handle return path, TTL, limits, and error behavior. 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.
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 description earns extra by explaining that input may be a literal or an h_... handle and must be omitted for ops taking none (fetch, calc, now), and by giving a worked args example — meaning beyond the schema's field-level text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (run an op by id) and immediately disambiguates scope: single step vs. run_pipeline for chains, and front-door tools over low-level ops. An agent can route correctly without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('single step on data you already have'), when-not ('chain two or more with run_pipeline'), and named alternatives ('calculate_expression over calc', 'read_page over fetch'). It even routes to discover_ops when arg shape is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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"}].
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes | Ordered steps, 1 to 50. A literal string starting with $ is written $$. | |
| terse | No | Return only the answer (value, or handle and preview), without steps, hashes or hints. | |
| dry_run | No | Validate and estimate without running. | |
| result_from | No | Which step to return, as a ref like "$2" or "$prices[0]". Default: the last step. | |
| inline_max_tokens | No | Return the value itself when it's at most this many estimated tokens, else a preview. Default 300. |
| Name | Required | Description |
|---|---|---|
| steps | No | Per step: op, handle, type, est_tokens, ms. |
| valid | No | dry_run: whether it would run. |
| value | No | terse: the value itself. |
| handle | No | terse, large result: its handle id. |
| result | No | The returned step's handle, as in run_op. |
| totals | No | dry_run: the estimate: steps, cost, side effects (e.g. reads_network), deterministic. |
| problems | No | dry_run: what would fail, per step. |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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). |
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.
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.
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.
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.
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.
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.
Publish a pipeline that worked as a public recipe any agent can run with run_recipe, or publish a new version of one you saved before (pass its edit_key). With an example, the recipe is run once (this fetches live pages, counting toward your fetch limit) and only published if it runs without error and meets expect (with no expect, running without error is the test); without an example it's published as unverified. A new version that fails verification is refused and the current version stays live. Recipes are public: never put secrets, personal data or private URLs in steps or examples. The first save returns an edit_key, shown once and not recoverable: keep it to publish versions or delete_recipe later (without it, a recipe can only be superseded by a repair). To fix someone else's broken recipe, save yours under a new name with repairs=; discover_ops(query=...) then lists yours first. Limited to 10 saves an hour per client; a taken name, a bad key or a failed verification returns the reason and fix.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 3-64 lowercase letters, digits or underscores, e.g. acme_pro_price. Must be new unless edit_key is given. | |
| steps | Yes | Pipeline steps as in run_pipeline, with {{param}} where values vary, e.g. {"op": "fetch", "args": {"url": "{{url}}"}}. | |
| author | No | Optional public credit, up to 40 characters. | |
| expect | No | What a correct result looks like: type, non_empty, min_items, max_items, min_chars, columns, contains, matches, schema. e.g. {"type": "table", "columns": ["Plan", "Price"]}. | |
| params | No | Each {{param}}: {"type": "string", "description": "...", "default"?: ...}. Every {{param}} in steps must be declared. | |
| example | No | Param values known to work, e.g. {"url": "https://example.com"}. Used to verify now and to health-check later. Strongly recommended. | |
| repairs | No | Name of an existing recipe this one fixes. | |
| edit_key | No | To publish a new version of your recipe: the key from its first save. | |
| description | Yes | 10-300 characters: what it returns and when to use it. Search matches on this text. | |
| result_from | No | Ref of the step to return; default the last. |
| Name | Required | Description |
|---|---|---|
| recipe | Yes | The recipe as published, with version and track record. |
| edit_key | No | First save only, shown once: needed to publish versions or delete. |
| verified | Yes | Whether the example ran and met expect. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds a lot beyond annotations: the example is run once against live pages counting toward a fetch limit, unverified publishing without an example, failed verification refusal keeping the current version live, edit_key shown once and unrecoverable, and a 10-saves/hour rate limit. The secrets/privacy warning and error-return behavior are also disclosed. Minor gap: annotations say destructiveHint=false while this publicly publishes content, which is arguably an irreversible public write, but the description does clarify the public/unrecoverable-key risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and the run_recipe/delete_recipe routing, and nearly every sentence carries weight. It is dense—packing verification, secrets, edit_key, repairs, and rate limits into one block—and could benefit from clearer separation, but little is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, an output schema present, and rich annotations, the description covers the edge cases an agent needs: verification semantics, key recovery, name collisions, repair flow, and rate limits. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 genuine meaning: edit_key's role in versioning, repairs linking to a named recipe, example driving verification, and name uniqueness rules. It goes beyond restating the schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Publish a pipeline that worked as a public recipe'. It immediately distinguishes itself from run_recipe (run it), delete_recipe, and discover_ops, so an agent can separate this from all relevant siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit about the two modes (new recipe vs. new version via edit_key), how to fix someone else's recipe (repairs=<their name>), and when verification applies (with/without example). Alternatives are named with the conditions that select them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calculatecalculate_datecalculate_expressiondatesdelete_recipediscoverdiscover_opsinspectinvokepackage_inforead_handleread_package_inforead_page12 fields changedInput schema / properties / max_tokens / descriptionPrevious value: -"Most tokens to return; markdown is trimmed to fit."New value: +"Most tokens to return. markdown is trimmed (and marks the cut); other views return a preview and handle instead."Input schema / properties / max_tokens / titleRemoved value: -"Max Tokens"Input schema / properties / query / descriptionPrevious value: -"find: what to look for. links: keep links containing it."New value: +"find: the word or phrase to look for (required). links: keep links whose URL or text contains it."Input schema / properties / query / titleRemoved value: -"Query"Input schema / properties / table / descriptionPrevious value: -"tables: which one, 0 = first, -1 = last."New value: +"tables: which table, 0 = first, -1 = last."Input schema / properties / table / titleRemoved value: -"Table"Input schema / properties / url / descriptionPrevious value: -"The page to read (http or https)."New value: +"Public http(s) URL of the page."Input schema / properties / url / titleRemoved value: -"Url"Input schema / properties / view / titleRemoved value: -"View"Input schema / titleRemoved value: -"read_pageArguments"Output schema / propertiesAdded value: +{
+ "handle": {
+ "description": "Handle id (h_...) of the full result, for run_op or read_handle.",
+ "type": "string"
+ },
+ "preview": {
+ "description": "Instead of value, when the result is over max_tokens."
+ },
+ "value": {
+ "description": "markdown/outline: text. links: [{href, text}]. tables: markdown table. find: [{match, context, line, offset}]."
+ },
+ "warning": {
+ "additionalProperties": true,
+ "description": "The result looks wrong for this view, e.g. empty.",
+ "type": "object"
+ }
+}Output schema / titleRemoved value: -"read_pageDictOutput"run_oprun_pipeline16 fields changedInput schema / $defsAdded 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"
+ }
+}Input schema / properties / dry_run / descriptionPrevious value: -"Check refs, args, types, cost and side effects without running anything."New value: +"Validate and estimate without running."Input schema / properties / dry_run / titleRemoved value: -"Dry Run"Input schema / properties / inline_max_tokens / descriptionPrevious 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."Input schema / properties / inline_max_tokens / titleRemoved value: -"Inline Max Tokens"Input schema / properties / result_from / titleRemoved value: -"Result From"Input schema / properties / steps / descriptionPrevious 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 $$."Input schema / properties / steps / items / $refAdded value: +"#/$defs/Step"Input schema / properties / steps / items / additionalPropertiesRemoved value: -trueInput schema / properties / steps / items / typeRemoved value: -"object"Input schema / properties / steps / titleRemoved value: -"Steps"Input schema / properties / terse / descriptionPrevious 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."Input schema / properties / terse / titleRemoved value: -"Terse"Input schema / titleRemoved value: -"run_pipelineArguments"Output schema / propertiesAdded 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."
+ }
+}Output schema / titleRemoved value: -"run_pipelineDictOutput"run_recipe14 fields changedInput schema / properties / dry_run / descriptionAdded value: +"Return the plan with params filled in, without running or counting anything."Input schema / properties / dry_run / titleRemoved value: -"Dry Run"Input schema / properties / inline_max_tokens / descriptionPrevious 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."Input schema / properties / inline_max_tokens / titleRemoved value: -"Inline Max Tokens"Input schema / properties / name / descriptionPrevious value: -"Recipe name, e.g. 'page_to_markdown'. discover() lists them."New value: +"Recipe name, e.g. 'page_tables'."Input schema / properties / name / titleRemoved value: -"Name"Input schema / properties / params / descriptionPrevious 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."Input schema / properties / params / titleRemoved value: -"Params"Input schema / properties / terse / descriptionPrevious 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."Input schema / properties / terse / titleRemoved value: -"Terse"Input schema / properties / versionAdded 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."
+}Input schema / titleRemoved value: -"run_recipeArguments"Output schema / propertiesAdded 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"
+ }
+}Output schema / titleRemoved value: -"run_recipeDictOutput"save_recipe23 fields changedInput schema / properties / author / descriptionPrevious value: -"Optional name for whoever made this, up to 40 characters."New value: +"Optional public credit, up to 40 characters."Input schema / properties / author / titleRemoved value: -"Author"Input schema / properties / description / descriptionPrevious value: -"One sentence: what it returns and when to use it. Other agents find recipes by this text."New value: +"10-300 characters: what it returns and when to use it. Search matches on this text."Input schema / properties / description / titleRemoved value: -"Description"Input schema / properties / edit_key / descriptionPrevious value: -"To publish a new version of a recipe you saved before: the edit key you got back then."New value: +"To publish a new version of your recipe: the key from its first save."Input schema / properties / edit_key / titleRemoved value: -"Edit Key"Input schema / properties / example / descriptionPrevious value: -"Param values that should work, e.g. {\"url\": \"https://example.com\"}. The recipe is run with them before it's accepted, and health-checked with them later. Strongly recommended."New value: +"Param values known to work, e.g. {\"url\": \"https://example.com\"}. Used to verify now and to health-check later. Strongly recommended."Input schema / properties / example / titleRemoved value: -"Example"Input schema / properties / expect / descriptionPrevious value: -"What a correct result looks like, so a quietly broken recipe counts as failing: type, non_empty, min_items, max_items, min_chars, columns, contains, matches, schema. e.g. {\"type\": \"table\", \"min_items\": 1, \"columns\": [\"Plan\", \"Price\"]}."New value: +"What a correct result looks like: type, non_empty, min_items, max_items, min_chars, columns, contains, matches, schema. e.g. {\"type\": \"table\", \"columns\": [\"Plan\", \"Price\"]}."Input schema / properties / expect / titleRemoved value: -"Expect"Input schema / properties / name / descriptionPrevious value: -"3-64 lowercase letters, digits or underscores, e.g. acme_pro_price."New value: +"3-64 lowercase letters, digits or underscores, e.g. acme_pro_price. Must be new unless edit_key is given."Input schema / properties / name / titleRemoved value: -"Name"Input schema / properties / params / descriptionPrevious value: -"Each {{param}}: {\"type\": \"string\", \"description\": \"...\", \"default\"?: ...}."New value: +"Each {{param}}: {\"type\": \"string\", \"description\": \"...\", \"default\"?: ...}. Every {{param}} in steps must be declared."Input schema / properties / params / titleRemoved value: -"Params"Input schema / properties / repairs / descriptionPrevious value: -"If this fixes another recipe that's broken, its name. Search will then offer yours in its place."New value: +"Name of an existing recipe this one fixes."Input schema / properties / repairs / titleRemoved value: -"Repairs"Input schema / properties / result_from / titleRemoved value: -"Result From"Input schema / properties / steps / descriptionPrevious value: -"Pipeline steps, with values that vary written as {{param}}, e.g. {\"op\": \"fetch\", \"args\": {\"url\": \"{{url}}\"}}."New value: +"Pipeline steps as in run_pipeline, with {{param}} where values vary, e.g. {\"op\": \"fetch\", \"args\": {\"url\": \"{{url}}\"}}."Input schema / properties / steps / titleRemoved value: -"Steps"Input schema / titleRemoved value: -"save_recipeArguments"Output schema / propertiesAdded value: +{
+ "edit_key": {
+ "description": "First save only, shown once: needed to publish versions or delete.",
+ "type": "string"
+ },
+ "recipe": {
+ "additionalProperties": true,
+ "description": "The recipe as published, with version and track record.",
+ "type": "object"
+ },
+ "verified": {
+ "description": "Whether the example ran and met expect.",
+ "type": "boolean"
+ }
+}Output schema / requiredAdded value: +[
+ "recipe",
+ "verified"
+]Output schema / titleRemoved value: -"save_recipeDictOutput"calculatedatespackage_inforead_pageinvoke1 field changedInput schema / properties / terseAdded value: +{
+ "default": false,
+ "description": "Return just the answer: the value if small, else a handle with a short preview.",
+ "title": "Terse",
+ "type": "boolean"
+}run_pipeline1 field changedInput schema / properties / terseAdded value: +{
+ "default": false,
+ "description": "Return just the answer: the value if small, else a handle with a short preview.",
+ "title": "Terse",
+ "type": "boolean"
+}run_recipe1 field changedInput schema / properties / terseAdded value: +{
+ "default": false,
+ "description": "Return just the answer: the value if small, else a handle with a short preview.",
+ "title": "Terse",
+ "type": "boolean"
+}save_recipe7 fields changedInput schema / properties / authorAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional name for whoever made this, up to 40 characters.",
+ "title": "Author"
+}Input schema / properties / description / descriptionPrevious value: -"One sentence: what it returns, for other agents searching later."New value: +"One sentence: what it returns and when to use it. Other agents find recipes by this text."Input schema / properties / edit_keyAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "To publish a new version of a recipe you saved before: the edit key you got back then.",
+ "title": "Edit Key"
+}Input schema / properties / exampleAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Param values that should work, e.g. {\"url\": \"https://example.com\"}. The recipe is run with them before it's accepted, and health-checked with them later. Strongly recommended.",
+ "title": "Example"
+}Input schema / properties / expectAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "What a correct result looks like, so a quietly broken recipe counts as failing: type, non_empty, min_items, max_items, min_chars, columns, contains, matches, schema. e.g. {\"type\": \"table\", \"min_items\": 1, \"columns\": [\"Plan\", \"Price\"]}.",
+ "title": "Expect"
+}Input schema / properties / repairsAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "If this fixes another recipe that's broken, its name. Search will then offer yours in its place.",
+ "title": "Repairs"
+}Input schema / properties / steps / descriptionPrevious value: -"Pipeline steps, with values to vary written as {{param}}, e.g. {\"op\": \"fetch\", \"args\": {\"url\": \"{{url}}\"}}."New value: +"Pipeline steps, with values that vary written as {{param}}, e.g. {\"op\": \"fetch\", \"args\": {\"url\": \"{{url}}\"}}."discoverinspectinvokerun_pipelinerun_recipesave_recipeExact IBAN, VAT, cron, regex answers; HTML/URL to hosted PDF or screenshot; agent memory; workflows.
Agent utility belt: memory, locks, webhook inboxes, timers, DNS, email, URL, timezone, cron
Free APIs for AI agents: web reading, text slicing, clock, ID keys, 1MB memory. No signup or fees.
Free HTML/CSV conversion, JSON validation, text stats and time APIs. Optional agent interviews.
Add one secure layer between your agents and this server.