Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Add Trust Boundary

add_trust_boundary

Add a trust boundary to a threat model to create a new model version and define allowed attack vectors, sealed zones, and crossing assets for reachability analysis.

Instructions

Add a trust boundary. Creates a new model version. Returns {model, entities, ...}: the model's id, version and title, and entities.trust_boundaries the boundary as created.

Input Schema

NameRequiredDescriptionDefault
passesNoOptional comma-separated AttackVector values the boundary allows through (subset of "Network,Adjacent,Local,Physical"). Omit for the methodology default (passes-everything). Narrowing this set is what makes a boundary block specific attacker vectors in the deterministic reachability composer.
sealedNoOptional. Set True to declare the boundary has NO lateral ingress — the only way into its zone is crossing the perimeter (an air-gap / network-segmented enclave). On its own this is a suggestion: only an ATTESTED seal lets reachability decisively rule an asset unreachable instead of indeterminate, and the attestation is recorded with ``edit_trust_boundary`` (``seal_source="attested"`` with a ``change_reason``), by a person or a program the workspace delegates ``seal_attested`` to. Default False (assume a lateral pivot is possible). Set it only when the isolation is real and attestable.
crossesNoOptional comma-separated asset IDs that cross this boundary.
model_idYesID of the threat model.
descriptionYesWhat this boundary represents (e.g., "Public network to API server").
server_versionYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.87.0
    • changedInput schema / properties / sealed / description
      Previous value: -"Optional. Set True to declare the boundary has NO lateral\ningress — the only way into its zone is crossing the perimeter\n(an air-gap / network-segmented enclave). On its own this is a\nsuggestion: only an ATTESTED seal lets reachability decisively\nrule an asset unreachable instead of indeterminate, and the\nattestation is recorded with ``edit_trust_boundary``\n(``seal_source=\"attested\"`` with a ``change_reason``). Default\nFalse (assume a lateral pivot is possible). Set it only when the\nisolation is real and attestable."New value: +"Optional. Set True to declare the boundary has NO lateral\ningress — the only way into its zone is crossing the perimeter\n(an air-gap / network-segmented enclave). On its own this is a\nsuggestion: only an ATTESTED seal lets reachability decisively\nrule an asset unreachable instead of indeterminate, and the\nattestation is recorded with ``edit_trust_boundary``\n(``seal_source=\"attested\"`` with a ``change_reason``), by a\nperson or a program the workspace delegates ``seal_attested``\nto. Default False (assume a lateral pivot is possible). Set it\nonly when the isolation is real and attestable."
  2. Changed1 schema field changedv0.77.0
    • changedInput schema / properties / sealed / description
      Previous value: -"Optional. Set True to declare the boundary has NO lateral\ningress — the only way into its zone is crossing the perimeter\n(an air-gap / network-segmented enclave). A sealed boundary that\nblocks the attacker's vector lets reachability decisively rule the\nasset unreachable instead of indeterminate. Default False (assume a\nlateral pivot is possible). Set it only when the isolation is real\nand attestable."New value: +"Optional. Set True to declare the boundary has NO lateral\ningress — the only way into its zone is crossing the perimeter\n(an air-gap / network-segmented enclave). On its own this is a\nsuggestion: only an ATTESTED seal lets reachability decisively\nrule an asset unreachable instead of indeterminate, and the\nattestation is recorded with ``edit_trust_boundary``\n(``seal_source=\"attested\"`` with a ``change_reason``). Default\nFalse (assume a lateral pivot is possible). Set it only when the\nisolation is real and attestable."
  3. Addedv0.62.1
  4. Removedv0.62.0
  5. First observedv0.57.0

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It does disclose two non-obvious trait-level facts: the call mutates by creating a new model version, and the return shape. However it says nothing about permission/attestation requirements for the call itself or failure modes; the deeper sealed/attestation semantics live in the schema, not the description.

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?

Three short sentences, front-loaded with the action and versioning side effect. The return-shape sentence is somewhat redundant given an output schema exists, and the RST-style backtick quoting is slightly noisy, but overall tight.

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

Completeness3/5

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

An output schema exists, so spelling out the return value is unnecessary duplication. For a 6-parameter mutation tool with no annotations, the description is adequate but thin on when-to-use, prerequisites, and the relationship to edit_trust_boundary, leaving gaps an agent must infer.

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 83%, so the schema already documents passes, sealed, crosses, model_id, and description in detail. The description adds no parameter-level meaning beyond the schema, which is acceptable at this coverage level.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Add a trust boundary') and adds the important side effect that it creates a new model version. The 'Add' vs sibling 'edit_trust_boundary' distinction is inferable from naming, though the description never names the sibling explicitly.

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

Usage Guidelines2/5

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

There is no statement of when to use this versus edit_trust_boundary, no prerequisites (e.g., does a model/asset need to exist first, does this require a specific role), and no exclusions. Usage is only implied by the parameter set.

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