Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Check Entity Quality

check_entity_quality

Estimate or queue quality checks for named assets and attackers lacking a current verdict; call without confirmation for a cost estimate, then confirm to run checks in the background.

Instructions

Ask for the quality check of the assets and attackers you name (every one when you name none) that have no current verdict: an entity whose quality reads unchecked, or one changed since its last check. Without confirm_estimate it only estimates; with it, the checks are queued and run in the background. Creates no model version.

Checking may be paid. Call it first without confirm_estimate, RELAY THE ESTIMATE TO THE PERSON, and confirm only when they agree; never confirm on your own. The answer says where each named entity stands: current (its verdict answers it as it stands; it is not checked again: to dispute it, answer its flag with answer_entity_question), checking (its check is queued already), answered (a stored verdict answers it and is served again, at no cost), platform_scope (made stale by a change to the platform; checked at Mipiti's cost) and customer_scope (checked at the caller's cost; estimate gives an upper bound, the deeper review running only where the first pass flags). A confirmation the caller's balance cannot cover is refused with 402 and queues nothing; an id naming no asset or attacker of the model is refused 400 unknown_entity. Read each entity again with get_entity for its verdict once it lands. To ask every entity again whatever is stored, use revalidate_entity_quality.

Returns {platform_scope, customer_scope, current, checking, answered, estimate, billing, confirmed, queued, message}.

Input Schema

Name	Required	Description
`model_id`	Yes	ID of the threat model.
`entity_ids`	No	JSON array of asset and attacker ids (e.g. ``["A-17", "T-04"]``); empty for every entity.
`server_version`	Yes
`confirm_estimate`	No	Queue the checks the estimate describes.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.97.0Oct 28, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With zero annotations, the description carries the full burden and does so: it discloses that checking may be paid, that confirmed checks queue and run in the background, that it creates no model version, which statuses are free or charged, and the exact failure modes (402 with nothing queued, 400 unknown_entity). This is precisely the cost, async, and side-effect context annotations would normally supply.

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?

Purpose and the no-confirm-without-consent rule are front-loaded, and every section adds decision-relevant content. It is dense and backtick-heavy, and the closing sentence plus status glossary partially restate return values the output schema already carries, which costs a little economy.

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 paid, asynchronous, mutating-in-effect tool with no annotations, the description covers cost, consent sequence, async behavior, status semantics, error codes, and next steps. An agent has everything needed to invoke it correctly and safely without opening other resources.

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 75%, and the prose adds real meaning beyond it: empty entity_ids means every entity, confirm_estimate flips from estimate-only to queued billing, and an id naming no entity returns 400. server_version and model_id get no narrative treatment, but they are self-evident from the schema.

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 and resource ('ask for the quality check of the assets and attackers you name') plus the exact scope condition ('that have no current verdict', 'every one when you name none'). It also explicitly distinguishes itself from two siblings: 'answer_entity_question' for disputing a verdict and 'revalidate_entity_quality' for re-asking everything regardless of stored state.

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 an explicit call protocol: 'Call it first without confirm_estimate, RELAY THE ESTIMATE TO THE PERSON, and confirm only when they agree; never confirm on your own.' It also names when to use the alternative revalidate_entity_quality and steers to get_entity to read results, leaving nothing to inference.

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

Deploy Server