Threat Modeling MCP Server

Overview Schema Source Related Servers Discussions Admin

manage_system_context

Manage Phase 1 business context and classification profiles for threat modeling across business, software, data assets, personas, and NFRs. Set, validate, retrieve, update, list, or clear records.

Instructions

Manage all Phase 1 business context and classification profiles.

Start with action="describe" to get the payload contract without loading every taxonomy field into this tool schema. A complete Phase 1 context can be submitted in one call with action="set", section="all". Values are checked by the canonical enum validators and Pydantic profile models.

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

Input Schema

Name	Required	Description	Default
`items`	No	Batch records for data_assets, user_personas, or nfrs
`action`	Yes	Operation: describe, plan, set, get, add, update, list, delete, validate, or clear
`values`	No	Fields for one record, or section-keyed data when setting section=all
`item_id`	No	Profile ID for one update/delete, or quality class for an NFR delete
`section`	No	Context section: business, software, data_assets, user_personas, nfrs, or all	all
`item_ids`	No	Profile IDs or NFR quality classes for a 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

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries full disclosure burden. It usefully explains why the schema is sparse (describe returns the payload contract without loading taxonomy), that a full context can be written in a single batch call, and that values are validated by canonical enums and Pydantic models. It says nothing about the destructive actions delete and clear — what gets removed, whether clear wipes an entire section, or whether either is reversible — which is a material 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?

Three sentences, front-loaded with purpose followed by the recommended workflow, with no padding. Minor jargon ("payload contract", "canonical enum validators", "Pydantic profile models") is implementation-flavored but still conveys that invalid values are rejected.

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?

For a 10-action tool with six parameters and no annotations, this is adequate but thin: the return shape is covered by the output schema, yet destructive semantics and any preconditions (required permissions, ordering constraints for add before update) are unaddressed. An agent can start correctly thanks to the describe-first instruction, but cannot predict the consequences of delete or clear.

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%, so the baseline is 3. The description's statement about submitting a complete context in one call and section-keyed values largely restates what the `section` and `values` schema fields already document, adding only a mild operational framing.

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?

"Manage all Phase 1 business context and classification profiles" names a specific domain resource and, via the action list elaboration in the schema, a concrete verb set. It distinguishes the tool from domain siblings like manage_architecture or manage_threats by scoping to Phase 1 context and classification profiles, though "Manage" itself remains generic.

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

Usage Guidelines3/5

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

The description gives explicit intra-tool workflow ("Start with action='describe'" then submit via action='set', section='all'), which is genuinely actionable. However, it offers no guidance on when to use this tool rather than the sibling domain tools, and no guidance on when delete/clear/validate actions are appropriate versus add/update.

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

Deploy Server