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
gov_checkA

Run the full holdout gate chain on a research artifact and return the verdict (release / review_needed / block) as JSON. Executes every required gate of the artifact kind with the real tools (fail-closed: missing tool, crash or timeout records not_run and blocks) and writes the result back. Use as the final step before publishing any AI-assisted research claim — after gov_init created the project and gov_attach recorded the evidence. Do NOT call it before evidence is attached: missing required gates produce review_needed or block by design. Returns decision, exit_code, missing, gates and policy_ref_ok; treat exit_code 2 (block) as do-not-publish.

gov_reportA

Read-only governance assessment of a research artifact, returned as JSON: current decision state, missing required gates, pass/fail per recorded gate, and policy reference check — WITHOUT running any gate or changing any file. Use to inspect an artifact before attaching evidence or to understand why a previous check did not release. Prefer gov_check for fresh gate execution; gov_report never mutates and never spawns tools.

gov_initA

Scaffold a holdout governance project in a directory (created if missing): writes policy.yml and gate-inputs.json only if absent, and creates a new artifact.json with decision=pending. Never overwrites an existing artifact.json — if present it returns an error and writes nothing. Use once at the start of a research run, then attach evidence with gov_attach and decide with gov_check. Returns the created files and the policy_ref SHA.

gov_attachA

Attach gate evidence, attachments, declarations or a human review to an artifact (decision resets to pending — run gov_check afterwards). Record gate + status + tool + report_ref after a gate tool produced evidence, or review + reviewer after a human reviewed. Attachments/declarations are name=value strings; repeated calls merge, never drop existing entries. Do NOT claim a gate passed when no tool ran — gov_check trusts the journaled status. Returns the updated gates, attachments, declarations and review.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.7/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a distinct lifecycle role: initialize, attach evidence, execute governance checks, and read-only inspection. There is no overlap or ambiguity between the four tools.

Naming Consistency5/5

All tool names follow a clear gov_<verb> pattern with consistent snake_case naming. The prefix clearly groups them under the same domain while the verb indicates the action.

Tool Count5/5

Four tools is a tight, well-scoped set that covers the governance workflow without redundancy. Each tool earns its place and the count feels appropriate for the server's purpose.

Completeness5/5

The tool set covers the full lifecycle: scaffold the project, attach evidence and reviews, view state without side effects, and run the authoritative gate check. No critical operation appears missing for the stated governance workflow.

Maintenance

ActivityMaintained
ResponsivenessNo issues