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
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
proposeA

Manager types a goal. Returns risk lane + proposed criteria for confirmation. May escalate immediately (too risky / can't define done).

confirmA

Manager confirms the criteria, optionally REPLACING them with the project's real checks, then returns the kickoff prompt.

If edited_criteria is given it becomes the authoritative final list. Each item is {id?, text, oracle_type, oracle} where oracle_type is "command" (a shell command that exits 0 on success), "browser" (a flow the agent proves), or "manual". An item whose id matches a proposed criterion patches it (and re-arms it for checking); any other item is added new. This is how you point a criterion at YOUR stack — e.g. {"text":"build passes","oracle_type":"command", "oracle":"cargo build"}. Returns {error, details} if a criterion is malformed.

get_next_actionA

Agent calls this each turn. Enforces pacing + caps. Returns the goal and what still fails (NOT a prescribed step), or STOP / ESCALATE / DONE.

report_resultB

Agent reports what it did. Runs the verifier. Returns FAIL+failing (with the re-injected standing order) or DONE. proof maps criterion_id -> artifact path for browser/manual criteria.

check_doneA

Explicit verifier call. Same authority as report_result's check — DONE only comes from here. When it goes green on a git project, a merge gate is raised.

request_gateA

Agent asks permission for an irreversible action (deploy/migrate/delete/send). Sets a pending gate the manager approves on the dashboard.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: check_done for verification, confirm for manager to set criteria, get_next_action for step retrieval, propose for goal definition, report_result for result reporting, and request_gate for permission. No overlap.

Naming Consistency4/5

Most tool names follow a verb_noun pattern (check_done, get_next_action, report_result, request_gate), though confirm and propose are single verbs. The naming style is consistent with lowercase and underscores.

Tool Count5/5

With 6 tools, the server covers the core interactions of a looping agent workflow (propose, confirm, get action, report, check done, request gate) without being excessive or insufficient.

Completeness4/5

The tool set covers the essential lifecycle: goal proposal and criteria confirmation, action retrieval, result reporting with verification, done checking, and gate requests. Minor gap: no explicit tool for listing all criteria, but get_next_action provides failing criteria and check_done tests all.

Maintenance

ActivityInactive
ResponsivenessNo issues