Skip to main content
Glama

Extcord

by io.extcord
OverviewDiscussionsAdmin

run_op

Read-only

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}).

Input Schema

NameRequiredDescriptionDefault
opYesOp id from the list above, e.g. 'html_to_text'.
argsNoThe op's arguments, e.g. {"url": "https://example.com"} for fetch.
inputNoThe 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).
terseNoReturn only the answer (value, or handle and preview), without steps, hashes or hints.
input_typeNoOverride the inferred type of a literal input, e.g. 'html' for markup passed as a string.
inline_max_tokensNoReturn the value itself when it's at most this many estimated tokens, else a preview. Default 300.

Output Schema

NameRequiredDescriptionDefault
valueNoterse: the value itself.
handleNoterse, large result: its handle id.
resultNoThe handle: id, type, size, est_tokens, value or preview, next ops.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior3/5

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.

Conciseness4/5

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.

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-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.

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 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.

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 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.

Usage Guidelines5/5

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.

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