Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Decide Proposal

decide_proposal

Accept or reject a threat model proposal when delegation policy permits, closing it and applying any accepted change. Refusals escalate to a person.

Instructions

Accept or reject a proposal. Call this only when the workspace's delegation policy names this decision for this agent at the proposal's tier (the delegation block of get_control_work_order says what you may decide). Mutating: closes the proposal and applies an accepted change.

This is a judgment. The call is refused with HTTP 403 and an escalation_id unless the delegation policy permits it; the refusal parks the decision for a person as a decision_request. Do not retry a refusal: report the escalation_id, poll list_proposals for the outcome, and continue other work.

Accepting an assumption proposal accepts the assumption: it is created if new, attested until expires_at and bound into the group that waited on it, which is then judged again. That is its own decision (assumption_accepted); a rule delegating proposal acceptance does not cover it. Rejecting one records the precondition as rejected for that objective, so it is not proposed again, and the objective keeps its gap.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoOptional note recorded with the decision.
decisionYes``accept`` or ``reject``.
model_idYesID of the threat model.
expires_atNoISO 8601 date an accepted assumption lapses (e.g. "2027-03-29T00:00:00Z"). Applies to accepting an ``assumption`` proposal; omitted, the acceptance lasts a year.
proposal_idYesID of the proposal to decide.
server_versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.83.1
    • addedInput schema / properties / expires_at
      Added value: +{
+  "default": "",
+  "description": "ISO 8601 date an accepted assumption lapses (e.g.\n\"2027-03-29T00:00:00Z\"). Applies to accepting an ``assumption``\nproposal; omitted, the acceptance lasts a year.",
+  "type": "string"
+}
  2. Addedv0.75.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations, so the description carries the full burden and does so: it declares the operation mutating ("closes the proposal and applies an accepted change"), describes the 403 + escalation_id refusal path, notes the decision is parked for a person as a decision_request, warns against retrying, and explains that accepting an assumption is itself a separate decision (assumption_accepted) not covered by a rule delegating proposal acceptance.

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 delegation gate, and every paragraph adds distinct information. It is dense and slightly long, but the length is justified by the authorization and refusal semantics.

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?

An output schema exists, so return values need not be described. Combined with the delegation precondition, refusal handling, and per-kind acceptance semantics, an agent has everything needed to invoke this correctly and recover from a refusal.

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 83%, so the schema already documents most fields. The description still adds real semantics beyond it: expires_at applies specifically to accepting an assumption proposal with a one-year default, and decision acceptance has downstream effects (attestation until expires_at, binding into the waiting group; rejection records the precondition as rejected so it is not re-proposed).

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?

Opens with a concrete verb pair and resource ("Accept or reject a proposal") and distinguishes itself from the sibling tools that create proposals (create_proposal) and read them back (list_proposals). The scope is unambiguous.

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?

States explicitly when this may be called (only when the delegation policy names the decision at the proposal's tier, per get_control_work_order), what to do on refusal (report escalation_id, do not retry, poll list_proposals), and how acceptance differs by proposal kind. When/when-not and the follow-up path are all named.

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