Skip to main content
Glama
Sign In
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Create Proposal

create_proposal

Raise a proposal to change a threat model's scope or design for review instead of editing it directly. Persists the change for approval, then poll for the outcome.

Instructions

Raise a proposal to change a model's scope or design. Call this when the code or your analysis says the model should gain or lose a component, or that an attacker position or asset should be removed by design; do not edit the model directly for those changes. Mutating: persists a proposal record.

A proposal is a change of scope or design. Raising one is not deciding it: a person (or an agent under a delegation rule that names the decision) decides it with decide_proposal. Design changes are never applied automatically. Poll list_proposals for the outcome.

Input Schema

NameRequiredDescriptionDefault
kindYesOne of ``add_component`` (payload ``{name, repo_url?, path?, trust_boundary_ids?}``), ``remove_component`` (payload ``{component_id}``), ``design_change`` (payload ``{target_kind: "attacker"|"asset", target_id, design_move}``; take ``design_move`` from ``get_design_leverage``), ``assumption`` (payload ``{co_id, group_id, precondition, assumption_id?, gap?}``: a precondition about the environment that only something outside this system can meet, one declarative sentence; ``assumption_id`` names an existing assumption that states it). A precondition a person already rejected for that objective is refused. ``drift_intent`` (payload ``{finding_id, intent: "intended" | "defect", control_id?, head_commit?}``): whether a description-drift finding was intended (the description is behind the product) or a defect of the code, naming for a defect the control whose passing assertion closes it. ``description_revision`` (payload ``{description, commit_sha?, finding_ids?}``): the whole description revised to what the code at that commit does, addressing those drift findings; accepting it writes the new text and extracts the behavioural model again over it, billed to whoever accepts. A revision that changes the sentence of a finding decided a defect is accepted only by a person. Propose one where ``get_behavioural_model``'s ``drift.revision_suggested`` is true.
payloadYesJSON object string with the fields for ``kind``.
evidenceNoOptional JSON object string, e.g. ``{paths: [], symbols: [], note: ""}``, pointing at what you saw.
model_idYesID of the threat model.
rationaleYesWhy this change is right (what in the code or design supports it).
server_versionYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.88.0
    • changedInput schema / properties / kind / description
      Previous value: -"One of ``add_component`` (payload ``{name, repo_url?, path?,\ntrust_boundary_ids?}``), ``remove_component`` (payload\n``{component_id}``), ``design_change`` (payload ``{target_kind:\n\"attacker\"|\"asset\", target_id, design_move}``; take ``design_move``\nfrom ``get_design_leverage``), ``assumption`` (payload ``{co_id,\ngroup_id, precondition, assumption_id?, gap?}``: a precondition\nabout the environment that only something outside this system\ncan meet, one declarative sentence; ``assumption_id`` names an\nexisting assumption that states it). A precondition a person\nalready rejected for that objective is refused."New value: +"One of ``add_component`` (payload ``{name, repo_url?, path?,\ntrust_boundary_ids?}``), ``remove_component`` (payload\n``{component_id}``), ``design_change`` (payload ``{target_kind:\n\"attacker\"|\"asset\", target_id, design_move}``; take ``design_move``\nfrom ``get_design_leverage``), ``assumption`` (payload ``{co_id,\ngroup_id, precondition, assumption_id?, gap?}``: a precondition\nabout the environment that only something outside this system\ncan meet, one declarative sentence; ``assumption_id`` names an\nexisting assumption that states it). A precondition a person\nalready rejected for that objective is refused.\n``drift_intent`` (payload ``{finding_id, intent: \"intended\" |\n\"defect\", control_id?, head_commit?}``): whether a\ndescription-drift finding was intended (the description is\nbehind the product) or a defect of the code, naming for a defect\nthe control whose passing assertion closes it.\n``description_revision`` (payload ``{description, commit_sha?,\nfinding_ids?}``): the whole description revised to what the code\nat that commit does, addressing those drift findings; accepting it\nwrites the new text and extracts the behavioural model again over\nit, billed to whoever accepts. A revision that changes the\nsentence of a finding decided a defect is accepted only by a\nperson. Propose one where ``get_behavioural_model``'s\n``drift.revision_suggested`` is true."
  2. Changed1 schema field changedv0.83.1
    • changedInput schema / properties / kind / description
      Previous value: -"One of ``add_component`` (payload ``{name, repo_url?, path?,\ntrust_boundary_ids?}``), ``remove_component`` (payload\n``{component_id}``), ``design_change`` (payload ``{target_kind:\n\"attacker\"|\"asset\", target_id, design_move}``; take ``design_move``\nfrom ``get_design_leverage``)."New value: +"One of ``add_component`` (payload ``{name, repo_url?, path?,\ntrust_boundary_ids?}``), ``remove_component`` (payload\n``{component_id}``), ``design_change`` (payload ``{target_kind:\n\"attacker\"|\"asset\", target_id, design_move}``; take ``design_move``\nfrom ``get_design_leverage``), ``assumption`` (payload ``{co_id,\ngroup_id, precondition, assumption_id?, gap?}``: a precondition\nabout the environment that only something outside this system\ncan meet, one declarative sentence; ``assumption_id`` names an\nexisting assumption that states it). A precondition a person\nalready rejected for that objective is refused."
  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 are supplied, yet the description carries the full burden well: it declares the write nature ('Mutating: persists a proposal record'), states that raising is not deciding and that a person or delegated agent decides, and asserts 'Design changes are never applied automatically'. It also tells the agent how to observe the outcome (poll list_proposals), which is exactly the behavioral context missing from structured fields.

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 imperative and the when-to-use constraint before the longer conceptual explanation of proposal/decision separation. Every sentence contributes, though the second paragraph is somewhat expansive for what it adds beyond the first.

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 6-parameter mutating tool with an output schema present, the description supplies what the schema cannot: the decision workflow, the non-automatic application guarantee, and the polling path. Return-value explanation is correctly omitted since an output schema exists.

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 description coverage is 83%, so the schema already documents the kind/payload coupling, evidence shape, and rationale. The description body itself adds little param-level detail beyond reinforcing the kind semantics (assumption preconditions, description_revision billing). Baseline 3 is appropriate when the schema does the heavy lifting.

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?

Specific verb+resource: 'Raise a proposal to change a model's scope or design', followed by a definition ('A proposal is a change of scope or design'). It explicitly distinguishes itself from direct mutation tools ('do not edit the model directly for those changes') and names the paired siblings decide_proposal and list_proposals.

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 trigger ('when the code or your analysis says the model should gain or lose a component, or that an attacker position or asset should be removed by design'), an explicit exclusion ('do not edit the model directly'), and routes to alternatives for the next steps (decide_proposal to decide, list_proposals to poll). Nothing is left 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

Other Tools