Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Submit Attestation

submit_attestation

Record a responsible party's affirmation that an external assumption holds, letting it mitigate linked control objectives until expiry. Non-applicability assumptions require CI verification.

Instructions

Record that a responsible party affirmed an assumption holds.

Only for external assumptions. Non-applicability assumptions require CI verification (submit assertions + run mipiti-verify) — manual attestation is rejected for them.

An assumption with a current attestation can mitigate linked COs. When the attestation expires, those COs become at-risk until re-attested or covered by controls.

Attesting accepts the assumption, which is a judgment about the world the platform cannot check: a program may do it only under a workspace delegation rule for assumption_accepted; otherwise the call is refused with HTTP 403 and an escalation_id and the attestation is parked for a person. An attestation holds for the text it was given for: editing the assumption's description retires it, and the assumption must be accepted again. An assumption need not be linked to an objective to be accepted — one bound into a control's group (see strengthen_controls) counts only while it is accepted.

An attestation is a responsible party's claim, never a proof over every site: it can cover an existential clause of a control (its tier reads claimed) and never a for-all one, where only a sound witness counts. An attestation the platform mints from CI results is no stronger than the weakest assertion behind it. The exits for a universal objective that cannot be proven are a risk acceptance or a not-applicable disposition.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYesID of the threat model.
statementNoWhat was attested.
expires_atNoISO 8601 expiry date (e.g., "2026-06-30T00:00:00Z").
attested_byNoWho is attesting (name, role, organization).
evidence_urlNoOptional link to supporting documentation.
assumption_idYesID of the assumption (e.g., "AS1").
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

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the 403 refusal with escalation_id and that the attestation is parked for a person, that editing the assumption's description retires the attestation, and that expiry flips linked COs to at-risk. It further explains the semantics of coverage (existential 'claimed' tier vs for-all) so the agent knows what the write actually buys.

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 action and the exclusion, and every paragraph carries behavioral information. It is however long and drifts into conceptual prose ('a judgment about the world the platform cannot check', 'no stronger than the weakest assertion behind it') that could be tightened without losing actionable content.

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 mutation tool totalling a 7-parameter schema with an output schema present, the description covers preconditions, failure mode, side effects, lifetime, and interaction with linked COs. Nothing an agent needs to invoke it correctly is missing, and return values are covered by the output schema.

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 86%, so the schema already documents model_id, assumption_id, expires_at, attested_by and evidence_url. The description adds contextual meaning around the attested statement ('holds for the text it was given for') but no new per-parameter syntax or format guidance, so the baseline 3 applies.

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 ('Record that a responsible party affirmed an assumption holds') and immediately scopes it apart from the sibling workflow: external assumptions only, not non-applicability ones. An agent can distinguish this from submit_assertions and submit_findings without opening any 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?

Gives explicit when-to-use ('Only for external assumptions'), when-not ('non-applicability assumptions... manual attestation is rejected'), and names the alternative path ('submit assertions + run mipiti-verify'). It also states the delegation-rule precondition that governs whether the call is allowed.

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