Metatron
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| METATRON_DB | No | Path to the SQLite database file. Overrides metatron.toml. Default is 'metatron.db' in the current working directory. | |
| METATRON_REPO | No | Repo identity to serve. If not set, will be inferred from context (--repo argument, METATRON_REPO env var, persisted default, current directory, or only repo in store). | |
| METATRON_MODEL | No | Model to use for extraction steps (not used by serve). Default from metatron.toml or 'claude-sonnet-4-6'. |
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_decisions_for_contextA | Fetch the team's canonical engineering decisions for a file/area and task. |
| submit_feedbackA | Report how helpful the served decisions were, and what was missing. |
| submit_candidate_decisionA | Record a new engineering convention you discovered while working — for human review. |
| get_verificationA | Fetch the team's verification contracts for a scope: how a change here is proven, and — in each contract's "failure_means" — what a red check implies about which subsystem is at fault. |
| get_verification_templateA | Return the canonical verification-contract skeleton, so you can draft a new contract in the exact format the layer expects. Drafts are review-gated and never self-canonical — a human approving the file is the curation act. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool targets a distinct artifact and action: reading decisions vs verification contracts, submitting a new decision candidate vs feedback, and fetching a template. The descriptions clearly delineate read-only retrieval from submission, and there is no functional overlap.
All names use snake_case with a verb-first structure (get_, submit_), which is consistent and predictable. Minor deviation: get_decisions_for_context includes a preposition, and some names are multi-word noun phrases, but no mixing of conventions.
Five tools is well within the ideal 3–15 range and each tool serves a distinct, necessary function in the decision/verification workflow. No tool feels redundant or extraneous.
The surface covers reading decisions, submitting decision candidates, giving feedback, reading verification contracts, and getting a template. However, there is no way to submit a new verification contract candidate or give feedback on verification contracts, leaving a gap on the verification side of the domain.