String Utility Belt
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
248 string and data transformations (encode/decode, hash, encrypt, compress, convert between JSON, YAML, TOML, CSV and XML, change case, format, analyse), run on this machine with no network access. Find a utility with list_utilities, read its exact parameters with describe_utility, then run it with run_utility. Several transformations in a row go in one run_pipeline call instead of a run_utility call each. detect_format identifies an unknown input (base64, JWT, gzip, …) before you pick a utility.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_utilitiesA | 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. |
| describe_utilityA | 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. |
| run_utilityA | Run a single utility on |
| run_pipelineA | Run several transformations on |
| detect_formatA | Guess what |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| utilities | The full utility catalog as JSON: id, name, category, description, tags and aliases for every utility. |
TDQS
Scored 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.