Skip to main content
Glama
Sign In
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Sufficiency

get_sufficiency

Whether the submitted assertions of one control, or of one functional test, together prove it. Read-only; name exactly one id.

Instructions

Whether the submitted assertions of one control, or of one functional test, together prove it. Read-only; name exactly one id.

For a control this explains verification_status: "partially_verified". status is sufficient | insufficient | pending, with freshness (fresh | stale | pending) beside it; insufficient carries details naming EACH uncovered clause and the evidence that would close it. A soundness_tier is the weakest clause's tier: a control is proven no more strongly than its thinnest clause. It is composed over the evidence as it stands now (strength_basis: now), beside soundness_tier_at_evaluation, and clause_strength lists each clause's tier now and when judged, with each piece of evidence marked passes_now: relay a clause whose evidence no longer passes. Reading does not queue a re-evaluation. For the whole model use get_verification_report.

commitments is what it was checked against: a person's declaration (basis: "declaration"; an open cross-check finding keeps it insufficient: get_control_delta) or a reading of the text.

Act by submitting the named assertions; a clause describing a mechanism the system does not use calls for refine_control, not evidence. get_control_work_order serves the per-clause list: where the order names a required class for a clause, required_evidence carries the clause id for covers and a suggested_submission skeleton whose <...> placeholders you replace. For a for-all clause prefer typed_boundary, else sink_default_deny. class_mismatch means the bound evidence is the wrong CLASS and more of it will not help. An attestation covers an existential clause, never a for-all one; that clause's only other exits are a risk acceptance or a not-applicable disposition.

For a functional test it is whether its evidence proves the objectives it is associated with, with the reasoning; it can read pending or absent until evidence is submitted.

Input Schema

NameRequiredDescriptionDefault
model_idYes
control_idNo
server_versionYes
functional_test_idNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.84.0
    • addedInput schema / properties / control_id / default
      Added value: +""
    • removedInput schema / properties / control_id / description
      Removed value: -"ID of the control (e.g., \"CTRL-01\")."
    • addedInput schema / properties / functional_test_id
      Added value: +{
+  "default": "",
+  "type": "string"
+}
    • removedInput schema / properties / model_id / description
      Removed value: -"ID of the threat model."
    • changedInput schema / required
      Previous value: -[
-  "server_version",
-  "model_id",
-  "control_id"
-]New value: +[
+  "server_version",
+  "model_id"
+]
  2. Addedv0.62.2
  3. Removedv0.62.0
  4. First observedv0.57.0

TDQS

A4/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 burden, and it discloses real behavioral traits: read-only, 'reading does not queue a re-evaluation', staleness semantics, and the rule that a control is only as strong as its thinnest clause. Some of the text describes output fields that the output schema already exposes, but the 'does not queue a re-evaluation' note and the insufficiency/evidence-closure semantics go beyond the schema.

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?

The purpose and routing are front-loaded, which is good, but the body is dense and spends a large share of its length narrating output fields (status, freshness, soundness_tier, clause_strength, passes_now) that the output schema already carries. The reStructuredText double-backtick littering also hurts readability.

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?

An output schema exists, so return values need not be explained, and the description supplies the interpretation an agent needs to act on them. With no annotations it correctly discloses the read-only and non-re-queuing behavior, and it explains how to move a control from insufficient to sufficient. The only material gap is the undocumented model_id/server_version parameters.

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 does add the critical constraint 'name exactly one id', implying mutual exclusivity between control_id and functional_test_id, which the schema does not convey. However, it says nothing about server_version or model_id, leaving two required parameters unexplained.

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 opening states a specific verb+resource ('whether the submitted assertions of one control, or of one functional test, together prove it') and marks it read-only. It explicitly contrasts itself with get_verification_report for the whole model, so an agent can differentiate it from the sibling. It is slightly diluted by the density of the surrounding return-field prose, but the core purpose lands clearly.

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?

It routes the agent broadly: use get_verification_report for the whole model, act by submitting assertions, use refine_control when a clause describes an unused mechanism, consult get_control_work_order for per-clause lists, prefer typed_boundary for for-all clauses. It also states the when-not case (a mechanism the system does not use is not evidence) and names relevant siblings.

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