Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Get Entity

get_entity

Retrieve a single threat model entity by type and ID—asset, attacker, component, trust boundary, or assumption—to inspect its native record and quality details.

Instructions

Get a single entity of any core type by ID. Read-only.

Dispatches on entity_type to the per-type read and returns that type's native record as-is (not wrapped in an array):

asset — the asset's typed fields. Soft-deleted assets carry deleted: true; the caller decides whether to surface them. entity_id e.g. A-01. A live asset or attacker also carries quality: the quality check's outcome (clean, advice, defect, question, invalid, or unchecked while none answers it as it stands), the warning, the proposed correction or the question, and the input_hash that apply_entity_proposals and answer_entity_question name.
attacker — the attacker with its factor decomposition, its surface_extent (unset / point / whole) and surface_extent_source, which says whether a person attested it. Soft-deleted attackers carry deleted: true. entity_id e.g. T-03.
component — the component. Speculative components (repo_url="") are returned as-is: the empty repo IS the lifecycle state, not an error. entity_id e.g. CMP-01.
trust_boundary — the boundary incl. its passes set (closed-vocabulary subset of {Network, Adjacent, Local, Physical}). entity_id e.g. TB-Net.
assumption — the assumption with its override applied (mirrors list_assumptions' merge for one entity: typed fields, the structured exclusion predicate when present, and the override layer — status / justification / linked CO IDs). Soft-deleted assumptions carry deleted: true. entity_id e.g. AS-01.

Input Schema

Name	Required	Description
`model_id`	Yes	ID of the threat model.
`entity_id`	Yes	ID of the entity to fetch.
`entity_type`	Yes	Which entity to read — one of ``asset``, ``attacker``, ``component``, ``trust_boundary``, ``assumption``.
`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.0

Behavior4/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 well: it declares read-only, states that soft-deleted records come back with deleted: true and that surfacing them is the caller's call, and warns that speculative components (repo_url="") are a lifecycle state, not an error. Missing is what happens when the ID is absent or mismatched with entity_type.

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

Conciseness3/5

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

The lead sentence is tight and front-loaded, but the five-bullet enumeration of return fields is long and partly redundant given an output schema exists. The density of per-type field detail (quality sub-fields, surface_extent_source) crowds out more actionable routing guidance.

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?

Rich on entity_type dispatch, ID formats, and soft-delete/speculative-state semantics, and an output schema covers the record shape. The remaining gap is failure behavior for missing or mismatched IDs, which an agent would want before calling.

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 75%, and the description goes well beyond it by giving concrete ID formats per type (A-01, T-03, CMP-01, TB-Net, AS-01) and spelling out what each entity_type value returns. model_id is left entirely to the schema and server_version is unexplained, keeping it short of a 5.

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 ('Get a single entity of any core type by ID'), declares it read-only, and explains the dispatch mechanism on entity_type. The per-type breakdown makes it unmistakable versus siblings like query_threat_model or list_assumptions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'by ID' and reinforced by the note that the assumption branch mirrors list_assumptions' merge for a single entity, but there is no explicit statement of when to prefer this over query_threat_model or a list tool, and no note on erroring for an unknown ID.

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

Deploy Server