Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

List Reconciliation Candidates

list_reconciliation_candidates

List open or rejected duplicate entity candidates between a threat model and its ancestors. Filter by disposition to focus on matches needing review or persisted non-duplicates for reconciliation.

Instructions

Reconciliation triage surface between this model and its ancestors.

When a model inherits entities (assets, attackers, components, trust boundaries) from an ancestor and the operator has authored a locally-named entity that looks like the same real-world thing, the reconciliation engine pairs them so the operator can decide whether to alias the local entity onto the inherited qualified id. disposition selects which side of the triage queue to read:

  • disposition="active" (default) — the OPEN candidate queue: detected pairs the operator has not yet acted on. Tier certain is a deterministic match (same qid or structurally identical) and is safe to auto-apply via apply_certain_reconciliation_match; tier heuristic is a fuzzy name/description match that needs review. Previously-rejected pairs are filtered out of this queue. Paginated via page / page_size. Returns {model_id, flag_enabled, total, tiers: {certain: int, heuristic: int}, page, page_size, candidates: [{kind, own_qid, inherited_qid, tier: "certain"|"heuristic", reasons: [str, ...]}, ...]}. When composition is disabled on the backend, total is 0, candidates is empty, and flag_enabled: false.

  • disposition="rejected" — the operator's persisted "these are NOT duplicates" decisions, in rejected_at ascending order (the same set the candidate detector consults to filter the active queue). Use this to render the rejected section of a triage view, or to find the surrogate id needed by unreject_reconciliation_candidate. NOT paginated — page / page_size are ignored. Returns {model_id, flag_enabled, rejections: [{id, model_id, kind, own_qid, inherited_qid, rejected_by, rejected_at}, ...]}. When composition is disabled on the backend, rejections is empty and flag_enabled: false; the same empty list is returned with flag_enabled: true when the rejection store is not configured on the instance.

Use on child models in a recursive tree to find duplicates that should be collapsed before they distort coverage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoACTIVE disposition only. 1-indexed page number. Default 1. Ignored when ``disposition="rejected"``.
model_idYesID of the descendant threat model.
page_sizeNoACTIVE disposition only. Items per page. Default 50. Ignored when ``disposition="rejected"``.
dispositionNoWhich side of the queue to read — ``"active"`` (default, open candidates) or ``"rejected"`` (persisted not-a-duplicate decisions).active
server_versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.68.2
    • addedInput schema / properties / disposition
      Added value: +{
+  "default": "active",
+  "description": "Which side of the queue to read — ``\"active\"``\n(default, open candidates) or ``\"rejected\"`` (persisted\nnot-a-duplicate decisions).",
+  "type": "string"
+}
    • changedInput schema / properties / model_id / description
      Previous value: -"ID of the threat model."New value: +"ID of the descendant threat model."
    • changedInput schema / properties / page / description
      Previous value: -"1-indexed page number. Default 1."New value: +"ACTIVE disposition only. 1-indexed page number. Default 1.\nIgnored when ``disposition=\"rejected\"``."
    • changedInput schema / properties / page_size / description
      Previous value: -"Items per page. Default 50."New value: +"ACTIVE disposition only. Items per page. Default 50.\nIgnored when ``disposition=\"rejected\"``."
  2. Addedv0.62.2
  3. Removedv0.62.1
  4. First observedv0.57.0

TDQS

A4.9/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 behavioral burden. It discloses return shapes for both dispositions, pagination behavior, and that page/page_size are ignored for rejected. It also covers edge cases: composition disabled causes empty results and flag_enabled=false; an unconfigured rejection store yields empty rejections with flag_enabled=true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Long but justified by two modes and several edge cases. The lead sentence gives the core purpose, the two disposition sections are clearly structured, and there is no filler or irrelevant detail.

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?

Despite no annotations, the description covers when to use the tool, response shapes, pagination, ordering, cross-tool routing, and backend-dependent edge cases. An agent has enough context to call it correctly and interpret its results.

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 description coverage is 80%, and the description adds meaning to disposition by defining active vs rejected, conffirms defaults, and clarifies that pagination applies only to active. It does not explain server_version, leaving a small gap, but the other parameters are well covered by the schema and description.

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 it lists reconciliation candidates and defines two dispositions: active open candidates and rejected persisted non-duplicate decisions. It also references sibling actions apply_certain_reconciliation_match and unreject_reconciliation_candididate, so an agent can distinguish this list tool from mutation/reversal tools.

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?

Explicitly says to use on child models in a recursive tree to find dupicates that should be collapsed. It also explains when to use each disposition: active for pending triage, rejected for rendering the rejected section or finding the surrogate id needed by unreject_reconciliation_candidate, and routes certain-tier matches to apply_certain_reconciliation_match.

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