Skip to main content
Glama
Sign In
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Edit Asset

edit_asset

Update an existing threat-model asset's name, description, security properties, factor ratings, or notes. Only the fields you provide change, and identity edits are checked before saving.

Instructions

Edit an existing asset. Only provided fields changed.

When changing identity fields, hold to the asset authoring contract: name the data/resource protected and its security property, not a mechanism — otherwise the result is flagged with a quality_warning (see add_asset). There is no status field to set.

The composed impact is server-derived from the factor fields; there is no way to set it directly. To change the rating, set factor values (the platform composes the new rating) and supply change_reason documenting the operator override of the LLM-generated factors. The reason is captured in the rating-revision audit trail. Over a rating held pending (rating_pending on get_entity), a factor edit settles the pair with the rating it sets, a judgment (rating_reconfirmed) a program makes only under a delegation rule, else parked whole for a person.

New words (name, description, security properties) are rated for: one rating call, at your cost; a rating a person chose is kept and the new one held pending beside it. Adopting a quality check's advice is your own edit of the words, stated with its change_reason.

LLM-gated on identity-bearing fields (name, description, security_properties). Factor and notes edits skip the gate.

Outcomes when identity fields change:

  • Accepted edit (LLM classifies as preserve) — {model, entities, controls_carried, ...}: the model's id, version and title, and the asset as it now stands.

  • Rejected edit (LLM classifies as replace / ambiguous) — {"accepted": False, ...}; nothing saved. Soft-delete + add-new instead.

Editing a soft-deleted asset is rejected — restore_entity (entity_type="asset") first. 503 on evaluator outage or when the rating call for new words fails (nothing saved), 502 on malformed response, 400 when factor fields are sent without change_reason, 409 when the model changed since it was read (read it again and send the edit again).

Input Schema

NameRequiredDescriptionDefault
nameNoNew name (optional).
notesNoNew notes (optional).
asset_idYesID of the asset (e.g., "A1").
model_idYesID of the threat model.
descriptionNoNew description (optional).
blast_radiusNo"Isolated" | "Multiplicative" | "Cascading".
change_reasonNoRequired when any factor field is supplied — documents the operator override of LLM-generated factors for the audit trail.
recoverabilityNo"Trivial" | "Manageable" | "Permanent".
server_versionYes
usage_subscoreNo"None" | "Low" | "High".
impact_rationaleNoNew rationale (optional).
regulatory_scopeNo"None" | "Notification" | "Legal".
integrity_subscoreNo"None" | "Low" | "High".
security_propertiesNoComma-separated properties (optional).
availability_subscoreNo"None" | "Low" | "High".
confidentiality_subscoreNo"None" | "Low" | "High".

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.62.2
  2. Removedv0.62.1
  3. First observedv0.57.0

TDQS

A4.5/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 behavioral burden and does so: it discloses the LLM quality gate, server-derived impact, required change_reason for factor edits, rating-pending settlement behavior, rating costs, accepted/rejected outcomes, and HTTP error conditions. This is unusually transparent for a mutation tool.

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 definition front-loads its purpose and uses a bullet list for accepted/rejected outcomes, which helps structure the complex behavior. However, several paragraphs are dense and clause-heavy, such as the rating-pending settlement sentence, so it is informative but not maximally concise.

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?

Given 16 parameters, complex state interactions, and an existing output schema, the description is complete enough: it covers prerequisites, gating, mutation semantics, outcomes, and failure modes. An agent has what it needs to call and interpret the tool.

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

Parameters4/5

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

Schema coverage is 94%, so baseline is 3; the description adds useful semantics by grouping parameters into identity-bearing, factor, and notes fields, explaining that impact and status are not directly settable, and clarifying change_reason's audit role. It does not define each of the 16 parameters, but the schema already does.

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?

The opening sentence names a specific verb and resource ('Edit an existing asset') and states patch semantics ('Only provided fields changed'), so an agent knows this is a partial update rather than a create or replace. It does not directly distinguish itself from other edit_* siblings, though later references to add_asset and restore_entity help.

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?

It gives explicit when/when-not guidance: identity-bearing fields are LLM-gated, factor and notes edits skip the gate, soft-deleted assets require restore_entity first, and rejected identity edits should become soft-delete + add-new. It also names add_asset for the authoring contract, providing strong routing guidance for the key edge cases.

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