stringutilitybelt.com · Usage guide · All utilities · Integrations
Chain string transformations into visual pipelines with live, per-step previews. 246 utilities — encodings, hashes, ciphers, compression, data formats (JSON/YAML/TOML/CSV/XML), line and text operations, analysis, generators, web/dev helpers, numbers, dates and colours — all running client-side, with the same engine available as a CLI, an HTTP API, an MCP server, a browser extension and a VS Code extension.
Every utility also runs on your own machine, outside the browser:
# Give Claude Code (or any MCP client) exact hashing, encoding and decoding instead of a guess
claude mcp add subelt -- npx -y @string-utility-belt/mcp
# Pipe text through a pipeline from the shell
echo 'eyJ1c2VyIjoiYWRhIn0=' | npx subelt base64_decode json_prettyMCP server — @string-utility-belt/mcp: five tools (search, describe, run a
utility, run a pipeline, detect a format); config for Claude Desktop, Cursor and other clients in its README.
CLI — subelt: steps as arguments, stdin to stdout, share links and pipeline files.
Editors and browsers — the VS Code extension (also on Open VSX for Cursor and VSCodium) and the Chrome extension.
Library — @string-utility-belt/core, the engine with every utility, for your own code.
Related MCP server: Utility Belt MCP
Pipelines — add, reorder (drag and drop), duplicate, disable/solo steps; undo/redo; per-step previews, diffs, timings and error policies (pass through / stop / empty); conditional steps; parallel branches with concat/zip/json/pick merges; macros (collapse a sub-chain into one step); "run on each" steps (run a sub-chain on every line, delimited piece, JSON array element or object value).
Share and save — pipelines (and optionally the input) as compressed #/p/… links, a named
pipeline library with JSON import/export, a preset gallery, an embeddable #/embed/… widget.
Magic — detects the input's format (base64, JWT, gzip, JSON, …) and suggests or appends the decoding step; "decode until stable" mode.
Input/output — file upload (text and binary), fetch-a-URL via the Worker proxy, input history, side-by-side and diff views, hex view for bytes, syntax highlighting, stats bar, smart download names, copy-as (raw / JSON literal / hex / base64).
Engine — runs in a Web Worker with cancellation, adaptive debounce, a chunked mode for multi-MB inputs and a preview-first-64 KB option; custom JavaScript steps run in a sandboxed, network-less iframe + worker, and are quarantined when they arrive from someone else's link.
App — command palette (Ctrl+K), keyboard shortcuts (?), fuzzy utility search with
favourites/recents and type-aware badges, light/dark themes, per-utility doc pages with a live
playground, installable PWA with offline support and an OS share target, i18n scaffold.
Open stringutilitybelt.com — nothing to install, and every
transformation runs in your browser (see the privacy policy
for the few features that contact the server). The site sets no cookies and runs no tracking
scripts: Cloudflare Web Analytics counts page views without cookies, the site's own server counts
clicks on sponsor and tool links by id alone, neither ever receives what you paste, and the site's
Content-Security-Policy blocks scripts from anywhere else. The how-to guide lives in the app
itself: click Docs in the header, or go to /docs/. Each
utility's settings and examples are on its own page, listed at
/utilities/.
From a terminal, the same engine is one command away:
echo -n hello | npx subelt trim base64_encode hash # SHA-256 of the base64Requires Node.js 20.19+ or 22.12+.
git clone https://github.com/String-Utility-Belt/string-utility-belt.git
cd string-utility-belt
npm ci
npm run dev # generates the utility manifest, then starts Vite
npm test # Vitest (unit, component, golden-example and property tests)
npm run lint
npm run typecheckCommand | What it does |
| Regenerate |
| Production build of the web app |
| Enforce the entry-chunk budget in |
| Pre-render utility pages, sitemap, RSS and OG images into |
|
|
| Build |
| Playwright end-to-end tests against a production build |
| Large-input benchmarks ( |
|
|
| What a release from |
| Re-record this README's demo GIF from the production build (after |
Surface | Where | Notes |
Core library | Framework-free engine + all utilities | |
CLI |
| |
MCP server | Utilities and pipelines as agent tools over stdio | |
HTTP API |
| |
Browser extension | MV3; context menu "run on selection" | |
VS Code extension | Transform selection, run a share link |
String Utility Belt is free, open source and has no paid tier. If it saves you time, you can support its development through GitHub Sponsors: it pays for hosting and keeps new utilities, presets and fixes coming. Companies can also sponsor a page on the site.
Contributions are welcome — bug reports, utility ideas and pull requests. Start with CONTRIBUTING.md (setup, adding a utility, PR checklist) and the Code of Conduct. CLAUDE.md is the detailed architecture reference.
Found a security issue? Please report it privately — see SECURITY.md.
Full documentation for one utility: its parameters (kind, default, options/bounds, description), the value types it accepts/produces, tags, aliases, worked examples (input, inputEncoding, params and expected output — byte outputs there use the app's display format, while run_utility returns bytes as base64), and which runtime capabilities it needs. Call this before run_utility to learn the exact parameter names and defaults; skip it for a utility you have already described. id must be an exact, case-sensitive utility id: names and aliases are not resolved, so look those up with list_utilities first. An unknown id returns isError ("unknown utility: "). When unavailable is set, run_utility and run_pipeline refuse the utility.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Utility id, as returned by list_utilities (e.g. "base64_encode"). |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| env | Yes | Runtime capabilities the utility needs (dom, wasm, eval, main). |
| name | Yes | |
| tags | Yes | |
| params | Yes | Parameter name -> spec (kind, label, default, options/bounds, description…). |
| accepts | Yes | Value type(s) the utility takes: string, bytes or json. |
| aliases | Yes | |
| category | Yes | |
| examples | Yes | Worked examples: input, params and expected output. |
| produces | Yes | Value type(s) the utility returns. |
| description | Yes | |
| unavailable | No | Why this server will not run the utility, when it will not. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds genuinely non-structured behavior: the exact error shape for an unknown id ("isError ('unknown utility: <id>')"), the effect of the `unavailable` flag on run_utility/run_pipeline, and the byte-format discrepancy between describe output (display format) and run_utility (base64). These are operationally important details an agent cannot infer from annotations or schema.
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?
Information is front-loaded (purpose first, then when-to-call, id semantics, and error/availability notes) and every clause carries weight. The first sentence is a long multi-clause construction with nested parentheticals, which slightly hurts scannability, but there is 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?
Despite the tool's low complexity, the description covers the prerequisite ordering (list_utilities -> describe_utility -> run_utility), parameter strictness, failure mode, and availability semantics. With an output schema already documenting the return shape, 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?
Although the single-param schema has 100% description coverage, the description goes beyond it by specifying that `id` is exact and case-sensitive, that names/aliases are NOT resolved, that list_utilities must be consulted first, and what a bad id yields. That materially reduces failed calls in a way the schema line ("Utility id, as returned by list_utilities") does not.
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 opens with a specific verb+resource ("Full documentation for one utility") and enumerates exactly what that documentation contains (parameters, types, tags, examples, runtime capabilities). It is identifiable against siblings because it names run_utility, run_pipeline, and list_utilities and the distinct role each plays.
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 states the trigger ("Call this before run_utility to learn the exact parameter names and defaults"), the exclusion ("skip it for a utility you have already described"), and routes id discovery to the alternative tool ("look those up with list_utilities first"). This is explicit when/when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Guess what input is — JSON, YAML, TOML, XML, HTML, CSV/TSV, base64/base32/hex, URL-encoding, JWT, UUID, data URI, gzip/zlib, email, URL, IP address, unix timestamp, Markdown, SQL, Morse code, ROT13, plain binary — and return {candidates: [{format, confidence, note}]}, best first, confidence 0-1. Use it when you are handed an opaque or unlabelled value and must pick a utility for it; skip it when the format is already known. It only identifies, never transforms: to decode, search list_utilities for the top format (base64 -> base64_decode, JWT -> jwt_decode) and run that with run_utility. Ambiguous input yields several candidates (all-digit text can be a timestamp, JSON and hex at once); treat anything below about 0.45 as a weak guess. Use inputEncoding "base64"/"hex" only to deliver binary data such as gzip bytes: it is decoded before detection, so a base64 string you want identified must stay "text" (the default). Empty input yields an empty list.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The value to inspect. | |
| inputEncoding | No | How to decode `input` first. Default "text". |
| Name | Required | Description |
|---|---|---|
| candidates | Yes | Likely formats, best first; confidence is 0-1. Empty for empty input. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, openWorldHint=false), yet the description still adds real behavior: it identifies but never transforms, ambiguous input returns multiple candidates, low-confidence results are weak guesses, and empty input yields an empty list. That is genuine operational context, though it doesn't discuss cost, size limits, or performance on large inputs.
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?
Purpose and return shape are front-loaded, and the trailing clauses all carry actionable content (threshold, encoding caveat, empty-input case). The long mid-sentence format enumeration is heavier than necessary, but it does set expectation for candidate breadth.
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 values needn't be explained, and the description still previews the candidates/best-first shape. With only two parameters, both annotated in the schema and clarified in prose, nothing an agent needs to invoke 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 clarifying the counterintuitive `inputEncoding` semantics: base64/hex are for delivering binary bytes, not for identifying a base64-looking string, which must stay "text". This is meaning the schema's one-line description does not convey.
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 (detect/guess) and resource (an opaque `input` value), enumerates the concrete format families it recognizes, and names the sibling tools (list_utilities, run_utility) it hands off to. An agent can distinguish it from all four siblings 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 routing: 'Use it when you are handed an opaque or unlabelled value... skip it when the format is already known,' plus the follow-on workflow (search list_utilities for the top format, then run_utility). Also supplies the confidence threshold (~0.45) that decides whether a candidate is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the string-transformation utilities this server can run (247 total, across categories like Encoding, Hashing, Ciphers, Compression, Data Formats, Analysis, Generators and more). Returns {items: [{id, name, category, description}], total, categories}, best matches first. Use this first to find an id, then call describe_utility for its exact parameters before run_utility. category and query combine (a utility must match both); omit both to browse the whole catalog. A category that does not exist matches nothing rather than failing, so take one from categories. There is no paging: when total exceeds the items returned, raise limit or narrow the query. Reads the bundled catalog only: no network access and no rate limit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default 50, max 500). | |
| query | No | Search words, matched case-insensitively against id, name, tags, aliases and description; every word must match somewhere, in any order (e.g. "encode url", "sha256", "uppercase"). | |
| category | No | Category to filter to (case-insensitive), e.g. "Encoding" or "Hashing". |
| Name | Required | Description |
|---|---|---|
| items | Yes | Matching utilities, best first, up to `limit`. |
| total | Yes | How many utilities matched before `limit` was applied. |
| categories | Yes | Every category name, for filtering. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint=false; the description goes well beyond them, disclosing that it reads a bundled catalog with no network access and no rate limit. It also documents the no-paging behavior and the remedy when `total` exceeds returned items, which is real operational context.
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-loads what it searches, then return shape, then the call sequence, then edge cases. It is longer than average but every clause adds a distinct, actionable fact with no restatement of the title or schema.
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, yet the description still names the return shape and the paging caveat, and it covers filtering, failure behavior, and follow-up calls. Nothing an agent needs to invoke 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 per-parameter meaning is already carried by the schema and the baseline is 3. The description adds non-schema value anyway: the AND semantics when `category` and `query` combine, the instruction to source category values from `categories`, and the limit-raising workaround.
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 ('Search the string-transformation utilities this server can run') plus scale and category coverage, so the agent immediately knows this is a catalog search, not an execution tool. The sibling relationship to describe_utility and run_utility is made explicit in the same breath.
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 call order ('Use this first to find an id, then call describe_utility for its exact parameters before run_utility') and an explicit when-to-omit condition ('omit both to browse the whole catalog'). It even pre-empts a failure mode by telling the agent to take a category from `categories` since unknown categories match nothing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run several transformations on input in one call: an ordered list of steps (string-utility-belt v3 schema), each step's output feeding the next. Besides utility steps, a pipeline can hold branches (parallel forks merged back together), macros (named sub-pipelines) and "run on each" steps (a sub-pipeline run on every line, delimited piece, JSON array element or JSON object value). Prefer this to chaining run_utility calls; for a single transformation, run_utility is simpler. Returns {output, outputEncoding?, errors, timings, skipped, halted}: errors maps step id to its error message, timings maps step id to milliseconds. Provide exactly one of steps or share (a #/p/<payload> share link, a full URL containing one, or the bare payload). Untrusted step data is sanitized first, so malformed entries are dropped rather than rejected. Refused outright: pipelines with more than 100 steps (nested steps counted), unknown utility ids, enabled steps with invalid params, and any step that would run arbitrary user JavaScript (e.g. "custom_js") — LLM-driven code execution is out of scope. Input is capped at 1,000,000 bytes, output text past 1,000,000 characters is cut off (flagged truncated, with fullLength), and the call is stopped after 20s.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The pipeline's source input. | |
| share | No | A share link (or its bare payload) for a previously built pipeline; used instead of `steps`. | |
| steps | No | Pipeline steps (v3 schema). Each entry is either a utility step {id, utilityId, params?, enabled?, condition?, onError?}, a fork {type:"branch", id, branches:[[...steps], [...steps]], merge:{mode:"concat"|"zip"|"json"|"pick", ...}}, a sub-pipeline {type:"macro", id, name, steps:[...steps]}, or a map {type:"each", id, split:{mode:"lines"|"json-array"|"json-values"} or {mode:"delimiter", separator}, steps:[...steps], skipEmpty?} that runs `steps` on every item and puts the results back in place (on an each step, `onError` also decides what a failed item becomes). `condition` gates a step on its input ({kind:"always"|"nonEmpty"|"regex"|"type", ...}); `onError` is "passthrough" (default: record the error, pass the input on), "stop" or "empty". Use [] for the identity pipeline; omit when using `share`. | |
| inputEncoding | No | How to decode `input`. Default "text". |
| Name | Required | Description |
|---|---|---|
| errors | Yes | Step id -> error message, for steps that failed. |
| halted | Yes | True when a step with onError "stop" failed and ended the pipeline. |
| output | Yes | The result: text as-is, JSON pretty-printed, bytes as base64. |
| skipped | Yes | Step id -> why it did not run (disabled, condition, halted, aborted). |
| timings | Yes | Step id -> milliseconds it took. |
| truncated | No | True when `output` was cut off at the output limit. |
| fullLength | No | Length `output` would have had untruncated, when `truncated`. |
| outputEncoding | No | Present when `output` is base64-encoded bytes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint=true and openWorldHint=false; the description goes far beyond by disclosing sanitization of untrusted step data, outright refusal conditions (100-step cap, unknown utility ids, invalid params, JS execution), an explicit 1,000,000-byte input cap, 1,000,000-char output truncation with `truncated`/`fullLength`, and a 20s timeout. This is unusually complete behavioral disclosure for a computation tool.
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?
Long but information-dense and front-loaded: composition model first, then routing, then constraints. Nearly every sentence carries distinct constraints or semantics, though the single-paragraph density slightly strains 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?
For a complex multi-step computation tool with a rich nested-step schema, the description covers composition forms, refusal conditions, limits, and return shape. With an output schema present, it need not explain returns further, and nothing needed 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 100%, so the baseline is 3, but the description adds real meaning: the exactly-one-of constraint between `steps` and `share`, that `share` may be a link, a URL containing one, or the bare payload, and the error/timing map semantics of `errors` and `timings`.
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 several transformations on `input` in one call), explains the ordered-step composition model, and explicitly distinguishes itself from the run_utility sibling. An agent can tell it apart from list_utilities/describe_utility/run_utility 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?
Explicitly states the selection rule: prefer this to chaining run_utility calls, but for a single transformation run_utility is simpler. It also states when to use `share` vs `steps`, giving both the positive and negative routing conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a single utility on input and return {output, outputEncoding?}. For two or more transformations in a row, make one run_pipeline call instead of chaining run_utility calls; if you do not know the id yet, find it with list_utilities. Plain text output is returned as-is; a JSON-producing utility returns pretty-printed JSON text; a byte-producing utility (e.g. gzip_compress, get_bytes) returns base64 with outputEncoding: "base64". inputEncoding controls how input itself is decoded first: "text" (default) uses it as-is, "base64" or "hex" decode it to raw bytes, "json" parses it. Params are validated against describe_utility's spec; invalid ones are rejected. Input is capped at 1,000,000 bytes, output text past 1,000,000 characters is cut off (flagged truncated, with fullLength), and the call is stopped after 20s. A failing utility returns isError with the error message. Utilities that run arbitrary user JavaScript (e.g. "custom_js") are refused, and the few that need a browser DOM parser (e.g. "xml_to_json", "html_table_to_csv") fail here.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Utility id (see list_utilities / describe_utility). | |
| input | Yes | The value to run the utility on. | |
| params | No | Utility parameters (see describe_utility for names/kinds); params left out use their declared default. | |
| inputEncoding | No | How to decode `input` before passing it to the utility. Default "text". |
| Name | Required | Description |
|---|---|---|
| output | Yes | The result: text as-is, JSON pretty-printed, bytes as base64. |
| truncated | No | True when `output` was cut off at the output limit. |
| fullLength | No | Length `output` would have had untruncated, when `truncated`. |
| outputEncoding | No | Present when `output` is base64-encoded bytes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far exceeds the annotations (readOnlyHint/openWorldHint): it discloses output encoding rules (plain text as-is, pretty-printed JSON, base64 bytes with `outputEncoding`), hard limits (1,000,000-byte input cap, output truncated past 1,000,000 characters with `truncated`/`fullLength` flags), a 20s timeout, error behavior (isError with message), and outright refusals (custom_js) and documented failures (xml_to_json, html_table_to_csv). This is exactly the behavioral context annotations cannot carry.
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 pipeline alternative, and nearly every sentence carries distinct operational information (encoding, limits, errors, refusals). It is dense and longer than typical, but not padded; the only mild cost is that limits/errors/refusals are packed into one long trailing sentence.
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 4-param tool with an output schema and only two booleans of annotation coverage, the description fills every remaining gap: encoding of both input and output, validation source, caps, timeout, truncation signaling, and known unsupported utilities. 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 100%, so the baseline is 3, but the description adds real semantics beyond the schema: it explains what each `inputEncoding` value actually does ('base64'/'hex' decode to raw bytes, 'json' parses it) and that `params` are validated against describe_utility's spec with invalid ones rejected. The schema's own enum descriptions are thinner than this.
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+resource ('Run a single utility on `input`') plus the return shape, and explicitly distinguishes itself from the sibling run_pipeline ('make one run_pipeline call instead of chaining run_utility calls'). An agent can route between the two 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?
Gives explicit when-not guidance ('For two or more transformations in a row, make one run_pipeline call instead') and a fallback path when the required `id` is unknown ('find it with list_utilities'). Alternatives and their selecting conditions are both named.
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.
v1.8.0describe_utilitydetect_formatlist_utilitiesrun_pipelinerun_utilityScored across 5 tools
Each tool occupies a distinct phase of the workflow: list_utilities discovers ids, describe_utility fetches specs, run_utility executes one, run_pipeline executes many, and detect_format only identifies. The single-vs-multi boundary between run_utility and run_pipeline is explicitly stated, and detect_format is clearly non-overlapping since it never transforms.
All five names use consistent snake_case verb_noun form (list_utilities, describe_utility, run_utility, run_pipeline, detect_format). The verbs map cleanly onto the discover/describe/run/detect lifecycle with no stylistic drift.
Five tools is well-scoped for a meta-server fronting a 247-utility catalog; exposing one tool per utility would be absurd, and wrapping the surface as discover/describe/run/pipeline/detect is economical. No redundant or filler tools.
The full lifecycle (find id, read spec, execute single, execute chained, identify unknown input) is covered with sensible encoding and error handling. Minor gaps: no dedicated validation/introspection beyond describe_utility and no explicit catalog-listing mode beyond a broad list query, but these are workable.
Exact hashing, base64/hex/URL encoding, JWT decoding and UUIDs for AI agents. No auth required.
19 zero-setup utilities: JSON, regex, cron, hash, base64, CSV, JWT, UUID, YAML, semver, time.
500+ deterministic tools for AI agents: math, conversion, validation, hashing, encoding, date/time.
22 developer utilities: base64, hashes, JWT, JSON tools, unit conversion. Free, keyless.
