Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Add Attacker

add_attacker

Add a new attacker to a threat model and create a new version by specifying capability, position, archetype, and trust boundaries. Helps model attack paths for security analysis.

Instructions

Add a new attacker to a threat model. Creates a new version.

Authoring contract: capability names the operations the attacker can perform from its position and what they achieve — not just the access or vantage point. Phrase it as "From [position], the attacker can [concrete operations] …" (e.g. "From the network path between the API server and the database, the attacker can read and alter requests and responses to exfiltrate data in transit or inject forged responses"). A capability that states only access is flagged with a quality_warning and the control objectives derived from it may be under-specified.

The caller supplies identity-bearing fields (capability, position, archetype, trust_boundary_ids); the backend LLM-reasons the factor decomposition. Override any factor post-create via edit_attacker with a change_reason. Mirror of add_asset semantics.

Three outcomes (normal create / auto-restore / similar-rejection) mirror add_asset. 503 on factor-reasoning or restore-candidate evaluator outage, 502 on malformed restore-candidate response.

surface_extent says how much of the reached interface this attacker's operations range over. An attacker ranging over the whole interface makes the objectives it appears in for-all obligations, which only a sound witness (typed_boundary / sink_default_deny) can credit. Declaring it here is an operator statement about the attacker's reach, recorded attested with its change_reason, so a create takes the two together. Only whole is declarable on a create: narrowing to one named entry is a statement about the objectives the attacker anchors, and a create has none yet — add the attacker, then narrow it with edit_attacker and a change_reason, where the narrowing is checked against the assets those objectives defend. There is no attacker status to set.

Input Schema

TableJSON Schema

Name	Required	Description
`model_id`	Yes	ID of the threat model.
`position`	No	Position/access level.
`archetype`	No	Archetype (e.g., "insider", "external").
`capability`	Yes	Attacker capability description (required).
`change_reason`	No	Required when ``surface_extent`` is supplied — documents the declaration for the audit trail.
`server_version`	Yes
`surface_extent`	No	``"whole"`` when, from its position, the attacker's operations range over ANY entry of the interface it reaches (any endpoint, request, row, file, message or frame). Recorded as attested by this call and requires ``change_reason``. Omit to leave it undeclared, which is the ordinary case.
`trust_boundary_ids`	No	Comma-separated trust boundary IDs.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.77.0Sep 9, 2026

addedInput schema / properties / change_reason

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Required when ``surface_extent`` is supplied —\ndocuments the declaration for the audit trail."
+}

addedInput schema / properties / surface_extent

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "``\"whole\"`` when, from its position, the attacker's\noperations range over ANY entry of the interface it reaches\n(any endpoint, request, row, file, message or frame). Recorded\nas attested by this call and requires ``change_reason``. Omit\nto leave it undeclared, which is the ordinary case."
+}

Addedv0.62.2Jul 22, 2026
Removedv0.62.0Jul 17, 2026
First observedv0.57.0Jul 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations present, the description carries the full transparency burden and does so thoroughly. It discloses that the call creates a new version, that the backend LLM-reasons the factor decomposition, that three outcomes mirror add_asset, that 503/502 errors can occur, and that surface_extent is recorded as an attested operator statement.

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?

The description is long but information-dense, with important constraints front-loaded and clearly separated. It loses a point for some redundancy, such as mentioning the add_asset mirror twice, and for an extended rationale about for-all obligations that could be tighter.

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 create operation with backend reasoning, side effects, error conditions, and an attestation parameter, the description covers all the non-obvious context an agent needs. It explains versioning, alternative routing, failure modes, the capability contract, and the special surface_extent workflow, while output format is covered by the output schema.

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 high at 88%, but the description still adds significant meaning beyond the schema. It defines the capability authoring contract with a concrete pattern and quality_warning consequence, and it explains surface_extent's create-time restriction and attestation semantics in ways the schema does not.

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 specific verb and resource: "Add a new attacker to a threat model." It also distinguishes itself from the sibling edit_attacker by noting that post-create factor overrides and surface narrowing happen there, and it names add_asset as its semantic mirror.

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?

The description gives explicit when-to-use guidance: use this tool to create an attacker, and use edit_attacker afterward to override factors or narrow surface_extent. It also tells the caller that only "whole" is declarable at create time and that narrowing belongs on a later edit, which prevents a common misuse.

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

Deploy Server