Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Sufficiency

get_sufficiency

Determine whether submitted assertions for a control or functional test prove it, returning status, freshness, uncovered clauses, and evidence needed to close gaps.

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. Reading does not queue a re-evaluation: the write that changed a control queues its own. For the whole model use get_verification_report.

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 the test's evidence proves the objectives it is associated with, with the reasoning; computed after evidence is submitted, so it can read pending or absent until then.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYes
control_idNo
server_versionYes
functional_test_idNo

Output Schema

TableJSON 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.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden and delivers key traits: read-only, no re-evaluation is queued by reading ('the write that changed a control queues its own'), and functional-test results are computed only after evidence is submitted, so they may read pending/absent. It does not cover auth/rate/permission context, but for a read-only query tool this is strong.

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 is front-loaded and clear, but the body is dense and mixes in remediation guidance (typed_boundary vs sink_default_deny, class_mismatch, attestation exits) that belongs to the action tools rather than to a read-only sufficiency lookup. Several sentences do not earn their place for selecting or invoking this tool.

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 domain-complex tool with an output schema (so return-value detail is not required here), the description supplies the status/freshness/soundness_tier semantics and the pending-on-functional-test caveat an agent needs. The remaining gap is the unexplained model_id/server_version inputs and the ambiguity of whether 'one id' is enforced by the caller.

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 0%, so the description must compensate and it partially does: it explains that control_id and functional_test_id are mutually exclusive and that exactly one must be named, plus what each answers. However, model_id and server_version (both required) receive no semantic explanation anywhere, leaving half the parameters opaque.

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 question the tool answers ('whether the submitted assertions of one control, or of one functional test, together prove it') plus its operation mode ('Read-only; name exactly one id'). It explicitly names the sibling that covers the other scope ('For the whole model use get_verification_report'), so an agent can distinguish it without opening a schema.

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?

Names alternatives with the selecting condition: get_verification_report for the whole model, get_control_work_order for the per-clause list, submit_assertions/refine_control/show risk acceptance for the follow-up actions. It also constrains invocation ('name exactly one id') so the agent knows the required input shape.

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