Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Get Compliance Report

get_compliance_report

Generate a read-only compliance gap-analysis report for a framework at model or tag scope, classifying each requirement as covered, partial, uncovered, unmapped, or excluded.

Instructions

Compliance gap-analysis report for one framework at a chosen scope. Read-only; no side effects. Requires PRO tier.

Evaluates every framework requirement against the mapped controls in scope and classifies each as covered, partial, uncovered, unmapped, or excluded, then returns coverage counts plus per-requirement rows. The framework must first be activated at the same scope via select_compliance_frameworks (with the matching scope), otherwise there is nothing to report on.

scope selects the boundary and how scope_id is read:

"model" — a single threat model (scope_id = model id).
"tag" — rolled up across every member model of a tag (scope_id = tag id).

Filtering / pagination:

level — level filter for level-aware frameworks; returns only requirements at or below this level (e.g. 1 for L1 only). Omit (or 0) for all levels. Honored for all scopes.
status — one of "covered", "partial", "uncovered", "unmapped", "excluded"; empty = all statuses. Model scope only.
offset / limit — per-requirement row pagination; offset skips the first N rows, limit caps rows returned (0 = no explicit limit). Model scope only.

A tag report is neither paginated nor status-filtered; passing status, offset, or limit with scope="tag" raises an error rather than silently returning unfiltered rows.

Input Schema

TableJSON Schema

Name	Required	Description
`level`	No	optional level filter; omit for all levels.
`limit`	No	max requirement rows to return, 0 = no explicit limit (model scope only).
`scope`	Yes	report boundary — "model" or "tag".
`offset`	No	skip the first N requirement rows, pagination (model scope only). Default 0.
`status`	No	optional per-requirement status filter (model scope only).
`scope_id`	Yes	id of the model or tag selected by ``scope``.
`framework_id`	Yes	framework to report on (already selected at this scope; see ``list_compliance_frameworks``).
`server_version`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.85.0Oct 7, 2026

changedInput schema / properties / limit / description

Previous value: -"max requirement rows to return, 0 = no explicit limit (model/system scopes only)."New value: +"max requirement rows to return, 0 = no explicit limit (model scope only)."

changedInput schema / properties / offset / description

Previous value: -"skip the first N requirement rows, pagination (model/system scopes only). Default 0."New value: +"skip the first N requirement rows, pagination (model scope only). Default 0."

changedInput schema / properties / scope / description

Previous value: -"report boundary — \"model\", \"system\", or \"tag\"."New value: +"report boundary — \"model\" or \"tag\"."

changedInput schema / properties / scope / enum

Previous value: -[
-  "model",
-  "system",
-  "tag"
-]New value: +[
+  "model",
+  "tag"
+]

changedInput schema / properties / scope_id / description

Previous value: -"id of the model, system, or tag selected by ``scope``."New value: +"id of the model or tag selected by ``scope``."

changedInput schema / properties / status / description

Previous value: -"optional per-requirement status filter (model/system scopes only)."New value: +"optional per-requirement status filter (model scope only)."

Changed9 schema fields changedv0.68.2Aug 22, 2026

changedInput schema / properties / framework_id / description

Previous value: -"ID of the compliance framework (as listed by list_compliance_frameworks)."New value: +"framework to report on (already selected at this scope; see ``list_compliance_frameworks``)."

changedInput schema / properties / level / description

Previous value: -"Optional level filter for level-aware frameworks — returns only requirements at or below this level (e.g. 1 for L1 only). Omit for all levels."New value: +"optional level filter; omit for all levels."

changedInput schema / properties / limit / description

Previous value: -"Maximum requirement rows to return. Default 0 = no explicit limit."New value: +"max requirement rows to return, 0 = no explicit limit (model/system scopes only)."

removedInput schema / properties / model_id

Removed value: -{
-  "description": "ID of the threat model.",
-  "type": "string"
-}

changedInput schema / properties / offset / description

Previous value: -"Number of requirement rows to skip, for pagination. Default 0."New value: +"skip the first N requirement rows, pagination (model/system scopes only). Default 0."

addedInput schema / properties / scope

Added value: +{
+  "description": "report boundary — \"model\", \"system\", or \"tag\".",
+  "enum": [
+    "model",
+    "system",
+    "tag"
+  ],
+  "type": "string"
+}

addedInput schema / properties / scope_id

Added value: +{
+  "description": "id of the model, system, or tag selected by ``scope``.",
+  "type": "string"
+}

changedInput schema / properties / status / description

Previous value: -"Optional status filter: \"covered\", \"partial\", \"uncovered\", \"unmapped\", or \"excluded\". Empty = all statuses."New value: +"optional per-requirement status filter (model/system scopes only)."

changedInput schema / required

Previous value: -[
-  "server_version",
-  "model_id",
-  "framework_id"
-]New value: +[
+  "server_version",
+  "scope",
+  "scope_id",
+  "framework_id"
+]

Changed5 schema fields changedv0.66.0Aug 5, 2026

changedInput schema / properties / framework_id / description

Previous value: -"ID of the compliance framework."New value: +"ID of the compliance framework (as listed by list_compliance_frameworks)."

changedInput schema / properties / level / description

Previous value: -"Optional level filter (e.g., 1 for L1 only)."New value: +"Optional level filter for level-aware frameworks — returns only requirements at or below this level (e.g. 1 for L1 only). Omit for all levels."

changedInput schema / properties / limit / description

Previous value: -"Max to return."New value: +"Maximum requirement rows to return. Default 0 = no explicit limit."

changedInput schema / properties / offset / description

Previous value: -"Skip first N."New value: +"Number of requirement rows to skip, for pagination. Default 0."

changedInput schema / properties / status / description

Previous value: -"Filter: \"covered\", \"partial\", \"uncovered\", \"unmapped\", \"excluded\"."New value: +"Optional status filter: \"covered\", \"partial\", \"uncovered\", \"unmapped\", or \"excluded\". Empty = all statuses."

Addedv0.62.2Jul 22, 2026
Removedv0.62.1Jul 17, 2026
First observedv0.57.0Jul 8, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the full burden and does so: read-only, no side effects, PRO tier requirement, the semantics of how scope_id is interpreted per scope, and a documented error path for invalid scope/filter combinations. This is well beyond what structured fields provide.

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?

Front-loaded with the core purpose and safety profile, then cleanly sectioned into scope and filtering/pagination blocks. Slightly long, but nearly every line carries operational detail that affects a correct call.

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?

An output schema exists so return values need no explanation, yet the description still clarifies the shape (coverage counts plus per-requirement rows). All required params, scope behavior, and error conditions are covered for a complex 8-param, 4-required tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already high (88%), but the description adds real meaning: how scope_id is read under each scope value, that level returns requirements at or below the given level, the exact status enum values, and that offset/limit/status are model-scope only.

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?

States a specific verb+resource+scope: a read-only compliance gap-analysis report for one framework at a chosen scope, and enumerates the classification outcomes (covered/partial/uncovered/unmapped/excluded). This clearly differentiates it from siblings like check_control_gaps and get_verification_report.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the prerequisite that the framework must first be activated at the same scope via select_compliance_frameworks, names the follow-up tool (list_compliance_frameworks) for framework ids, and specifies the exact error behavior when status/offset/limit are passed with scope="tag".

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Get Compliance Report

Instructions

Input Schema

Output Schema

Schema Changelog

TDQS

Other Tools