record-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RECORD_MCP_EXTRA_RULES | No | Path-separated list of directories containing extra YAML rule packs (equivalent to the repeatable --rules-dir option). Rule ids must be unique across the built-in catalog and all packs. | |
| RECORD_MCP_ALLOWED_HOSTS | No | Comma-separated list of allowed hosts. Turns on DNS-rebinding protection for real hostnames (equivalent to the --allowed-host option). |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_traceA | Check one RECORD trace for violations. Runs schema conformance, behavioral rules (human oversight, escalation, temporal, provenance, integrity) and per-regulation field-gap analysis. Returns status (pass / warn / fail), counts by severity, and every violation with its JSON-pointer path, evidence, regulatory citations, and remediation. Use check_trace_chain for several traces. |
| check_trace_chainA | Check a chain of RECORD traces: every per-trace rule plus cross-trace rules. Cross-trace rules include duplicate record_ids, agent version drift within a case, escalations closed without human review, human overrides the agent reasserted, outcome status regressions, and SAR filing deadlines. Returns the chains found, per-trace reports, chain violations, and overall status. |
| list_rulesA | List violation rules in the catalog, optionally filtered. |
| get_ruleA | Full definition of one rule: description, citations, params, remediation. |
| list_frameworksA | Regulatory frameworks known to the catalog, their authority_basis prefixes, and which record-py gap analyses each one triggers. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| audit_trace | Audit RECORD trace(s) and write an examiner-ready violation summary. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| record-schema | The RECORD JSON Schema (draft-07) traces are validated against. |
| rule-catalog | Index of every violation rule. |
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose: check_trace vs. check_trace_chain differ by single- vs. multi-trace scope, list_rules vs. get_rule differ by list vs. detail, and list_frameworks covers a separate catalog entity. There are no overlapping or indistinguishable tools.
All tool names use snake_case with a leading verb (check/list/get) and clear object nouns. check_trace_chain is a predictable extension of check_trace, and there are no mixed naming conventions.
Five tools fit the checker/catalog purpose well: two validation entry points and three catalog lookup tools. Each tool earns its place with no filler or obvious thinness.
The surface covers single-trace checking, chain checking, rule listing/detail, and framework discovery, which are the core operations for a RECORD compliance checker. Remediation and regulatory context are also exposed through the validation and rule tools, leaving no obvious dead ends.