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
}

Tools

Functions exposed to the LLM to take actions

NameDescription
check_answer_groundingA

Deterministically check a single answer against the context it should be grounded in: required facts (anchors) present, every number traceable to the context, abstention when the question is unanswerable. Same logic as the CI gate — no model, no network. Returns pass/fail with named issues.

check_extractionA

Deterministically check a structured extraction against its hand-labelled gold record: schema validity (nullable fields are the abstention contract), field accuracy with per-field normalisers (dates → ISO, money → minor units) and aliases, and fabrication — a non-null value in a field whose gold is null (a guessed date of birth the document never stated). Same logic as the CI gate — no model, no network. Returns pass/fail with named issues and a per-field verdict.

check_readinessA

Run groundwork check in a repo that has a scaffolded harness: redaction self-test, then the archetype's eval (grounding for document-qa, extraction for extraction) against the repo's own gold set. Returns the exit code, the main scorer's metrics, and any named failures — exactly what CI would report.

scaffold_harnessA

Run groundwork init [archetype] in a repo: writes the adapter boundary, redaction config, gold-set templates, GitHub Action, and playbook for a deployment pattern — document-qa (documents → grounded answers) or extraction (documents → structured fields). Never overwrites existing files. After scaffolding, the human wires groundwork/adapter.mjs and replaces the example gold cases with real ones.

cost_summaryA

Run groundwork cost in a repo: measured token usage from eval runs, with savings recommendations in leverage order (prompt caching, batching, context trimming, model routing last).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a unique role: scaffolding, deterministic per-example checks, full CI-readiness evaluation, and cost reporting. The two check tools are cleanly separated by archetype (answer grounding vs extraction), and check_readiness is a higher-level composite rather than a duplicate.

Naming Consistency4/5

Four tools follow a clear verb_noun snake_case pattern (check_*, scaffold_*), but cost_summary breaks the pattern by being noun_noun. The naming is still readable and predictable overall, with no mixed casing or chaotic style.

Tool Count5/5

Five tools is a well-scoped set for the Groundwork CLI: scaffold, validate readiness, run archetype-specific checks, and analyze cost. Each tool earns its place with no redundancy or bloat.

Completeness5/5

The tool surface covers the full core workflow: scaffold_harness sets up a project, check_readiness runs the CI-equivalent eval, check_answer_grounding and check_extraction handle both supported archetypes, and cost_summary closes the loop on optimization. There are no obvious dead ends or missing lifecycle steps.

Maintenance

ActivitySlowing
ResponsivenessNo issues