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.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

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

Tools

Functions exposed to the LLM to take actions

NameDescription
verbaly_initA

Create the config file and the locale catalogs, and detect the bundler or meta-framework so the answer names the package to add and the line to wire (what verbaly init does). Writes files, and a file already there is kept rather than overwritten. Run this when doctor says there is no config.

verbaly_doctorA

Diagnose a Verbaly project end to end (what verbaly doctor does): the config file, the catalog files and their JSON, the bundler plugin for the detected framework, the generated types, files the parser could not read, t imported from a package that never exports it, orphan keys, and every failure verbaly check would report. Run this first when something does not work. Read-only.

verbaly_wrapA

Find hardcoded user-visible text in JSX/TSX files and wrap it in a t tagged template so the compiler can extract it (what verbaly wrap does). This is how an existing codebase is onboarded. Reports only unless write is set. Text it cannot wrap safely (a sentence split across markup, an expression rendering JSX) is listed as needing a human and never rewritten. A file that does not bind t is never written either, because the rewrite would not compile: those come back in blocked, with whether the file is a client component, so you can add the binding and run again.

verbaly_extractA

Scan the source files, add new messages to the locale catalogs and refresh the generated types (what verbaly extract does). Writes catalog files unless dryRun is set. prune drops keys no longer referenced in the code, translations included.

verbaly_statusA

Translation coverage of the Verbaly project: total messages, translated count per locale, machine translations awaiting review (drafts) and translations written for an older source text (outdated). Read-only.

verbaly_missingA

List missing translations, unknown keys, keys written with two texts (collisions: every place shows the first text) and translations that exist but cannot render what the source renders (a dropped {param}, a lost rich tag, a flattened plural block), the same gate verbaly check runs in CI. Warnings never fail the gate and are listed too: an incomplete plural set for the locale, keys a translation carries that the source catalog does not (extra), texts the code and the source catalog disagree on (divergent, the text in the code ships) and translations written for an older source text (outdated). Optionally also lists machine translations awaiting review. Read-only.

verbaly_translateA

Fill missing translations with the configured provider (default: Claude, needs @anthropic-ai/sdk and ANTHROPIC_API_KEY). New translations are saved as drafts awaiting human review (verbaly review), which no tool here can approve. A batch the provider never answers is reported in failed and leaves everything else written, so a retry only asks for what is left. dryRun lists what would be translated without calling the provider.

verbaly_write_draftsA

Save translations you wrote yourself, so neither a catalog nor the state file is ever edited by hand. Each one is checked the way verbaly translate checks a provider (params, rich tags and plural cases must survive), written only for keys the source catalog has, and marked as a draft awaiting human review. Existing translations are kept unless overwrite is set, which is how an outdated one gets rewritten. Approving is not a tool here: a human runs verbaly review --approve.

verbaly_draftsA

Every machine translation still waiting for a human, each with the source text and what the provider wrote, so a person can read both and decide. Read-only. Approving is deliberately not a tool here and never will be: a machine translation is unreviewed by definition, so accepting one is verbaly review --approve, run by a human.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
verbaly-configThe resolved Verbaly config: source locale, every locale, the catalog directory and where the language lives in the url. Read this before reasoning about anything else in the project.
en catalogEvery message of one locale, keyed the way the runtime sees them: a nested catalog arrives flattened, a text the code owns reads as the code has it, and an empty value means untranslated. This is the only way to read what a message actually says.

TDQS

A4/5.0

Scored across 9 tools

Disambiguation4/5

Each tool maps to a distinct CLI operation (init, doctor, wrap, extract, status, missing, translate, write_drafts, drafts) with clear boundaries, and the descriptions explicitly orient the agent (doctor first, init when doctor says no config). The one soft spot is drafts: pending-review listings are surfaced in verbaly_status, optionally in verbaly_missing, and again in verbaly_drafts, so an agent may pick the wrong one for that question.

Naming Consistency4/5

Every tool uses the same verbaly_ snake_case prefix with a single short token, which is highly predictable and mirrors the CLI commands. Minor deviation: the tokens mix verbs (init, wrap, extract, translate) with nouns/adjectives (status, missing, doctor, drafts), so the suffix does not consistently signal an action.

Tool Count5/5

Nine tools is well within the ideal 3-15 range and each corresponds to a real stage of the localization workflow with no filler. Nothing appears redundant by count alone.

Completeness4/5

The surface covers onboarding (init, wrap), maintenance (extract, translate, write_drafts), and inspection (doctor, status, missing, drafts), with read/write variants and dryRun/overwrite flags. Gaps are minor: approving drafts and locale management are deliberately excluded (human-only), and pruning exists only as an extract flag rather than a standalone operation.

Maintenance

ActivityActive
ResponsivenessNo issues