Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Edit Attacker

edit_attacker

Update an existing attacker in a threat model by changing only specified fields, with server-computed likelihood and required change reason for factor overrides.

Instructions

Edit an existing attacker. Only provided fields changed.

When changing identity fields, hold to the attacker authoring contract: capability names the operations performable from the position ("From [position], the attacker can [operations] …"), not just access — otherwise the result is flagged with a quality_warning (see add_attacker).

The composed likelihood is server-derived from the factor fields; to change the rating, set factor values and supply change_reason for the audit trail.

LLM-gated on identity-bearing fields (capability, archetype, position). Factor and trust_boundary edits skip the gate.

503 on evaluator outage, 502 on malformed response, 400 when factor fields, surface_extent or attest_surface_extent are sent without change_reason.

Attesting surface_extent is a person's audited structural declaration, ledgered like a factor override and forking a model version: "whole" makes every objective the attacker appears in a for-all obligation. "point" is REFUSED where an asset on one of those objectives is implemented by several components and is not split-knowledge — reaching any one of them reaches the asset, so a narrowing to one named entry would not be true of it — and it never makes a clause whose own text is universal existential.

Input Schema

TableJSON Schema

Name	Required	Description
`model_id`	Yes	ID of the threat model.
`position`	No	New position (optional).
`archetype`	No	New archetype (optional).
`capability`	No	New capability (optional).
`attacker_id`	Yes	ID of the attacker (e.g., "T1").
`attack_vector`	No	"Network" \| "Adjacent" \| "Local" \| "Physical".
`change_reason`	No	Required when any factor field, ``surface_extent`` or ``attest_surface_extent`` is supplied — documents the operator override for the audit trail.
`server_version`	Yes
`surface_extent`	No	``"whole"`` (operations range over ANY entry of the interface reached) or ``"point"`` (one named entry). Supplying it attests it; requires ``change_reason``.
`attest_position`	No	Operator-attest the attacker's current position without changing it — e.g. to confirm a fully external attacker's empty crossed set so an objective blocked on an unpositioned attacker can be resolved. Pass ``true`` to attest.
`user_interaction`	No	"None" \| "Required".
`attack_complexity`	No	"Low" \| "High".
`trust_boundary_ids`	No	Comma-separated trust boundary IDs — the boundaries this attacker has crossed (its position). Replaces the existing set. Changing it operator-attests the position, which lets reachability trust it for a decisive verdict.
`privileges_required`	No	"None" \| "Low" \| "High".
`likelihood_rationale`	No	New rationale (optional).
`attest_surface_extent`	No	Record the extent already on the attacker as attested, without changing its value. Pass ``true`` to attest; requires ``change_reason``.
`capability_prevalence`	No	"Commodity" \| "Targeted" \| "Rare".

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.77.0Sep 9, 2026

addedInput schema / properties / attest_surface_extent

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Record the extent already on the attacker as\nattested, without changing its value. Pass ``true`` to attest;\nrequires ``change_reason``."
+}

changedInput schema / properties / change_reason / description

Previous value: -"Required when any factor field is supplied —\ndocuments the operator override of LLM-generated factors."New value: +"Required when any factor field, ``surface_extent``\nor ``attest_surface_extent`` is supplied — documents the\noperator override for the audit trail."

addedInput schema / properties / surface_extent

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "``\"whole\"`` (operations range over ANY entry of the\ninterface reached) or ``\"point\"`` (one named entry). Supplying\nit attests it; requires ``change_reason``."
+}

Addedv0.62.2Jul 22, 2026
Removedv0.62.0Jul 17, 2026

Changed2 schema fields changedv0.60.1Jul 17, 2026

addedInput schema / properties / attest_position

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Operator-attest the attacker's current position without\nchanging it — e.g. to confirm a fully external attacker's empty\ncrossed set so an objective blocked on an unpositioned attacker can\nbe resolved. Pass ``true`` to attest."
+}

changedInput schema / properties / trust_boundary_ids / description

Previous value: -"Comma-separated trust boundary IDs (replaces existing)."New value: +"Comma-separated trust boundary IDs — the boundaries\nthis attacker has crossed (its position). Replaces the existing set.\nChanging it operator-attests the position, which lets reachability\ntrust it for a decisive verdict."

First observedv0.57.0Jul 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries full behavioral burden and does so thoroughly: patch semantics, LLM gating, server-derived likelihood, quality_warning on contract violations, specific HTTP error conditions, and surface_extent attestation with forking and refusal rules. This goes far beyond a generic 'edit' description.

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 essential edit semantics and dense with useful detail; no filler sentences. The surface_extent paragraph is long and intricate, but it encodes necessary refusal and forking semantics, so it earns its place despite being heavy.

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 17-parameter mutation tool with no annotations and an output schema present, the description covers all non-obvious behavior: patch semantics, gating, error responses, audit trail requirements, and attestation constraints. Nothing an agent needs to call it correctly is missing.

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 94%, but the description adds critical meaning beyond it: capability must name operations performable from the position, likelihood is server-derived and cannot be set directly, change_reason triggers and error conditions, and surface_extent attestation has deep structural consequences. Without this, several parameters would be ambiguous.

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?

First sentence, 'Edit an existing attacker. Only provided fields changed,' names the exact verb/resource and clarifies patch semantics. It is unambiguously distinct from sibling creation/editing tools and even references add_attacker for the authoring contract.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear operational context: edits an existing attacker, only supplied fields change, identity fields are LLM-gated, and change_reason is required for factor/surface_extent edits. It does not explicitly contrast with alternatives like add_attacker or edit_asset, but its scope is unmistakable and the 'see add_attacker' pointer helps.

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

Deploy Server