compliance-evidence-mcp

by prayagpadwal

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.9/5 across 8 of 8 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![compliance-evidence-mcp MCP server](https://glama.ai/mcp/servers/prayagpadwal/compliance-evidence-mcp/badges/card.svg)](https://glama.ai/mcp/servers/prayagpadwal/compliance-evidence-mcp)

Score Badge

Copy to your README.md:

[![compliance-evidence-mcp MCP server](https://glama.ai/mcp/servers/prayagpadwal/compliance-evidence-mcp/badges/score.svg)](https://glama.ai/mcp/servers/prayagpadwal/compliance-evidence-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/prayagpadwal/compliance-evidence-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server