This server exposes String Utility Belt's 248 string-transformation utilities for discovery, documentation, execution, pipelining, and format detection.
Search/browse utilities by query and category with list_utilities, returning ids, names, categories, descriptions, totals, and available categories.
Get exact utility documentation with describe_utility before running it: parameters, defaults, accepted/produced types, examples, tags, aliases, and runtime needs.
Run a single utility with run_utility on text, base64, hex, or JSON input; byte outputs return as base64.
Run multi-step pipelines with run_pipeline, including branches, macros, per-item/each steps, conditions, and error policies; results include errors, timings, skipped steps, and halt status.
Detect likely input formats with detect_format, returning ranked candidates with confidence and notes to help choose the right decoder.
Operates on a bundled catalog with no network or rate limit; input is capped at 1,000,000 bytes, output at 1,000,000 characters, and calls time out after 20 seconds.
Refuses arbitrary user JavaScript utilities and some DOM-dependent utilities; describe_utility can flag unavailable utilities.
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, utilities added, editor opens and runs, and page loads that find the browser
extension, 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?
Beyond the readOnly/idempotent annotations, it discloses error behavior ("An unknown id returns isError (\"unknown utility: <id>\")") and a downstream consequence that annotations cannot express ("When `unavailable` is set, run_utility and run_pipeline refuse the utility"). It also flags a subtle format difference: byte outputs in examples use the app's display format while run_utility returns base64.
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 payload is front-loaded (what the doc contains, then usage order, then the id constraint) and every clause carries information. The dense parenthetical enumerating doc fields and the mid-sentence byte-format aside make it harder to scan than it needs to be, but nothing is padding.
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 explanation is not required, yet the description still characterizes the documentation shape well enough to set expectations. For a single-parameter lookup tool with full annotation coverage, an agent has everything needed to call it correctly and to interpret failure.
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% and the schema already says the id comes from list_utilities, so the baseline is 3; the description earns above that by adding that the id is exact and case-sensitive, that names and aliases are not resolved, and that an unknown id yields isError. That is real disambiguation the schema does not provide, though the example format is slightly redundant.
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 ("Full documentation for one utility") and immediately enumerates what that documentation contains (parameters, value types, tags, aliases, examples, runtime capabilities). This is clearly distinguishable from list_utilities (browsing) and run_utility (execution) named in the same description.
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_utility to learn the exact parameter names and defaults"), explicit when-not ("skip it for a utility you have already described"), and routes to the right alternative ("look those up with list_utilities first") when the id is not known. Little 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.
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 (readOnly, idempotent, non-destructive), and the description adds real behavior: it never transforms, only identifies; ambiguous input returns multiple candidates; scores below ~0.45 are weak guesses; empty input yields an empty list. The only shortfall is that it says nothing about cost/performance on large inputs, but as a pure read-only classifier that is minor.
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 usage, then the decode-vs-run handoff, then the encoding gotcha, then the empty-input edge case — good ordering with no wasted sentences. The very long inline format enumeration is informative but consumes a lot of the paragraph's budget; a compact list would read faster.
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 summarizes the return shape and the confidence interpretation threshold, which is the part an agent actually needs to act on results. Combined with the binary-vs-text encoding caveat and the "identify, never transform" boundary, nothing needed 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 already 100%, but the description adds a genuinely non-obvious rule the schema cannot convey: inputEncoding "base64"/"hex" is only for delivering binary payloads such as gzip bytes because it is decoded before detection, so a base64 string you want identified must stay "text". That is exactly the kind of guidance that prevents a silent misclassification.
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?
"Guess what `input` is" gives a specific verb and resource, and the enumerated format list (JSON, YAML, JWT, UUID, gzip, Morse, ROT13...) makes the scope concrete rather than vague. It also states the exact return shape {candidates: [{format, confidence, note}]}, best first, so an agent can distinguish it immediately from siblings like run_utility or list_utilities.
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 ("handed an opaque or unlabelled value and must pick a utility for it") and explicit when-to-skip ("skip it when the format is already known"). It also names the downstream alternative path — list_utilities then run_utility — including a concrete example mapping (base64 -> base64_decode, JWT -> jwt_decode).
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 (248 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 already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds real value beyond that: no network access, no rate limit, no paging, best-match ordering, and that unknown categories silently match nothing rather than erroring. It even explains the recovery path when total exceeds items returned.
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 the tool searches and its result shape, then workflow, then filter semantics, then edge cases. Every sentence introduces new information; none restates the name or the 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?
Covers the full call path from discovery to execution, filter interaction, pagination behavior and environment constraints, which is complete for a three-optional-parameter listing tool with an output schema. Nothing an agent needs in order 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 baseline is 3, but the description adds conjunctive AND semantics between category and query and tells the agent to source category values from the returned `categories` list. It also hints at limit as the remedy for truncated results, meaning that goes beyond the schema's bare maximum.
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') and immediately scopes it with the catalog size and category list. It is unambiguously a discovery tool, clearly distinct from describe_utility and run_utility, which it names.
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 ordered workflow: use this first to find an id, then describe_utility for parameters, then run_utility. It also specifies when to omit filters (browse the whole catalog) and how filters combine (a utility must match both).
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 already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantive behavior beyond them: sanitization drops malformed steps, refusal conditions (over 100 steps, unknown utility ids, custom_js), the 1,000,000-byte input cap, 20s timeout, and output truncation with `truncated`/`fullLength` flags. It stops short of describing merge or branch semantics in detail, but the added context is well above the annotation bar.
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 the core behavior and follows with alternatives, return shape, and limits in a logical order; every sentence carries information. The middle parenthetical about branch/macro/each is densely packed and overlaps the `steps` schema description, slightly reducing efficiency.
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 orchestration tool it covers invocation rules, step-schema vocabulary, return-value structure (errors/timings/skipped/halted), limits, and refusal conditions. Even though an output schema exists, the explicit return-field description is a helpful supplement rather than redundant.
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 a constraint the schema cannot express: 'Provide exactly one of `steps` or `share`' (surface is not modeled as oneOf in the schema). It also clarifies identity-pipeline usage via `[]` and gives a high-level vocabulary for branch/macro/each types that complements the schema's nested description.
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+scope: 'Run several transformations on `input` in one call' and immediately characterizes the ordered step chaining. It explicitly names run_utility as the sibling for single transformations, so an agent can discriminate without reading schemas.
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 routing rules: 'Prefer this to chaining run_utility calls; for a single transformation, run_utility is simpler.' It also states the mutually exclusive choice between `steps` and `share` and notes when to omit steps, leaving little to inference.
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?
Annotations already declare this a safe, idempotent read, so the description's job is to add operational context — and it does: base64 output encoding for byte-producing utilities, pretty-printed JSON for JSON utilities, the 1,000,000-byte input cap, 1,000,000-character output truncation with `truncated`/`fullLength` flags, a 20s timeout, and isError on failure. These are real behavioral traits an agent cannot infer from the annotations.
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 primary alternative before any detail, then layers output encoding, decoding semantics, limits, and error behavior in a logical order. Every sentence carries distinct information — no restatement of the name or the annotations.
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 dynamic-dispatch tool with nested free-form `params` and an output schema, the description covers everything an agent needs: how to discover ids, how input and output encodings work, validation behavior, size/time limits, truncation signalling, error signalling, and known unsupported utility classes. Nothing material is left to inference.
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 a step up by explaining what each `inputEncoding` value actually does to the bytes ('text' as-is, 'base64'/'hex' decode to raw bytes, 'json' parses) and by noting that omitted `params` fall back to declared defaults and are validated against describe_utility's spec. It stops short of describing individual utility param kinds, which is reasonable given they are dynamic.
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 ('Run a single utility on `input`') and states the return shape, immediately distinguishing it from the batch sibling by saying 'For two or more transformations in a row, make one run_pipeline call instead of chaining run_utility calls.' An agent can pick this tool over run_pipeline or list_utilities 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 routing rules: chain two or more steps through run_pipeline, resolve an unknown id via list_utilities, and check params via describe_utility. It also names when-not conditions (arbitrary-JS utilities are refused, DOM-parser utilities fail here), which is exactly the exclusion guidance most definitions omit.
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 maps to a distinct phase of the workflow: catalog discovery (list_utilities), documentation (describe_utility), single execution (run_utility), multi-step execution (run_pipeline), and identification (detect_format). The potentially confusable pair run_utility vs run_pipeline is explicitly delineated with guidance on when to use which.
All five tools follow a clean verb_noun snake_case pattern: list_utilities, describe_utility, run_utility, run_pipeline, detect_format. No mixed conventions or vague verbs.
Five tools is exactly right for a 248-utility meta-server: the catalog is accessed via discovery, docs, single-run, pipeline, and detection rather than one tool per utility. Each tool earns its place with no redundancy.
The surface covers the full lifecycle: find, learn, run, compose, and identify. Minor gaps exist around managing reusable macros or saving/inspecting prior results independently, but core workflows are fully supported.
Exact hashing, base64/hex/URL encoding, JWT decoding and UUIDs for AI agents. No auth required.
42 free deterministic utilities: JSON, CSV, YAML, encoding, hashing, JWT, cron, formatters, CSS.
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.
