Skip to main content
Glama
Sign In
Threat Modeling MCP Server

Threat Modeling MCP Server

by residentevilrenz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

manage_trust_boundaries

Manage trust zones, crossing points, and boundaries to identify where actors and data cross security perimeters, supporting threat analysis and detection planning.

Instructions

Manage zones, crossing points, boundaries, and their relationships.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "manage_trust_boundaries"
  }
}

Input Schema

NameRequiredDescriptionDefault
itemsNoBatch records for add, update, or supported link operations
actionYesOperation: describe, analysis_plan, detection_plan, add, update, list, get, delete, link, unlink, or clear
valuesNoFields for one record, relationship, or optional list filters
item_idNoRecord ID for one get, update, or delete
sectionNoTrust section: zones, crossing_points, boundaries, or allall
item_idsNoRecord IDs for batch delete

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.5/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. It never mentions that 'delete' and 'clear' are destructive and irreversible, what permissions are required, or how link/unlink relationships behave, leaving an agent to guess at the riskiest operations.

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?

It is a single front-loaded sentence with no filler, which is structurally clean. The problem is under-specification rather than verbosity: the one sentence omits the operation model that the eleven-action enum actually implies.

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

Completeness2/5

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

For a tool with six parameters, eleven supported actions including destructive ones, and no annotations, a single vague sentence is not enough. The output schema does relieve the need to describe return values, but the destructive-action semantics and action-specific parameter usage remain entirely unexplained.

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 100% and all six parameters, including the eleven-value action enum and the section enum, are documented in the schema itself. The description adds no syntax, format, or interaction details (e.g., how items and item_ids interact with action), so the baseline 3 applies.

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

Purpose3/5

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

The description names the resource domain (zones, crossing points, boundaries, and their relationships), which does help an agent tell this apart from domain siblings like manage_architecture or manage_threats. However, the verb is the generic 'Manage', and it never states what operations are performed or how it differs from other manage_* tools beyond subject matter.

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 guidance on when to use this tool versus alternatives, and no mention of prerequisites or sequencing (e.g., when to use link vs add, or when section='all' is appropriate). The agent must infer everything from the action enum in the schema.

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