Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Import Controls

import_controls

Import existing security controls into a threat model from JSON or free-text, with automatic mapping and deduplication, plus a confirmation step before saving.

Instructions

Import existing security controls into a threat model.

Accepts structured JSON or free-text. Controls are auto-mapped to COs and deduplicated against existing ones. The parse/map/dedup runs as a background job (polled for progress), then — because this mutates the model — you are asked to confirm before the controls are saved.

Input Schema

TableJSON Schema

Name	Required	Description
`auto_map`	No	Auto-map controls to COs using LLM (default: True).
`model_id`	Yes	ID of the threat model.
`free_text`	No	Free-text controls (narrative/CSV/bullets).
`source_label`	No	Origin label (e.g., "ISO 27001").
`controls_json`	No	JSON array of {description, co_ids?, framework_refs?}.
`server_version`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.62.2Jul 22, 2026
Removedv0.62.1Jul 17, 2026
First observedv0.57.0Jul 8, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full burden of behavioral disclosure and does so exceptionally well. It explicitly mentions the background job with polling for progress, mutation of the model, and a confirmation step before controls are saved. It also discloses auto-mapping and deduplication behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no filler. The main purpose is front-loaded, followed by input format, background execution, and confirmation behavior. Every sentence adds operational value.

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 the tool's complexity—background jobs, progress polling, auto-mapping, deduplication, and confirmation—the description covers all critical operational aspects. An output schema exists, so return-value details are not needed in the description. The only minor omission is expanding 'COs', but the schema's co_ids and the sibling context make it recoverable.

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

Parameters3/5

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

Schema description coverage is high at 83%, so the baseline is 3. The description adds some context connecting 'structured JSON or free-text' to the controls_json and free_text parameters, but the schema already documents those parameters well. It does not clarify the undocumented server_version parameter, but the description is not required to compensate heavily given high schema coverage.

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?

The description opens with a specific verb and resource: 'Import existing security controls into a threat model.' It further distinguishes this from sibling import tools by mentioning structured JSON/free-text input, auto-mapping to COs, and deduplication against existing controls. 'COs' is a domain abbreviation, but the overall purpose is unmistakable.

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 clearly states the use case: importing existing security controls into a threat model, with structured JSON or free-text as input. It does not explicitly name alternatives or say when not to use this tool, but the context is strong enough that an agent can infer when this tool is appropriate.

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

Deploy Server