Skip to main content
Glama
Sign In
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Review Queue

get_review_queue

Returns a ranked, read-only review queue of items needing a decision or re-check, helping you prioritize escalations, proposals, assumptions, and stale controls for maintenance.

Instructions

Returns the workspace's review queue: what needs a decision or a re-check, ranked. Read-only; no side effects.

Each row carries an item_type, one of escalation (a judgment an agent was refused and parked for a person), proposal (an open change of scope or design, or an assumption proposal: a precondition a strengthening run found only the environment can meet), unaccepted_assumption (an assumption something depends on that is not accepted — never attested, lapsed, or its text changed since it was attested — with the controls and objectives that wait on it), open_assumption, behavioural_question (an open question about what the system does, answered with answer_behavioural_questions), behavioural_link (an element of the behavioural model not yet linked to an asset or trust boundary, or linked to one that lacks the property at stake; see get_behavioural_links), not_applicable_refuted (a person's statement that a property does not apply to an asset, which the behavioural model contradicts: under a confirmed model it no longer counts, under an unconfirmed one it still does; ask the person to revise or revoke it, or to confirm the model), position_disagreement (an attested attacker position a producer would place elsewhere), behavioural_attacker (get_behavioural_attackers), inventory_judgement (get_inventory_judgements), or stale_control (an implemented/verified control whose assertions have not been checked in 90+ days). Rows are ranked: escalations, then proposals and the behavioural rows by risk tier, then position disagreements, unaccepted assumptions, open assumptions and stale controls. Escalations and proposals are decided with decide_proposal; an unaccepted assumption is accepted with submit_attestation; for each stale control, verify its assertions against the codebase. Accepting an assumption is a person's judgment unless the workspace delegates it. Start here for periodic maintenance.

Input Schema

NameRequiredDescriptionDefault
server_versionYes

Output 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/5.0
Behavior4/5

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

No annotations are provided, but the description explicitly declares read-only/no side effects and discloses ranking order and decision semantics per row. It also notes assumption acceptance is a person's judgment unless delegated, though it omits auth, rate, and pagination details.

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-loads the core return and read-only property, then enumerates item types. The length is substantial but justified by the many row types; structure would benefit from bullets but remains organized.

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 complex aggregate queue with an output schema present and no annotations, the description supplies item semantics and next actions. It omits parameter context and auth details, but covers enough for correct interpretation.

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

Parameters2/5

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

The sole required parameter server_version has zero schema description coverage and is never mentioned in the description, so the agent gets no meaning for it. With one undocumented parameter, the description fails to compensate for the schema gap.

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?

Returns the workspace's review queue ranked, and enumerates item_type values with what each represents. This clearly distinguishes it from narrow sibling getters and makes clear it is an aggregate decision queue.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Says 'Start here for periodic maintenance' and routes each row type to the tool that resolves it (decide_proposal, submit_attestation, etc.). It provides strong when-to-use context, though it does not state explicit when-not or contrast with listing siblings like list_proposals.

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