Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Verification Report

get_verification_report

Retrieve verification report with tier1/tier2 pass/fail/pending counts, per-control status, and sufficiency gaps to spot controls lacking evidence or needing review.

Instructions

Get verification report with summary stats and sufficiency gaps.

Returns tier1/tier2 pass/fail/pending counts, per-control verification status, and sufficiency details.

Each per-control sufficiency block carries:

  • status: "sufficient" | "insufficient" | "pending" | "stale". "stale" means the stored verdict no longer reflects the current control description, active assertion set or the rules it was computed under. Reading does not queue a re-evaluation: the write that changed a control queues its own. Call this tool again later for the refreshed verdict.

  • details: human-readable LLM reasoning.

  • misaligned_assertion_ids: assertions whose stated subject is off-topic for the control's current description (common after a control has been refined or regenerated). Treat as a directive: rebind to the right control, supersede via delete_assertion, or rewrite. Do NOT treat them as evidence. A non-empty list forces the verdict to "insufficient".

  • stale: boolean shortcut for status == "stale", kept distinct so an INSUFFICIENT verdict that's also stale (the prior insufficient decision was computed under outdated inputs) can be flagged without overloading status.

A drift item means the accepted evidence changed (a test's definition, a witness's scope or allowlist) and its verdict was withdrawn until reviewed again.

By default returns summary only (no per-assertion details). Set summary_only=False to include full assertion details and drift items.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax control entries to return (0=all).
offsetNoSkip first N control entries.
statusNoFilter by verification status: "verified", "partially_verified", "pending", "unverified".
model_idYesID of the threat model.
summary_onlyNoOmit per-assertion details and drift items (default True).
server_versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.62.2
  2. Removedv0.62.0
  3. First observedv0.57.0

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations the description carries the full load, and it delivers meaningful semantics: what 'stale' means, that reading does not queue a re-evaluation, that misaligned_assertion_ids is a directive (not evidence) and forces 'insufficient', and what a drift item implies. It still omits permission/auth requirements and rate-limit behavior, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence, but the bulk of the text is spent describing return structure (sufficiency blocks, stale flag, drift items) even though an output schema exists and already governs those fields. The status/drift semantics partly justify the length, but the block is longer than it needs to be.

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 read tool with an output schema, the description supplies the non-schema semantics an agent needs (stale semantics, re-evaluation timing, misaligned-assertion handling, default truncation). Only the sibling-selection guidance and any access prerequisites are missing.

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 coverage is 83%, so the baseline is 3. The description restates summary_only's effect in slightly richer terms (assertion details plus drift items) but adds nothing about limit/offset/status semantics beyond the schema's own text.

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?

States a specific verb and resource ('Get verification report') and enumerates the payload: tier1/tier2 pass/fail/pending counts, per-control verification status, and sufficiency details. That is enough to distinguish it from read-only siblings, though it never names an alternative like get_sufficiency or get_reachability_verdicts to sharpen the boundary.

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 default-vs-full behavior is spelled out ('By default returns summary only... Set summary_only=False to include full assertion details and drift items'), which is real invocation guidance. But there is no when-to-use-this-vs-get_sufficiency reasoning and no exclusions, so usage is only implicit.

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

Deploy Server

Other Tools