Skip to main content
Glama
Mipiti
by Mipiti

add_asset

Create a new asset in a threat model, optionally scoping to components, and generate a new version. Automatically restores soft-deleted duplicates or rejects similar assets.

Instructions

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

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

Behavior5/5

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

No annotations provided, but description comprehensively covers creation of new version, LLM factor reasoning, consistent prompting, three outcomes with detailed conditions, and failure modes (503, 502). Exceeds expectations for disclosure.

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?

Well-structured with bullet points for outcomes and failure modes. Front-loaded core purpose. Somewhat lengthy but every sentence adds value; slight room for tightening.

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 complexity (three outcomes, LLM gating, versioning, component linking) and existing output schema, description covers all necessary behavioral and failure modes comprehensively.

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%; description adds meaning beyond schema for component_ids (links to components, multi-component assets), security_properties (default 'C'), and description (feeds factor-reasoning prompt). Does not describe server_version, but that is minor.

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?

Clearly states 'Add a new asset to a threat model' with specific verb and resource. Distinguishes from siblings like edit_asset, remove_asset, restore_asset by outlining unique outcomes (normal create, auto-restore, rejection).

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?

Explains when to use (add asset) and notes post-create override via edit_asset with change_reason. Mentions LLM-gating against re-add of soft-deleted assets. Could improve by explicitly stating limitations or when not to use, but context is adequate.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mipiti/mipiti-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server