Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}
resources
{
  "listChanged": true
}
completions
{}

Tools

Functions exposed to the LLM to take actions

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

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

run_utilityA

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.

run_pipelineA

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.

detect_formatA

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.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
utilitiesThe full utility catalog as JSON: id, name, category, description, tags and aliases for every utility.

TDQS

A4.7/5.0

Scored across 5 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityActive
ResponsivenessNo recent community issues