Skip to main content
Glama
Mipiti
by Mipiti

Revalidate Entity Quality

revalidate_entity_quality

Re-validates existing threat model entities to clear stale quality warnings or apply validation improvements without regenerating the model, then saves a new version preserving controls.

Instructions

Re-run quality validation on a threat model's existing assets and attackers, as if they were freshly generated. A fast first-pass check judges every entity; only the ones it flags get a deeper review that confirms them, sharpens their wording, or flags them for you.

Use this to apply validation improvements to an already-generated model, or to clear stale quality warnings — without regenerating the whole model (which would destroy controls, assertions, and components). It is non-destructive: an entity that should be removed is left in place with a quality warning rather than deleted, so no control objective loses its asset or attacker anchor. The result is saved as a new model version; controls and control objectives carry forward.

May consume credits for the entities that need the deeper review; a model already in good shape costs nothing. Returns the updated model envelope: {"accepted": true, "model": {...}}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYesID of the threat model whose assets and attackers to re-validate.
server_versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.68.2

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the operation is non-destructive, explains what happens to flagged entities ('left in place with a quality warning'), notes the result is saved as a new model version, mentions controls carry forward, and discloses credit consumption. This is strong behavioral transparency.

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 description is longer than average but well structured: it front-loads the core re-validation behavior, then covers usage intent, non-destructive behavior, side effects, costs, and return format. Each sentence provides useful information, though it could be tightened slightly without losing key context.

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 tool with two required parameters, no annotations, and several behavioral nuances, the description is complete. It explains the two-phase validation, what happens to flagged entities, persistence behavior, credit implications, and the output envelope. The presence of an output schema further reduces the burden of documenting return values.

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

Parameters2/5

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

Schema description coverage is only 50% because 'server_version' has no schema description and the tool description does not clarify it either. While 'model_id' is self-explanatory in the schema, the description adds no parameter-level meaning beyond the operation-level context, leaving a required parameter ambiguous.

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?

The description states a specific verb and resource: 'Re-run quality validation on a threat model's existing assets and attackers'. It also distinguishes this from regenerating the whole model by emphasizing it works on existing entities without regeneration, making its unique role clear even among many sibling tools.

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 description explicitly states when to use this tool: 'to apply validation improvements to an already-generated model, or to clear stale quality warnings'. It also names the avoided alternative — regenerating the whole model — and explains why that is worse, stating it would destroy controls, assertions, and components.

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