UML Forge

Overview Schema Source Related Servers Discussions Admin

umlforge_threat_model

Read-only

Generate a STRIDE threat model to identify security gaps before launch, map auth flows and trust boundaries, and document risks for audits or penetration tests.

Instructions

Generate a full STRIDE security threat model for a system.

USE THIS WHEN:

You want to identify security vulnerabilities before launch
You need to document auth flows, trust boundaries, or sensitive data handling
You are preparing for a penetration test or compliance audit (GDPR, SOC2, PCI-DSS)

NOT FOR:

General architecture review → use umlforge_reverse_engineer with report_mode=True
Deployment and infrastructure topology → use umlforge_deployment
API flow design (without security focus) → use umlforge_api_sequence

Produces:

Auth flow sequence diagram: all failure paths, trust boundary annotations
Data flow diagram: sensitivity labels (PUBLIC / INTERNAL / CONFIDENTIAL / SECRET)
STRIDE threat table: all 6 categories with likelihood, mitigation, status
Critical flags (🚨) for high-risk gaps
(report_mode=True) Security Assessment Report: threat landscape, critical vulnerability deep-dives, compliance status, remediation roadmap, risk score

Args: system_description: What the system does, how users access it, main components. auth_mechanism: Auth in use (e.g. "JWT Bearer token", "API Key", "OAuth2 + PKCE"). trust_boundaries: Boundary crossings (e.g. ["public internet → API", "API → database"]) (optional). sensitive_data: Sensitive data types (e.g. ["user emails", "payment tokens"]) (optional). compliance_framework: Compliance scope (e.g. "GDPR", "NDPA 2023", "PCI-DSS") (optional). report_mode: True → also produce a Security Assessment Report. Pro/Team/Enterprise only. Omit to use your saved account preference (dashboard toggle); False forces diagrams only.

Input Schema

Name	Required	Description	Default
`report_mode`	No
`auth_mechanism`	Yes
`sensitive_data`	No
`trust_boundaries`	No
`system_description`	Yes
`compliance_framework`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.3.0Oct 16, 2026
- addedInput schema / properties / report_mode / anyOf
```
Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]
```
- changedInput schema / properties / report_mode / default
```
Previous value: -falseNew value: +null
```
- removedInput schema / properties / report_mode / type
```
Removed value: -"boolean"
```
Addedv0.2.0Sep 4, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds non-obvious behavior the annotations do not: report_mode is Pro/Team/Enterprise-only, and omitting it falls back to a saved account preference while False forces diagrams-only. It does not mention latency, size limits, or whether generated artifacts persist, so it stops short of a 5. Generating an artifact under readOnlyHint=true is consistent with "does not mutate the described system" semantics rather than a contradiction.

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?

Headers (USE THIS WHEN, NOT FOR, Produces, Args) front-load routing information and the ordering is logical. The "Produces" block partly restates what the output schema already covers, making it slightly longer than strictly necessary, but nothing is padded or redundant enough to hurt.

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

Completeness5/5

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

For a six-parameter generative tool with a rich output schema, the description covers routing, exclusions, parameter examples, tier constraints, and default-resolution behavior. An agent has everything needed to select and invoke it correctly without consulting siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden and does: it documents all six parameters with concrete examples ("JWT Bearer token", ["public internet → API", "API → database"], "NDPA 2023") and marks the four optional ones. It also explains report_mode's tri-state semantics (True / omit / False) and tier gating, which the bare boolean|null schema cannot convey.

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?

StartsWith a specific verb+resource+methodology ("Generate a full STRIDE security threat model for a system"), leaving no ambiguity about what the tool returns. It also explicitly names the sibling tools it is not (umlforge_reverse_engineer, umlforge_deployment, umlforge_api_sequence), so an agent can disambiguate without opening other schemas.

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?

The USE THIS WHEN / NOT FOR structure gives explicit triggers, explicit exclusions, and a named alternative for each exclusion (e.g. architecture review → umlforge_reverse_engineer with report_mode=True). This is the strongest possible routing guidance.

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

Deploy Server