Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Add Asset

add_asset

Add a new asset to a threat model by naming the protected data or resource and its security property. Creates a new version, derives impact factors, and restores soft-deleted assets when matched.

Instructions

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

Authoring contract: name the data or resource being protected and the security property at stake (Confidentiality / Integrity / Availability / Usage) — not a mechanism, control, or capability. Name the thing whose exposure or corruption is the harm (e.g. "per-organization key-wrapping material", not "KMS encryption"). An asset phrased as a mechanism is flagged with a quality_warning and the control objectives derived from it may be under-specified.

There is no asset status to set: an asset that does not apply is recorded with a non-applicability assumption or create_co_disposition.

The caller supplies identity-bearing fields (name, description, security_properties, notes) plus optional component scoping; the backend LLM-reasons the factor decomposition (and composes the impact rating from it). The same prompt the generation pipeline uses for LLM-produced assets is reused here, so factors are calibrated consistently regardless of who introduced the asset. Override any factor post-create via edit_asset with a change_reason for the audit trail.

component_ids (optional) links the asset to one or more deployable units. Components are the canonical bridge between security architecture (trust boundaries) and code organization (repos); linking assets here flows boundary context into the reachability graph. Multi-component is the right shape for multi-instance assets (e.g., a session token on client + cache).

LLM-gated against a re-add of a previously soft-deleted asset on the same model. Three possible outcomes:

  • Normal create — fresh asset with a new ID. Returns the envelope {"model": ThreatModel, "controls_carried": N, ...}.

  • Auto-restore — proposal matched a soft-deleted asset; that asset is un-deleted (CO tombstones revive). Response carries auto_restored: True, restored_asset_id, and discarded_fields.

  • Similar-verdict rejection — {"accepted": False, "classification": "similar", "candidate_restore_id": "A-N", ...}; nothing saved.

Fails with a tool error on:

  • 503 — restore-candidate evaluator OR factor-reasoning evaluator unavailable. Retry with backoff.

  • 502 — restore-candidate evaluator returned malformed response. Retry same prompt.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesAsset name (required).
notesNoOptional notes.
model_idYesID of the threat model.
descriptionNoOptional description (recommended — feeds the factor-reasoning prompt).
component_idsNoComma-separated component IDs scoping the asset (e.g., "CMP1,CMP2"). Empty / omitted = unscoped. Validated against components declared on the model.
server_versionYes
security_propertiesNoComma-separated properties, e.g. "C,I,A" (default: "C").

Output Schema

TableJSON 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.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden — and it delivers richly. It discloses side effects (creates a new version), gating behavior (LLM-gated against re-add of soft-deleted assets), the three possible outcomes with their response signatures (normal create, auto-restore with revived CO tombstones, similar-verdict rejection), and explicit failure modes (503 and 502 with retry guidance). This is exceptional behavioral disclosure for an unannotated 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 description is long but well-structured and front-loaded: the core purpose leads, then the authoring contract, then outcomes, then errors. Bold headers, bulleted outcome lists, and bold inline flags make it scannable. Every section adds distinct information rather than padding, though it borders on being dense enough to skim past details.

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 this is a complex, LLM-gated mutation tool with an output schema, the description is complete: it covers the accepted shapes, the contract for a good asset, the three possible returns, and the failure modes. Nothing an agent needs to invoke it correctly — including what happens after invoking — is missing.

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 high (86%), so the schema already documents most parameters. The description adds genuine meaning beyond it: it explains that description feeds the factor-reasoning prompt, that component_ids is the canonical architecture-to-code bridge and multi-component is right for multi-instance assets, and it frames the authoring contract for name. It does not elaborate on server_version or notes, but those are self-evident, so the description compensates where it matters.

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?

States a specific verb and resource — 'Add a new asset to a threat model' — and immediately distinguishes its effect by noting 'Creates a new version.' The description sets this apart from sibling tools like edit_asset (which overrides post-create) and add_component/add_attacker by naming the precise resource being added. An agent can tell this from its siblings without opening their schemas.

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?

The description names edit_asset as the alternative for post-create overrides, and create_co_disposition for recording non-applicability — giving clear routing advice. The component_ids paragraph also explains when multi-component is the right shape. However, it does not explicitly contrast with add_component or add_attacker (the other 'add_*' family members), so sibling differentiation is incomplete.

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