Professional threat modeling server using the STRIDE methodology. Provides frameworks, rubrics, and templates for security threat analysis through threat modeling tools.
This STRIDE threat modeling MCP server demonstrates solid foundational work with consistent naming patterns and reasonable schema definitions. However, it has several moderate issues that prevent a higher score: (1) Parameter descriptions lack actionable constraint documentation (min/max, regex patterns, valid value enums); (2) Output schemas are largely undocumented, tools return complex nested objects but the response structure is not explicitly declared to clients; (3) Error handling is absent, no guidance for when operations fail or input is invalid; (4) Some tools appear to be framework/template providers rather than actionable tools that perform analysis, which blurs the agent-executable boundary; (5) Tool descriptions are generic and lack the 'WHEN to call this' context that helps LLMs disambiguate during planning.
Provide DREAD scoring framework for LLM client analysis.
Create attack tree visualizations for threat modeling.
Generate security test cases for identified threats.
Provide mitigation framework for LLM client analysis.
Generate a comprehensive threat modeling report.
Get guidance for analyzing a code repository for security threats.
Provide STRIDE threat modeling framework for LLM client analysis.
Output schemas are not documented. All 8 tools return complex nested objects (dicts with multiple keys like 'stride_framework', 'mitigation_framework', etc.) but the response structure is only visible by reading the implementation code. LLM clients cannot see expected fields, types, or nesting without inspecting the source.
Parameter constraints are missing or undocumented. Enum values (e.g., 'priority_filter' in generate_threat_mitigations accepts 'all|high|medium|low') are mentioned in descriptions as free text, not declared as enum constraints in the schema. String lengths, numeric ranges, and required vs optional status are not explicit.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 15 | - | v1 |
Validate that threat modeling coverage is complete.
Complex nested input objects (threat_model, threat_context, scoring_guidance) lack schema documentation. When a parameter is type 'object', the LLM needs to know the required/optional fields and their types. Current descriptions are vague ('details about the threats to test') without specifying the object structure.
No error handling or recovery guidance. None of the tools document what happens when inputs are invalid, malformed, or missing. No guidance on retryable vs fatal errors, or suggestions for correcting invalid input.
Tools appear to be framework/template providers rather than actionable tools. Most tools return static templates, rubrics, or guidance structures for the LLM client to populate. The boundary between 'tool that provides a framework' (passive reference) and 'tool that performs analysis' (active computation) is blurred, making LLM tool selection ambiguous.
Generic descriptions lack WHEN/WHY context. Tool descriptions explain WHAT but not WHEN to call them or how they differ from similar tools. For example, get_stride_threat_framework and generate_threat_report both seem to produce threat modeling output, but the description does not explain when to use each.