A
licenseB
qualityC
maintenanceEnables read-only analysis of local disk usage to identify cleanup targets by size, type, recency, and duplicates.
6
16
1
MIT
assurance-mcp
by i-ops-hq
This server provides four read-only MCP tools for auditing coverage and freshness of files or retrieved sets without ever writing to disk.
check_set_coverage_tool: Compare any two sets of keys (e.g. expected vs. found documents/chunks/files) to see if the run covered everything; reports
complete,read of required, missing items, and unexpected items. No filesystem access needed.check_coverage_tool: Check whether every month/period in a folder span is present; can accept a period range or derive from dated filenames and returns the derivation with the ratio.
check_staleness_tool: Check whether a document's figures still match a named source file; returns
uncheckablewhen required recorded facts are missing.list_dated_files_tool: List which reporting periods a folder holds based on dated filenames, helping an agent decide what to ask next.
All tools are read-only by construction — no writes, deletes, network calls, or path escapes via ../symlinks.
Click on "Install 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., "@assurance-mcpCheck coverage on ~/Downloads/monthly-reports"
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.
assurance-mcp
For an agent that retrieves before it answers
If your agent can list the folder it is reasoning about, you probably do not need this. We A/B'd exactly that inside Cursor and the run without these tools did better: it listed the directory, spotted the odd filename, and checked itself. That is the right behaviour and we are not going to pretend otherwise.
Where it earns its place is where the agent cannot see the whole set. It performed a retrieval and
holds k results, and nothing in those results says what the other set contained. It cannot list what
it was not given, and neither can a better model.
check_retrieval_coverage_tool answers that, in arithmetic, with no model involved.
Read-only by construction. No writes, no deletes, no network. Proven by
test_the_server_never_writes: no tool opens a file for writing, and no requests, urllib,
shutil, os.remove, os.replace or symlink_to call exists in the package.
Related MCP server: flameox
Install
python3 -m venv .venv && source .venv/bin/activate
pip install assurance-mcp{
"mcpServers": {
"assurance": {
"command": "/absolute/path/to/.venv/bin/python",
"args": ["-m", "assurance_mcp.server"]
}
}
}Cursor (~/.cursor/mcp.json), Claude Desktop, or any MCP client. Restart it, and you get four tools.
The one that fits your problem
check_set_coverage_tool takes two lists the agent already holds. No folder, no filesystem.
You: Before you answer, check what you retrieved against what the question spans.
Agent: check_set_coverage_tool(
expected = ["msa.md", "amendment-1.md", "amendment-2.md", "amendment-3.md"],
found = ["msa.md", "amendment-1.md", "globex/msa.md"],
scope = "documents this question spans",
where = "the retrieved set")
→ complete: false · read 2 of 4
"2 of 4 documents this question spans — not in the retrieved set:
amendment-2.md, amendment-3.md"
unexpected: ["globex/msa.md"]
Agent: I've read 2 of the 4 documents this question spans. Amendment 2 and 3 weren't retrieved and
the terms may have changed in them, so I shouldn't answer yet. I also pulled in a Globex
document, which I've discarded.That's a sentence no agent produces on its own, and it's the one that stops a wrong answer.
Use it for: retrieved chunks vs. documents the question spans · files reviewed vs.
git diff --name-only · controls with evidence vs. controls in scope · partitions loaded vs.
declared · eval cases run vs. declared.
All four tools
answers | needs a folder | |
| did the run cover everything, over any two sets? | no |
| which periods are in this folder, and which aren't? | yes |
| do a document's figures still match a source you name? | yes |
| which periods does this folder hold? | yes |
check_coverage_tool handles monthly, quarterly, weekly, daily and numbered runs (INV-0001,
run_042), and returns the derivation with the ratio so the agent can surface a denominator you
can argue with. Works from a cold start: no state, no database, no key.
Honest limits
expectedis never inferred. A denominator the tool invents is one nobody can argue withCSV and TSV only for profiling — no XLSX dependency here
Staleness needs recorded facts, or the answer is
uncheckable— never silenceNo cross-document inference. It produced 21 false positives on a real corpus, so it's refused
The caller names the folder boundary; paths can't escape it via
..or a symlink
Family
assurance-core — the pure arithmetic, zero dependencies · assurance-cli — the same checks as a command
Upstream is I-Ops; this repo is a publication, never a source. Apache-2.0.
Available Tools
4 toolscheck_coverage_toolA
Check whether every month in a folder span is present.
Read-only. Names a folder and optionally a period range such as 'January 2024 to December 2025' or 'last 12 months'.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| folder | Yes | ||
| period_range | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description explicitly labels the operation as read-only, which is an important safety disclosure. It does not detail how 'present' is determined or what the exact output is, but the presence of an output schema reduces that burden.
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: the core purpose appears first, followed by the read-only note and parameter usage. Every sentence adds value, and the example period ranges are useful without adding clutter.
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 read-only check with one required and one optional parameter, the description gives enough information for basic invocation: purpose, inputs, and safety behavior. It lacks explicit guidance on choosing between sibling tools and a precise definition of 'folder span', but the output schema presumably covers return details.
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?
Since the schema provides 0% description coverage, the description compensates by naming both parameters: folder is the folder to inspect, and period_range is an optional range with useful examples like 'January 2024 to December 2025' and 'last 12 months'. It could add folder path format or the meaning of a null period_range, but the essential semantics are covered.
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 states a clear action: verify that every month in a folder's span is present, optionally restricted to a period range. This distinguishes it from list_dated_files_tool and check_set_coverage_tool by focusing on month-level coverage, though it does not explicitly name or contrast those siblings.
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 implies when to use the tool through its purpose and gives usage context for the optional period_range with concrete examples. However, it does not explicitly say when to prefer this tool over check_staleness_tool or check_set_coverage_tool, nor does it mention any exclusions or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_set_coverage_toolA
Check what a task required against what was actually read, over any two sets of keys.
Read-only, and touches no filesystem — the caller holds both lists. Use this when the thing you must account for is not dated files in a folder: documents the question spans against the chunks a retriever returned, files changed in a pull request against files reviewed, table partitions against partitions loaded, required controls against controls with evidence, declared eval cases against cases actually run.
expected is the caller's declaration and is never inferred here. scope names the items for
the sentence ("documents the question spans"); where names where they were looked for ("the
retrieved set"); derivation records how the expected set was arrived at, so a reader can
disagree with the denominator rather than only with the result.
Returns the coverage record: complete, read of required, and each way an expectation
failed to be evidence kept separate. Anything present that was not expected is reported under
unexpected and deliberately earns no credit against the denominator.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| found | Yes | ||
| scope | No | ||
| where | No | ||
| expected | Yes | ||
| derivation | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.7/5.0
Behavior5/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 does so well: it states 'Read-only, and touches no filesystem,' explains that `expected` is never inferred, and discloses the behavior for unexpected items ('deliberately earns no credit against the denominator'). This gives an agent a trustworthy model of side effects and result semantics.
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 front-loads the core purpose and usage, then uses later paragraphs for parameter semantics and output behavior. Each section earns its place; the examples are compact and collectively clarify the tool's scope without unnecessary fluff.
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 read-only, pure computational tool with an output schema and no side effects, the description is complete: it covers safety, parameter meanings, returned fields, and the special treatment of unexpected items. No critical information an agent would need to call it correctly is missing.
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 for most parameters: `expected` is defined as the caller's declaration, `scope` names items for the sentence, `where` names where they were looked for, and `derivation` records how the expected set was arrived at. `found` is only implied as 'what was actually read' rather than explicitly named as the second required list, leaving a small gap.
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 precise verb-resource pairing: 'Check what a task required against what was actually read, over any two sets of keys.' It also distinguishes itself from dated-file-oriented siblings by saying 'when the thing you must account for is not dated files in a folder' and provides concrete example pairings, so an agent can tell this apart from related tools.
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 explicit usage context: 'Use this when the thing you must account for is not dated files in a folder,' followed by several illustrative scenarios such as documents vs. retrieved chunks and required controls vs. controls with evidence. It does not name alternatives or state explicit when-not-to-use cases, but the guidance is clear enough to route an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_staleness_toolA
Check whether a document's figures still match a source file the caller names.
Read-only. Does not search for a plausible match — both paths are required. Returns UNCHECKABLE when recorded facts are missing and cannot be read.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| folder | Yes | ||
| source | Yes | ||
| document | Yes | ||
| recorded_facts | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
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. It explicitly states that the tool is read-only and discloses the UNCHECKABLE return condition for missing recorded facts. It also clarifies that it does not perform fuzzy searching. This provides meaningful behavioral context, though it does not detail all possible outputs or error conditions, which are partly covered by the output schema.
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 exceptionally concise—three sentences. It front-loads the core purpose in the first sentence, then adds essential constraints and return behavior. No wasted words; every sentence contributes meaningful information.
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?
Given the tool has an output schema (though not shown) and no annotations, the description covers the essential aspects: purpose, read-only nature, required paths, and a special return condition. It does not explicitly discuss error handling for missing files or permissions, but the read-only designation and simple scope make this acceptable. It is largely complete for a staleness-check tool.
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?
The schema has 0% description coverage, so the tool description must compensate. It does add value by explaining that both paths (document and source) are required and that recorded_facts affect the UNCHECKABLE return. However, it does not elaborate on the role of each parameter beyond their names (e.g., what a 'source file' is versus 'document'), leaving some semantics to be inferred.
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 action (check) and a clear subject (whether a document's figures still match a source file). It also distinguishes itself by noting that it does not search for a plausible match, which helps differentiate it from sibling tools like check_coverage_tool. The purpose is unambiguous.
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 implies when to use the tool (when you need to verify staleness against a named source) and provides a key constraint (both paths are required). However, it does not explicitly mention alternative tools or when not to use it, leaving some ambiguity against siblings. The guidance is implicit rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_dated_files_toolA
List which reporting periods a folder holds from dated filenames.
Read-only. Helps an agent decide what to ask next.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| folder | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description does state 'Read-only,' which is a key behavioral trait. However, it does not describe edge-case behavior such as what happens when a folder contains no dated filenames, or whether the listing follows any particular ordering or hidden-file handling beyond the output schema.
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?
The description is short and front-loaded: the primary function is stated in the first sentence. The second sentence, 'Helps an agent decide what to ask next,' adds light context but is somewhat filler-like. Overall, it is concise with no repetition of schema fields.
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 one parameter, and an output schema exists, so return value details are not required. The description gives enough information to understand the basic call: a folder is required and the result will list reporting periods. However, it does not explain how to choose this over sibling tools, which leaves a notable completeness gap for an agent navigating multiple related tools.
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 add meaning beyond the schema. The description confirms that the 'folder' parameter is the source of dated filenames and that reporting periods are derived from them. However, it does not provide details about expected path format or accepted folder specifiers, though the single parameter is relatively self-explanatory.
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: 'List which reporting periods a folder holds from dated filenames.' This clearly identifies the tool's function and differentiates it from sibling tools like check_coverage_tool and check_staleness_tool, which are about validation rather than inventory.
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 phrase 'Helps an agent decide what to ask next' implies use as an exploratory step, but the description does not explicitly say when to use this tool versus the sibling check tools. No exclusions or alternative conditions are provided, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4.1/5.0
Disambiguation4/5
The four tools mostly partition cleanly: staleness checking, dated-file listing, folder-month coverage, and arbitrary set coverage are distinct jobs. The two coverage tools have similar names and check_coverage_tool/list_dated_files_tool both read dated filenames, but the descriptions clarify when each is appropriate.
Naming Consistency5/5
All tool names follow the same verb_noun_tool convention with lowercase snake_case and a consistent trailing _tool suffix. There is no mixing of camelCase, vauge verbs, or haphazard pattens.
Tool Count5/5
Four tools is well within the well-scoped range and each tool earns its place as a distinct read-only assurance operation. The set feels compact without being thin.
Completeness4/5
The server covers the main assurance workflows: listing available dated periods, checking month-level folder coverage, checking arbitrary set coverage, and checking staleness against a named source. A minor gap is that there is no discovery tool for finding plausible source files for staleness checks, but the descriptions make clear that the caller is expected to supply both paths.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Read-only finance and operations controls for AI agents with evidence and safe next actions.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Read-only MVR preflight for trust, permission, evidence gaps, and African market-entry readiness.
Run verified read-only code tools: quant diagnostics + agent-ops preflight, no source exposure.
Related MCP Servers
- AlicenseCqualityAmaintenanceEnables coding agents to query, compare, and audit local profiler traces, benchmarks, memory captures, and execution evidence without uploading code or data, using CLI and MCP interfaces.11164MIT
- FlicenseNot gradedqualityCmaintenanceProvides read-only access to local SharePoint/OneDrive synced files, enabling listing, searching, and querying Excel workbooks with filters and aggregations, all within a strict sandbox.
- FlicenseNot gradedqualityCmaintenanceEnables local folder analysis of unstructured documents (PDF, DOCX, PPTX, TXT, SVG, PNG, CSV, XLSX) by extracting structure, reading content, and generating reports, with a strict approval gate before any save operation.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/i-ops-hq/assurance-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server