Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@compliance-evidence-mcp What SOC 2 controls are missing evidence?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets AI agents query security control evidence for SOC 2 and ISO 27001 audit readiness — with the authorization boundary enforced in the server, not in the prompt.
Agents are increasingly pointed at compliance data: which controls are missing evidence, what's expired, what's still open from the last audit. That data is not uniformly readable. An external auditor, an internal analyst, and an autonomous reporting agent should each see a different slice of it, and the difference has to be enforced somewhere that a model cannot talk its way past.
All data in this repository is synthetic. The control references are real SOC 2 and ISO 27001 identifiers, which are public; every owner, evidence artifact, and audit finding attached to them is invented for demonstration and describes no real organization, system, or vulnerability.
There is no run_sql tool.
Most database-backed MCP servers expose query execution and let the model compose SQL. That moves the authorization decision into the model's judgement, where it can be neither constrained nor audited — and where a prompt injection in a document, a ticket, or a scraped page can reach it.
This server exposes seven intent-shaped tools instead. Because the server knows what each call means, it can compose the caller's authorization predicates into the SQL before execution:
Layer | Enforcement |
Scope | Deny-by-default. A missing grant raises, so a refusal is distinguishable from an empty result. |
Row (classification) |
|
Row (business unit) | Evidence inherits its business unit transitively from the control it supports. |
Column | Free-text notes and finding detail are masked below |
Aggregate | Coverage rollups join under the predicate, so counts never include invisible rows. |
Existence | Out-of-scope and nonexistent IDs both return |
Filtering after the query returns is not equivalent, and aggregates are where that usually goes wrong: a rollup computed over all rows and then trimmed still tells the caller how many rows they weren't allowed to see.
Related MCP server: @actalumen/mcp-server
$ python demo.py
1. list_controls() -- rows visible
agent-coverage-bot clearance=INTERNAL 9 controls units=corp-it,gpu-cloud,platform
analyst-platform clearance=INTERNAL 8 controls units=corp-it,platform
auditor-external clearance=CONFIDENTIAL 5 controls units=platform
security-lead clearance=RESTRICTED 13 controls units=corp-it,gpu-cloud,platform,security
2. list_findings(status='open') -- scope + masking
agent-coverage-bot DENIED (no findings:read grant)
analyst-platform DENIED (no findings:read grant)
auditor-external DENIED (no findings:read grant)
security-lead 5 open findings, 0 with detail masked
3. get_evidence_gaps() -- aggregates respect the boundary
agent-coverage-bot 4 gaps: A.5.23, A1.2, CC6.2, CC6.6
analyst-platform 3 gaps: A1.2, CC6.2, CC6.6
auditor-external 2 gaps: A1.2, CC6.6
security-lead 4 gaps: A.5.23, A1.2, CC6.6, CC7.3Same query, four identities. The interesting row is CC6.2: analyst-platform
reports it as an evidence gap, security-lead does not. The control is covered —
but by evidence classified above the analyst's clearance. The aggregate degrades
to "uncovered" rather than confirming that evidence exists. That is the behaviour
you want; it is also the one that post-filtering silently gets wrong.
Tool | Required scope |
| — |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
whoami() is unscoped by design: an agent should be able to discover what it is
allowed to see, so it can interpret an empty result correctly instead of
concluding that no findings exist.
Principals are resolved in principals.py — deliberately outside the warehouse.
In production resolve() maps the OAuth subject presented by the MCP client to a
principal; it is never read from a table the agent can also query, and never
taken from a tool argument the model could influence. Resolution fails closed:
an unset identity defaults to the least-privileged principal.
For local runs, select an identity with an environment variable:
COMPLIANCE_MCP_PRINCIPAL=security-lead python -m compliance_mcp.serverEvery invocation is appended to access_log with principal, arguments, decision,
and row count. Denials are logged too — in an assurance context, the record
of what an agent was refused is itself evidence, and it is the first thing you
want when reconstructing an incident.
pip install -e .
python demo.py # the walkthrough above
pytest -q # 17 authorization testsWire it into Claude Code:
// .mcp.json
{
"mcpServers": {
"compliance-evidence": {
"command": "python",
"args": ["-m", "compliance_mcp.server"],
"env": { "COMPLIANCE_MCP_PRINCIPAL": "analyst-platform" }
}
}
}tests/test_authorization.py is the substance of this repo. It asserts that a
principal cannot reach data outside its grant by row, by column, by business
unit, or through aggregates — plus that resolution fails closed, that
out-of-scope lookups are indistinguishable from missing ones, and that no
raw-SQL passthrough has been added.
This is a reference implementation, not a product. DuckDB with a seeded fixture stands in for the warehouse so it runs anywhere with no credentials; the repository layer issues plain parameterized SQL, so Snowflake or Databricks is a connector swap. The fixture controls are real SOC 2 TSC and ISO 27001 Annex A references; the findings are invented.
What it is meant to demonstrate is the pattern: agent-accessible data surfaces need an authorization boundary that lives in code, is enforced in the query, and leaves an audit trail.
Built with Python 3.10+ and the official MCP Python SDK (2.x).
Recent tool invocations against this server, including denials.
The access trail is itself sensitive, so it requires the same grant as the findings register.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It usefully discloses that the access trail is sensitive and requires the same grant as the findings register. It does not mention ordering, pagination, or read-only status, though returning a log implies no mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the purpose stated first and the authorization caveat second. Every sentence earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with an output schema, the description provides the core subject and an important sensitivity note. It does not explain when to select it over siblings, but the tool's simplicity and existing output schema reduce the need for more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents only a 'limit' integer with default 20 and no description, while the description says 'Recent' but never explains how limit applies. With 0% schema description coverage and no parameter guidance in the description, the agent must infer the parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: recent tool invocations against this server, including denials. Although it lacks an explicit verb, the tool name 'get' and the content make the operation obvious. It also distinguishes from sibling tools focused on controls, evidence, findings, and identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or when to prefer a sibling; it only defines what it returns and adds a permission caveat. The use case of needing recent tool invocations is implied by the purpose, so guidance is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| control_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it excels: it discloses that null is returned for both nonexistent and out-of-scope controls, and explicitly explains the deliberate indistinguishability for security. This is exactly the kind of non-obvious behavior an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one tightly packed sentence with no filler. It front-loads the core purpose and then adds the crucial null-behavior caveat, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema, the description covers the key contextual points: what it returns, when it returns null, and why null is ambiguous. The security rationale is an important contextual addition that prevents an agent from misinterpreting failed lookups.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies control_id identifies the single control but does not explain the expected format or source of valid IDs. The parameter name and 'one control' wording make it inferable, but the description does not directly elaborate on the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Full detail for one control.' This clearly distinguishes it from list-oriented siblings like list_controls and get_control_coverage by emphasizing singular detail retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you need full detail for a single control, not a collection. It does not explicitly name alternatives or state when not to use it, but the 'one control' framing implies the appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| framework | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does this well by revealing a non-obvious behavior: controls with evidence entirely above the caller's clearance are reported as gaps rather than omitted. It also specifies the as_of date format and default, adding useful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose first, then the important clearance-related behavioral quirk, then the only parameter note. Every sentence earns its place, and there is no wasted wording or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is mostly complete for a simple read-only tool, and the output schema apparently handles return values. However, the framework parameter is unexplained, and there is no guidance on choosing this tool over related siblings like get_evidence_gaps or list_controls. These are meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It explains as_of as an ISO date with a default of today, but it says nothing about the framework parameter, its meaning, format, or filtering behavior. That leaves an important parameter completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's resource ('evidence coverage per control') and the possible result values ('covered' or 'gap'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like get_evidence_gaps, but the per-control framing gives enough clarity to avoid fundamental confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need per-control evidence coverage statuses, and it even clarifies an edge case around caller clearance affecting reported results. It does not explicitly discuss when not to use it or name alternatives, but the intended use case is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Controls with no current unexpired evidence -- the audit-readiness worklist. as_of is an ISO date (default today).
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| framework | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the selection rule (no current unexpired evidence) and the as_of sensitivity, but does not describe read-only behavior, pagination, sorting, or how 'current' is determined. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The core output is front-loaded, and the important as_of parameter note follows immediately. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has no required parameters, and an output schema exists, so the missing return-value detail is acceptable. However, the framework parameter remains undocumented and there is no differentiation from sibling coverage tools, leaving the context incomplete for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to as_of by specifying ISO date format and default, but framework is completely unexplained and receives no semantic description in either the schema or the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's output: controls with no current unexpired evidence, framed as an audit-readiness worklist. It lacks an explicit verb but the tool name supplies the action, and the meaning is distinguishable from siblings like list_controls or list_evidence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'audit-readiness worklist' phrase implies when an agent would use this tool, but there is no explicit guidance about when to prefer it over similar siblings such as get_control_coverage or list_evidence. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List in-scope controls. Filter by framework ('soc2', 'iso27001') or business unit. Only controls within the caller's clearance and business units are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| framework | No | ||
| business_unit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It reveals a non-obvious authorization behavior: only controls within the caller's clearance and business units are returned. The verb 'List' implies read-only, and the filter behavior is stated, though pagination and default behavior when filters are omitted are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the operation and the second covers filtering and access scope. Every sentence earns its place, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-optional-parameter list tool with an output schema, the description provides enough to call it correctly: filter options, scope, and authorization filtering. It does not specify whether filters can be combined or the exact business unit value format, but those are minor gaps given the output schema and optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds explicit framework values ('soc2', 'iso27001') and clarifies that both parameters act as filters. It does not detail the accepted business unit format, but it adds meaning beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List in-scope controls.' It then names the available filters and distinguishes this from siblings like get_control, which targets a single control. The scope qualifier combined with clearance language makes the tool's purpose easy to identify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to list controls filtered by framework ('soc2', 'iso27001') or business unit. It does not explicitly say 'use get_control for a single control' or call out exclusions, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evidence artifacts supporting controls. Evidence inherits its business unit from the control it supports. Free-text notes are masked below CONFIDENTIAL clearance.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| control_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add two useful behaviors: business-unit inheritance from the control and clearance-based masking of free-text notes. However, it omits other operational traits such as default scope, filtering behavior, or whether results are restricted to the current user.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler; each adds either the resource definition or a relevant behavioral detail. It is appropriately compact, though the opening noun fragment could be reshaped into a clearer verb-first statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple optional-parameter list operation and an output schema is present, so return-value documentation is not essential. Still, the unexplained 'kind' parameter and lack of usage guidance leave an agent uncertain how to scope a call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only indirectly explains control_id via 'the control it supports.' The 'kind' parameter is entirely unexplained, including possible values, defaults, and how it filters results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('evidence artifacts supporting controls') and the tool name supplies the list action, so the core purpose is discernible. It does not explicitly contrast with evidence-related siblings like get_evidence_gaps, so it falls short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to call list_evidence instead of list_controls, get_evidence_gaps, or list_findings. The inheritance note hints at a control-based relationship but does not state a selection condition or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| severity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds valuable behavioral context: the required 'findings:read' scope and the masking of finding detail below CONFIDENTIAL. It does not mention pagination, but the presence of an output schema reduces the need for that detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose, scope, filter options, and a masking caveat in three short clauses. Every sentence earns its place without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with two optional parameters and an output schema, the description covers purpose, authentication, filtering, and a confidentiality behavior. Minor gaps are whether status and severity can be combined and what happens when no filters are supplied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does by enumerating allowed values for status ('open', 'closed') and severity ('critical', 'high', 'medium', 'low'). It does not clarify whether filters combine or how to request 'all' findings, but it adds real meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies audit findings as the resource and, combined with the tool name 'list_findings', clearly implies a listing operation. It also distinguishes itself from sibling tools about controls and evidence, though it could be more explicit by starting with 'Lists...'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage context: retrieve audit findings and filter by status or severity, plus a required scope. It does not name alternative tools or exclusion conditions, but the context is sufficient for selecting this tool over obvious siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It clearly states what is returned (identity and effective grants) and adds useful context about how the result affects interpretation of other queries. It does not specify output format or error behavior, but for a zero-parameter introspection tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded: the core purpose appears in the first sentence, and the usage guidance is a compact second paragraph. Every sentence contributes meaning with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description fully covers what the tool does, why to call it first, and how the result should inform subsequent actions. There are no missing pieces that would prevent an agent from selecting or invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-level detail, but none is needed because the input schema is already complete and empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Return') and the exact resource: the server's acting identity and effective grants. This clearly distinguishes it from sibling tools like list_controls or list_findings, which operate on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this first' and explains why: it establishes scope for business units and sensitivity levels and helps interpret empty results. It does not name alternatives or exclusions, but given the tool's bootstrap role, that guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_access_logget_controlget_control_coverageget_evidence_gapslist_controlslist_evidencelist_findingswhoamiScored 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.
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Compliance frameworks (SOC 2, ISO 27001, CMMC, NIST, more) delivered to AI agents as MCP tools.
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
Shared, permission-aware company context for AI agents, with provenance, approvals and audit.
