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": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
deed_checkA

Check a Deed program and report what the compiler found. Writes one JSON object a line. A diagnostic line is something wrong with the program. An obligation line is a contract clause the checker looked at: tier is proven when it was settled at compile time, tested when a test pins it, and guarded when it falls to a runtime check, in which case reason says what stopped it from being proven. Silence means the program is well formed.

deed_testA

Run a Deed program's tests: every test block in it, and every property its contracts generate. Writes one JSON object a line with the name and whether it passed, and the failing diagnostic when it did not, then a summary line counting them, so a program with no tests in it says so rather than answering with nothing. A property line is one nobody wrote: the checker generated inputs from a where clause and held the function to its ensures, and the seed is on the line so the same run can be asked for again. Refuses without running when the program does not check: ask deed_check for what is wrong with it.

deed_runA

Run a Deed program's main and report what it printed. Refuses before running if the program does not check, or if main's row asks for a capability this server does not hand out: there is no filesystem here, so a program that reads or writes files is refused rather than failed.

deed_fmtA

Format a Deed program into the one layout the formatter chooses. Returns the formatted text, or the parse diagnostics when the file does not parse, because a file with no tree has no layout to pick.

deed_fixA

Apply every machine-applicable repair the compiler offers and return the repaired program. Only the repairs deed fix would apply without asking; a suggestion the compiler is not sure about is left for the reader and shows up in deed_check instead.

deed_explainA

Explain one diagnostic code, such as DEED4025. Returns the page that code carries: what it means, why the rule exists, and usually an example.

deed_reviewA

Compare the checked module set before a patch with the set after it. Returns one JSON review receipt naming authority additions, obligation tier regressions and newly introduced Guarded obligations. An optional policy object accepts denyNewAuthority, denyWeakerPromises and denyNewGuarded; its verdict is evidence, not a transport error. Both sides stay in memory: this tool opens no file and holds no capability.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 7 tools

Disambiguation5/5

Each tool targets a distinct operation in the Deed toolchain: static checking, test execution, running main, formatting, auto-fixing, diagnostic explanation, and patch review. There is no overlap in their inputs or outputs, so an agent can reliably select the right tool for a given task.

Naming Consistency4/5

All tools share the `deed_` prefix and a simple verb-based naming scheme (check, test, run, fmt, fix, explain, review). The only minor inconsistency is the abbreviation 'fmt' instead of 'format', but the pattern is otherwise uniform and predictable.

Tool Count5/5

Seven tools is well within the ideal range for a domain-specific language server. Each tool covers a core workflow step (check, test, run, format, fix, explain, review) and none are superfluous or redundant.

Completeness5/5

The set provides a complete lifecycle for interacting with Deed programs: static checking, testing, execution, formatting, automated repair, diagnostic explanation, and change review. No obvious essential operation is missing; the only conceivable additions (e.g., a build tool) fall outside the apparent scope of this server.

Maintenance

ActivitySlowing
ResponsivenessResponsive