Skip to main content
Glama
Sign In
Mipiti MCP Server

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Reevaluate Threat Model Factors

reevaluate_threat_model_factors

Re-rate LLM factor judgments for a threat model's live assets and attackers—all, named IDs, unrated, or stale—without regenerating the model or losing controls.

Instructions

Re-run the LLM factor judgment on a model's live assets and attackers: every one, those entity_ids names, only those nobody rated (unrated_only), or only those whose rating was made for another description of the system (stale_only, an entity's rating_stale; with both flags, either). With entity_ids a flag narrows to those named. The review queue's rating_stale row names the request that re-rates its entities. Re-baselines factors after a bug fix or description change, or rates what reads "not rated", without regenerating the model (which would destroy controls, assertions, components). One call per entity in scope, at your cost; an id naming no live asset or attacker is refused (400) before any call; a scope naming none makes no call.

A rating a model made is replaced with a fresh decomposition and its impact / likelihood re-derived from it. A rating a person chose is never replaced: the answer is held pending beside it (rating_pending on get_entity), the more severe of the two in force, until someone settles them with settle_entity_rating. Each re-rating is a rating revision recorded with change_reason (default "LLM factor re-evaluation"), told apart from overrides made with edit_asset / edit_attacker. The judgment is a starting point: layer deployment-specific factors on top with those, and a change_reason saying why.

Per-entity soft-fail: a failure on one entity lands in failed_entities (id, kind, reason) and the rest still persist; 503 only when every entity in scope failed, with nothing persisted. Soft-deleted entities are skipped.

Re-ratings keep the model version, except where an answer changes an attacker's attack_vector or privileges_required: reachability reads both, so the run saves one new version carrying every answer, and a proposal reviewed before it reads review_stale. Privileges a person attested, or that what the attacker holds gives, are no rating's: an answer never moves them.

Input Schema

NameRequiredDescriptionDefault
model_idYesID of the threat model to re-rate.
entity_idsNoOptional comma-separated asset and attacker ids (e.g. "A-03,T-14"); omit for every live entity.
stale_onlyNoOnly entities rated for another description. Default False.
unrated_onlyNoOnly entities whose ``rating_source`` is ``unrated``. Default False.
change_reasonNoOptional audit-trail reason (default "LLM factor re-evaluation").
server_versionYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.100.0
    • addedInput schema / properties / stale_only
      Added value: +{
+  "default": false,
+  "description": "Only entities rated for another description. Default\nFalse.",
+  "type": "boolean"
+}
  2. Changed3 schema fields changedv0.91.0
    • changedInput schema / properties / change_reason / description
      Previous value: -"Optional override of the audit-trail reason\n(default: \"LLM factor re-evaluation\"). Use this to thread\na higher-level reason like \"Re-eval after refinement bug\nfix shipped in vN.N.N\" when running the tool as part of a\nbroader workflow."New value: +"Optional audit-trail reason (default \"LLM factor\nre-evaluation\")."
    • addedInput schema / properties / entity_ids
      Added value: +{
+  "default": "",
+  "description": "Optional comma-separated asset and attacker ids (e.g.\n\"A-03,T-14\"); omit for every live entity.",
+  "type": "string"
+}
    • addedInput schema / properties / unrated_only
      Added value: +{
+  "default": false,
+  "description": "Only entities whose ``rating_source`` is\n``unrated``. Default False.",
+  "type": "boolean"
+}
  3. Addedv0.62.2
  4. Removedv0.62.1
  5. First observedv0.57.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does: cost model ("one call per entity in scope, at your cost"), pre-flight validation (400 on an id naming no live entity, no call made), soft-fail semantics with failed_entities and 503 only when all fail, soft-deleted entities skipped, and conditional version bumping when attack_vector or privileges_required change. It also discloses that human-chosen ratings are never overwritten but held as rating_pending with the more severe value in force, which is critical and non-obvious behavior.

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?

The core action and scope modes are front-loaded, followed by consequences, then edge cases — a sensible ordering. It is dense but nearly every sentence carries operational information (cost, 400, soft-fail, version bump, pending ratings); only a few phrasings could be tightened without losing meaning.

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 6-parameter mutation whose output schema already covers return values, the description supplies everything else an agent needs: scoping rules, cost, error contracts, partial-failure shape, versioning side effects, and the human-rating conflict path. Nothing material is left to inference.

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

Parameters4/5

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

Schema coverage is 83%, so the baseline is 3, but the description adds genuine meaning the schema does not: how entity_ids interacts with the flags ("With entity_ids a flag narrows to those named"), and that stale_only + unrated_only together mean either. It also explains rating_stale and the 'not rated' reading behind unrated_only, and the default change_reason string.

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?

Opens with a specific verb + resource + scope: "Re-run the LLM factor judgment on a model's live assets and attackers," then enumerates the three scope modes. An agent can tell this apart from sibling mutations like refine_threat_model, regenerate_controls, or edit_asset without opening any schema.

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?

Explicitly states when to use it ("Re-baselines factors after a bug fix or description change, or rates what reads 'not rated'" from the review queue's rating_stale row) and what not to use instead ("without regenerating the model (which would destroy controls, assertions, components)"). It also routes to the correct siblings: settle_entity_rating for pending human ratings and edit_asset/edit_attacker for layering deployment-specific factors.

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