Mipiti MCP Server

by Mipiti

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Answer Behavioural Questions

answer_behavioural_questions

Answer open behavioural questions, many in one call. Mutating; creates a model version.

Instructions

Answer open behavioural questions, many in one call. Mutating; creates a model version.

Answer only from what the code or the owner shows; say unknown rather than guess, in a sentence or two. An extraction runs once every owner question has an answer, or on extract_now=True (with no answers, refused 409 questions_open while one is open, and 409 extraction_running while one is queued or running, or with no answer since it started: poll it), billed to the caller (402 when short).

dry_run=True records nothing (no version, no escalation) and returns outcome: whether the answers extract (extracts, estimate), the questions left or raised. Dry-run, answer what is raised, then submit once.

An answer is a fact (text), or a disposition its question lists: not_needed, not_behaviour, unknown, as_stated; text is then a note. A question about the model's own structure carries structured: answer with structured naming the ids offered, {"classes": [...]} or {"public": true}, {"zones": {id: zone}}, {"zone": z}, {"actions": [...]}, {"changes": {field: [actions]}}, {"receivers": [...]}, {"elements": [id | {"id", "secret": true}]} (a zone's contents: an id not offered is a new element there; not_needed says it holds nothing). An offer with new_zones takes a zone it does not list, one with new_actors a receiver it does not list, each added (409 id_in_use when the id names something else). It edits the model at once. Where the code does more or less than the sentence, add contradicts: {"direction": "code_does_more" | "code_does_less", "quote"?} (409 drift_is_defect over a defect's sentence).

A program's answer is a judgment: refused with 403 and an escalation_id unless delegated. Do not retry; poll list_proposals.

With an extraction asked for, queued is true: follow it with get_behavioural_model(view="status", wait_seconds=50).

Input Schema

Name	Required	Description	Default
`answers`	No	JSON array of ``{"question_id", "text"?, "disposition"?, "structured"?, "contradicts"?}``, e.g. '[{"question_id": "q1", "text": "Only the owner deletes."}, {"question_id": "q3", "structured": {"classes": ["org_admin"]}}]'.	[]
`dry_run`	No	Return what the answers would do (``outcome``) and record nothing. Default False.
`model_id`	Yes	ID of the threat model.
`extract_now`	No	Extract now, with the answers collected.
`server_version`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.90.0Oct 22, 2026

addedInput schema / properties / dry_run

Added value: +{
+  "default": false,
+  "description": "Return what the answers would do (``outcome``) and record\nnothing. Default False.",
+  "type": "boolean"
+}

Changed2 schema fields changedv0.88.0Oct 16, 2026

changedInput schema / properties / answers / description

Previous value: -"JSON array of ``{\"question_id\": \"...\", \"text\": \"...\",\n\"disposition\"?: \"...\"}``. Example: '[{\"question_id\": \"q1\",\n\"text\": \"Only the owner can delete a record.\"}, {\"question_id\":\n\"q2\", \"disposition\": \"unknown\"}]'. Empty to extract with answers\ncollected."New value: +"JSON array of ``{\"question_id\", \"text\"?, \"disposition\"?,\n\"structured\"?, \"contradicts\"?}``, e.g. '[{\"question_id\": \"q1\",\n\"text\": \"Only the owner deletes.\"}, {\"question_id\": \"q3\",\n\"structured\": {\"classes\": [\"org_admin\"]}}]'."

changedInput schema / properties / extract_now / description

Previous value: -"Extract now, with the answers given and those already\ncollected."New value: +"Extract now, with the answers collected."

Addedv0.87.0Oct 14, 2026

TDQS

A4.6/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 burden and discharges it: mutation semantics (creates a model version, edits the model at once), the extraction trigger conditions, and a complete error map — 409 questions_open, 409 extraction_running, 409 id_in_use, 409 drift_is_defect, 402 when short of credit, 403 with escalation_id for program answers. dry_run's exact side-effect exemption is also stated.

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

Conciseness3/5

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

Every sentence carries information, but the layout is a dense run-on: the extraction error codes are crammed into a parenthetical after 'extract_now=True', and the structured-answer grammar sits in one long block. Front-loading is good (mutation and purpose first) but scannability suffers for a definition this long.

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?

Output schema exists so return values need no explanation, yet the description still pre-announces 'outcome', 'extracts'/'estimate', 'queued', and 'raised', which is exactly what an agent needs to branch on. Permissions (403/escalation), billing (402), idempotency (dry_run), and the required follow-up call are all covered.

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

Parameters5/5

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

Schema coverage is 80% (baseline 3), but the description adds semantics the schema lacks: the closed set of dispositions (not_needed, not_behaviour, unknown, as_stated), the meaning of text-as-note when a disposition is used, the accepted structured shapes per question kind, and the contradicts.direction vocabulary. This materially reduces misfill risk on the hardest parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Answer open behavioural questions') and adds the key distinguishing scope 'many in one call', plus the mutation disclosure 'Mutating; creates a model version'. It never explicitly contrasts itself with the closely related extract_behavioural_model or get_behavioural_model siblings, so the differentiation is implied rather than spelled out.

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 explicit operating rules: answer only from code/owner evidence, say 'unknown' rather than guess, 'Dry-run, answer what is raised, then submit once', 'Do not retry; poll list_proposals', and 'follow it with get_behavioural_model(view="status", wait_seconds=50)'. It names the alternative tools for the escalation and status paths and gives trigger conditions for each.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server