Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Apply Entity Proposals

apply_entity_proposals

Applies quality-check correction proposals to threat-model assets and attackers in a new model version, returning per-entity outcomes, version, or conflict details.

Instructions

Accept the quality check's corrections of assets and attackers, in one new model version.

Applying is accepting: a judgment normally the owner's. A program's is parked for a person (refused, with escalation_id: do not retry) unless the workspace delegates entity_correction_accepted. A doubted claim you can establish, or take conservatively, is answered with answer_entity_question instead; a property that does not apply is declared not applicable, since a correction never removes one.

Read the correction as quality on get_entity (or the review queue's entity_quality row): proposed holds the corrected words, proposal_hash names them, input_hash the verdict, and drops each claim the words before made that the correction does not, with why. RELAY proposed AND drops TO THE PERSON. A correction no reader marked is a rewording, else a narrowing; under a rule admitting only rewording, a claim every reader missed is applied by the program: the residual that policy accepts. It never moves a position, credentials or components; the entity is rated for its new words, a person's rating kept and the new one held pending (settle_entity_rating).

One outcome per entity: applied (correction_kind); unbound (no proposal_hash: the correction and its hash are returned); refused; property_removed (never written); rejected (another entity, a duplicate, or internal identifiers, reason says); stale (read it again); none; unavailable (try again). One entity never stops the others; a model changed since it was read writes nothing, each such item stale beside conflict.

Returns {results, version?, conflict?}.

Input Schema

NameRequiredDescriptionDefault
model_idYesID of the threat model.
proposalsYesJSON array of ``{"entity_id", "input_hash", "proposal_hash"}``, each ``input_hash`` and ``proposal_hash`` as the verdict was read.
server_versionYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.100.0
    • changedInput schema / properties / proposals / description
      Previous value: -"JSON array of ``{\"entity_id\", \"input_hash\"}``, each\n``input_hash`` as the verdict was read."New value: +"JSON array of ``{\"entity_id\", \"input_hash\",\n\"proposal_hash\"}``, each ``input_hash`` and ``proposal_hash`` as\nthe verdict was read."
  2. Addedv0.97.0

TDQS

A4.7/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 thoroughly: it discloses that applying is normally the owner's judgment, program refusal and escalation behavior, delegation conditions, partial application across entities, stale/conflict handling, and the fact that positions, credentials, and components are never moved. It also explains rating behavior and the pending settlement path.

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, but the body is dense and jargon-heavy, with long clauses such as the rewording-versus-narrowing policy that take effort to parse. The outcome list is complete but buried in prose rather than structured, so the definition is longer and harder to scan than necessary.

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?

Given a complex mutation tool with no annotations and an output schema, the description is complete enough to invoke correctly: it covers refusal, stale, conflict, partial success, and the return keys `{results, version?, conflict?}`. The remaining gap around `server_version` is minor.

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

Parameters4/5

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

Schema coverage is 67%, and the description compensates for the most important parameter by explaining how `proposal_hash` names corrected words, `input_hash` names the verdict, and `drops` lists removed claims. It does not explain `server_version`, and `model_id` is left to the schema, but the core proposal semantics are substantially enriched.

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?

The opening states a specific verb and resource: 'Accept the quality check's corrections of assets and attackers, in one new model version.' It distinguishes this action from related tools by naming `answer_entity_question`, `get_entity`, and `settle_entity_rating`. An agent can identify the operation without opening the 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?

It explicitly routes doubted claims to `answer_entity_question` instead, explains that refused corrections are parked for a person with an `escalation_id` and should not be retried unless delegation exists, and tells the agent to re-read on `stale` and retry on `unavailable`. These are concrete when/when-not rules and alternatives.

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