Skip to main content
Glama
Mipiti
by Mipiti

Settle Entity Rating

settle_entity_rating

Settle a pending rating held for an asset or attacker when human and model ratings conflict, choosing to keep the person's rating, take the model's, or set a new one.

Instructions

Settle the rating held pending for an asset or attacker. Mutating.

A rating a person chose is never replaced by a model's: where an entity's words changed, or a re-evaluation answered over it, the model's rating is held pending beside the person's, the more severe of the two in force. get_entity serves the pair as rating_pending (the rating in force and the pending one, who chose each, the words each was made for, and pair_hash); the review queue's rating_pending row lists every such entity. Settling is a judgment (rating_reconfirmed): a program's is parked for a person (403 with an escalation_id: do not retry) unless the workspace's delegation policy names it at the entity's tier. RELAY BOTH RATINGS TO THE PERSON and settle as they choose.

choice: keep_person keeps the person's rating for the words as they stand; take_model takes the model's; set writes another, given in factors. A choice that changes an attacker's attack vector or privileges saves a new model version; any other writes a rating revision. Refused 409 stale with the current pair_hash when the pair or the entity's words moved since it was read (read it again), 409 nothing_pending when no pair is held.

Returns {entity_id, choice, version_created}.

Input Schema

NameRequiredDescriptionDefault
choiceYes``keep_person``, ``take_model`` or ``set``.
factorsNoFor ``set``: a JSON object of the rating's factors (an asset's subscores, blast radius, recoverability and regulatory scope; an attacker's attack vector, privileges required, attack complexity, user interaction and capability prevalence).
model_idYesID of the threat model.
entity_idYesThe asset or attacker (e.g. "A-03").
pair_hashYes``rating_pending.pair_hash`` as it was read.
rationaleNoFor ``set``: why the rating is what it is.
entity_kindYes``asset`` or ``attacker``.
change_reasonNoWhy it is settled so (kept with the decision).
server_versionYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.100.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses mutation, judgment semantics, 403 escalation behavior with escalation_id and 'do not retry', two distinct 409 cases (stale pair_hash and nothing_pending), and side effects (new model version for attacker vector/privilege changes vs. rating revision otherwise). It also states what happens to the person's rating and the model's held rating.

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 long but front-loaded with purpose and mutation status, then structures the explanation around reading the pair, settlement choices, side effects, and error cases. Some sentences are dense and parenthetical, but the length is largely justified for a complex mutation with no annotations.

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?

Given 9 parameters, 6 required, a complex domain, no annotations, and an output schema, the description covers the essential behavior: prerequisites, process guidance, permission escalation, stale-pair recovery, side effects, and return shape. An agent has enough information to call it correctly and handle its error paths.

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 description coverage is already high at 89%, so baseline is 3. The description adds meaningful relationships beyond the schema: it explains that choice values resolve the held pair, that pair_hash reflects the pair as read and becomes stale if the pair or entity words move, and that set writes factors. It does not add much about rationale or change_reason beyond the schema, but it substantially enriches the central choice/pair_hash semantics.

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 first two sentences state the specific verb ('Settle'), resource ('rating held pending'), and scope ('asset or attacker'), and immediately flag that it is mutating. It distinguishes itself from read-oriented siblings like get_entity and from other entity-quality tools by focusing narrowly on resolving a pending rating pair.

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 explains when a pending pair exists, points to get_entity and the review queue for reading it, specifies process expectations ('RELAY BOTH RATINGS TO THE PERSON'), and covers the escalation path for programmatic callers (403 unless delegation policy names it). It also gives behavioral alternatives for each choice value, leaving little inference needed.

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