Threat Modeling MCP Server

Overview Schema Source Related Servers Discussions Admin

manage_architecture

Create, update, list, and delete architecture components, connections, and data stores to document system structure for threat modeling.

Instructions

Manage architecture components, connections, and data stores.

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_architecture"
  }
}

Input Schema

Name	Required	Description	Default
`items`	No	Batch records for add or update
`action`	Yes	Operation: describe, plan, add, update, list, delete, or clear
`values`	No	Fields for one record or optional list filters
`item_id`	No	Record ID for one update or delete
`section`	No	Architecture section: components, connections, data_stores, or all	all
`item_ids`	No	Record IDs for batch delete

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 14, 2026

TDQS

C2.8/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 disclosure burden, and it discloses almost nothing. It does not say that 'delete' and 'clear' are destructive or irreversible, whether 'clear' wipes an entire section, whether 'add' can batch via items, or whether prerequisites exist (e.g., needing a system context first). For a tool whose schema contains two clearly destructive actions, this is a substantial gap.

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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though its terseness borders on under-specification for a multi-action mutation tool, which is penalized under contextual completeness rather than here.

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?

This is judged too weak: the tool exposes seven actions, two of them destructive, with no annotations and no per-action explanation, and the description never clarifies that 'describe' and 'plan' are read-only while 'delete'/'clear' mutate state. An output schema exists, so return values need not be described, but the action-level behavioral contract is missing entirely.

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 each parameter has an inline description, including enums for action and section, so the schema already does the semantic work. The description adds nothing about batching (items/item_ids), the interplay between action and section, or defaults. Baseline 3 applies when the schema fully documents parameters.

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 domain objects (architecture components, connections, data stores) and the verb 'manage', which distinguishes it from siblings like manage_threats or manage_asset_flows. However, 'manage' is a generic umbrella verb that does not convey the actual operation space — the schema reveals seven distinct actions including destructive ones, none of which is hinted at in the description.

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 the many sibling tools, nor any indication of which action to pick for which intent. The description neither states prerequisites nor excludes any scenarios, leaving the agent to reverse-engineer usage from the enum values alone.

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

Deploy Server