Skip to main content
Glama
Sign In
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 accepted changes; refused decisions 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

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.
record_onlyNoAccepting parked answers to behavioural questions starts the extraction they complete, billed to whoever accepts; True records them without it. Default False.
server_versionYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.88.0
    • addedInput schema / properties / record_only
      Added value: +{
+  "default": false,
+  "description": "Accepting parked answers to behavioural questions\nstarts the extraction they complete, billed to whoever accepts;\nTrue records them without it. Default False.",
+  "type": "boolean"
+}
  2. 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"
+}
  3. Addedv0.75.0

TDQS

A4.6/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: it declares the operation mutating, describes the 403 refusal with escalation_id, distinguishes the self-decision for accepting an assumption proposal, explains expires_at binding and re-judging, and states the persistence effect of rejection. This is unusually rich behavioral disclosure.

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?

Three dense paragraphs, front-loaded with purpose and the gating condition, then refusal handling, then per-proposal-type semantics. Long but every sentence carries actionable information; only mild redundancy.

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 explained, and the description still covers the mutation effect, failure mode, and decision-type-specific consequences. Nothing an agent needs to call this complex judgment tool correctly is missing.

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

Parameters3/5

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

Schema coverage is 86%, so the schema already documents decision (accept/reject), expires_at, record_only, and note. The description reinforces the accept/reject semantics and the assumption-specific effect of expires_at, but adds little for model_id, proposal_id, server_version, or note. Baseline 3 is appropriate.

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 (accept/reject) and resource (proposal), and immediately scopes it against siblings by naming get_control_work_order for the delegation policy and list_proposals for outcome polling. An agent can identify the operation and its gate without opening any 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?

Gives an explicit precondition (delegation policy must name this decision for this agent at the proposal's tier), explicit when-not behavior (refusal returns 403 and parks a decision_request), and explicit alternative actions (do not retry; poll list_proposals). This is a genuine when/when-not/alternative guide.

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