Skip to main content
Glama

encode

Read-onlyIdempotent

Bring your own text -> the cheapest substrate for your reader — the MCP twin of HTTP POST /v1/encode.

Requires $0.01–$0.05 USDC (x402) or an Authorization Bearer trial/paid key.
On payment_required, call fillin_probe then fillin_signup (POST /v1/signup)
for a free 20-query trial, or fillin_payment_challenge then retry with
X-Payer-Address, X-Payer-Nonce, X-Payer-Signature (or Bearer).
POST /v1/probe for 1 free taste/IP/day.

Not a search-result rendering trick: this is Glyph as a language anyone can speak.
Give it a tool result, a RAG chunk, a document — it comes back as whichever form
(dense photo-glyph image or plain text) is genuinely cheaper for your reader model's
token billing, with the honest manifest attached. The trailing JSON block always
carries a `selection` object {substrate, reader, reader_class, tier, rationale,
estimates} so the choice is auditable from the token math — the same object the
HTTP route returns.

Billed at the flat query rate regardless of which substrate is chosen — text and
glyph cost the same here, unlike retrieve_auto's answer substrate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesYour text to encode — a tool result, a RAG chunk, a document. Max 40,000 chars.
readerNoYour reader model — used to pick the cheapest legible substrate. Flat-tile billers ('gemini', 'qwen') can get a dense glyph; pixel billers ('claude', 'gpt-4o') get text. Unknown/None is treated as pixel-billed — the safe default (text), never an overclaimed saving.
verbatimNoSet true if this text must stay exact (code, hashes, quotes) — it then never picks glyph, which paraphrases. None (default) auto-detects fenced code blocks.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even though annotations already provide readOnlyHint, openWorldHint, and idempotentHint, the description adds substantial beyond-annotation behavioral context: exact cost range ($0.01–$0.05 USDC), auth mechanisms (x402, Bearer, X-Payer-Address/Nonce/Signature), rate limits (1 free taste/IP/day, free 20-query trial), the auditable `selection` manifest contract, billing parity across substrates, and a safe-default behavior for unknown readers. Nothing contradicts 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in sentence one, which is good. However, the description is long and dense: payment fallback flows and credential details consume several sentences, some phrasing is cryptic ('Glyph as a language anyone can speak', 'flat-tile billers'), and the trial/signup details overlap with the 1-free-taste note. Every sentence has some content, but the structure is inflated and could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a payment/auth state machine, the description is unusually thorough: it prescribes exact fallback tool sequences (fillin_probe, fillin_signup, fillin_payment_challenge), exact headers, billing semantics, and the selection manifest. Since an output schema exists, return-value documentation isn't the description's job. Minor gaps remain — 'glyph' is never precisely defined and the 'Requires payment... On payment_required' interplay is slightly ambiguous — but for this complexity level it's near complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema itself is unusually rich (reader billing categories 'flat-tile/pixel billers', verbatim auto-detection of fenced code, max length). The description reinforces the text parameter's purpose and clarifies billing implications ('text and glyph cost the same here'), but adds little beyond the schema's already-detailed parameter explanations — so the high-coverage baseline of 3 applies.

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?

The description names a specific action (encode user-supplied text) and a specific outcome (return whichever substrate — glyph image or plain text — is cheaper for the reader's token billing). It also differentiates from siblings explicitly: 'unlike retrieve_auto's answer substrate' and 'Not a search-result rendering trick' (distinguishing it from glyph_search). An agent can tell what this tool is for without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete usage context ('Give it a tool result, a RAG chunk, a document'), an exclusion ('Not a search-result rendering trick'), a named alternative (retrieve_auto), and explicit conditional flows for the payment_required case (fillin_probe → fillin_signup, or fillin_payment_challenge → retry with X-Payer-* headers). It stops short of a full 5 because it never explicitly says 'use glyph_search for search-result rendering' or states when not to use encode beyond that one exclusion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources