compliance-evidence-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| COMPLIANCE_MCP_PRINCIPAL | No | Principal identity for local runs (e.g., security-lead, analyst-platform). If unset, the server fails closed to the least-privileged principal. |
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 |
|---|---|
| whoamiA | Return the identity this server is acting as and its effective grants. Use this first: it tells you which business units and sensitivity levels are in scope, so you can interpret an empty result correctly. |
| list_controlsA | List in-scope controls. Filter by framework ('soc2', 'iso27001') or business unit. Only controls within the caller's clearance and business units are returned. |
| get_controlA | Full detail for one control. Returns null if the control does not exist or is outside the caller's scope -- these are deliberately indistinguishable so the tool cannot be used to probe for restricted control IDs. |
| list_evidenceB | Evidence artifacts supporting controls. Evidence inherits its business unit from the control it supports. Free-text notes are masked below CONFIDENTIAL clearance. |
| get_control_coverageA | Evidence coverage per control, with status 'covered' or 'gap'. A control whose evidence is entirely above the caller's clearance reports as a gap rather than being omitted. as_of is an ISO date (default today). |
| get_evidence_gapsB | Controls with no current unexpired evidence -- the audit-readiness worklist. as_of is an ISO date (default today). |
| list_findingsA | Open or closed audit findings. Requires the 'findings:read' scope; filter by status ('open', 'closed') or severity ('critical', 'high', 'medium', 'low'). Finding detail is masked below CONFIDENTIAL. |
| get_access_logB | Recent tool invocations against this server, including denials. The access trail is itself sensitive, so it requires the same grant as the findings register. |
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 8 tools
Most tools have clearly distinct roles: identity, controls, evidence artifacts, coverage status, gap worklist, findings, and access log. The only mild overlap is between get_control_coverage and get_evidence_gaps, but their descriptions differentiate a status view from a filtered worklist.
The set follows list_noun and get_noun conventions consistently, with whoami as a standard, recognizable exception. There is slight semantic variation where get_ is used for both single entities and aggregate reports, but the pattern remains predictable and readable.
Eight tools is well within the ideal range for a read-only compliance evidence service. Each tool earns its place by covering a distinct part of the audit-readiness workflow without redundancy.
The surface covers the core audit-readiness workflow: identity/scope, controls, evidence, coverage, gaps, findings, and access logs. Minor gaps exist, such as no single-evidence retrieval or finding-detail endpoint, but they are unlikely to cause dead ends for common agent workflows.