Skip to main content
Glama
Mipiti
by Mipiti

Add Asset

add_asset

Adds a new asset to a threat model, creating a new version. Name the data or resource protected and its security property (Confidentiality, Integrity, Availability, Usage) to define what the model safeguards.

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 or control ("per-organization key-wrapping material", not "KMS encryption"). An asset phrased as a mechanism is flagged with a quality_warning and yields under-specified control objectives. An asset that does not apply is recorded with a non-applicability assumption or create_co_disposition; there is no status to set.

The platform reasons the factor decomposition and composes impact with the prompt generation uses, so factors are calibrated alike; override one afterwards with edit_asset and a change_reason. component_ids links the asset to the deployable units that hold it, which feeds reachability (several for a multi-instance asset, e.g. a session token on client and cache).

A proposal matching a soft-deleted asset is gated: it either restores that asset (auto_restored: true, restored_asset_id, discarded_fields; its CO tombstones revive) or is refused as similar ({accepted: false, classification: "similar", candidate_restore_id}, nothing saved). A normal create returns {model, entities, controls_carried, ...}: model is the model's id, version and title, entities.assets the asset as created. 503: an evaluator is unavailable, retry with backoff; 502: it answered malformed, retry.

Input 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

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 burden and does so well: it discloses version bumping, quality_warning flagging, soft-delete gating with restore-vs-refuse outcomes, response envelopes for both create and restore paths, and 503/502 retry semantics. This is far beyond what any structured field provides.

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?

Purpose is front-loaded and each contractual block earns its place. It is dense and slightly long, and it spends some words describing return envelopes that the output schema already covers, which is minor redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-param mutation on a complex domain it is essentially complete: authoring rules, linking effect, gating outcomes, error handling, and response shape are all present. The remaining overlap with the output schema slightly dilutes rather than harms completeness.

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 86%, so the baseline is 3, but the description adds real meaning: component_ids 'feeds reachability' with a multi-instance session-token example, security_properties are named, and description is noted to drive the factor-reasoning prompt. This is useful semantics beyond the schema's own hints.

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+resource ('Add a new asset to a threat model') and immediately adds a versioning consequence. It distinguishes itself from the sibling edit_asset by contrasting create time versus later override.

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 authoring contract is explicit about what to name the asset and what not to do (mechanisms vs protections, quality_warning consequences), and it names the alternatives for adjacent cases (create_co_disposition for non-applicable assets, edit_asset for overriding factors). It's strong guidance but stops short of a crisp 'use this instead of X when Y' routing statement across the many sibling tools.

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