Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Assign To Components

assign_to_components

Replaces a control's or asset's component scope, linking security boundaries to code repositories so scoped entities are visible to the relevant coding agents.

Instructions

Replace an asset's or a control's component scope. Mutating.

Components are the canonical bridge between security architecture (trust boundaries) and code organization (repos). target_type selects what is being scoped:

"control" — replace a control's component scope. A control scoped to one or more components is visible to coding agents working in those repos (matched via Component.repo_url + Component.path); an unscoped control is visible everywhere. Use when wiring a previously unscoped control to the component(s) that implement it, adding a second component to a cross-cutting control (e.g. "all microservices enforce JWT validation"), or correcting a wrong assignment. target_id is the control ID (e.g. "CTRL-03").
"asset" — replace an asset's component scope. Linking assets to components flows boundary context into reachability derivation without giving Asset its own trust_boundary_ids. Multi-component is the right shape for a multi-instance asset (e.g., a session token on client + cache + DB — each component handles a distinct instance). target_id is the asset ID (e.g. "A1").

Both variants are mechanical / non-AI-gated and validate only that every referenced component exists on the model. An asset's answer carries the model's id, version and title, and entities.assets the asset as it now stands.

Input Schema

Name	Required	Description
`model_id`	Yes	ID of the threat model.
`target_id`	Yes	ID of the asset or control to scope (must match ``target_type``).
`target_type`	Yes	Either "asset" or "control" — which entity to scope.
`change_reason`	Yes	Why this scope is appropriate (min 10 chars). Captured in the version history.
`component_ids`	Yes	Comma-separated component IDs (e.g., "CMP1,CMP2"). Empty string = unscoped (a control becomes visible to every coding agent; an asset loses its explicit code-ownership binding). Every supplied ID must exist on the model.
`server_version`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.68.2Aug 22, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the burden well: it declares the operation mutating, explains that it replaces scope wholesale, notes both variants are 'mechanical / non-AI-gated' and validate only that components exist, and spells out the empty-string unscoped consequence. It stops short of stating permission requirements or reversibility beyond the mention of version history in the schema.

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 mutation and replace semantics are front-loaded, and the per-variant bullets are well organized. It is on the long side and some of the empty-string/unscoped detail duplicates the schema's component_ids description, but nearly every sentence carries scope semantics an agent would otherwise have to infer.

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 6-parameter mutation tool with no annotations, this covers the important ground: replacement semantics, validation limits, unscoped behavior, and target_type branching. An output schema exists, so the brief return-value note is optional rather than required. Preconditions (e.g., target must exist on the model) are only implied.

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 83%, so the schema already documents most parameters. The description adds real value beyond it: target_id examples ('CTRL-03', 'A1'), the meaning of target_type per branch, and the visibility consequences of component scoping. It does not restate component_ids syntax, but it doesn't need to.

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 ('Replace an asset's or a control's component scope') and flags it as mutating up front. The target_type enumeration makes the two operating modes explicit, so an agent can distinguish this from add_component/edit_component without reading the schema.

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?

Gives concrete when-to-use conditions per variant: wiring a previously unscoped control, adding a second component to a cross-cutting control, correcting a wrong assignment, and multi-instance assets. It also states the replacement (not additive) semantics, which is the key usage trap.

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

Deploy Server