Skip to main content
Glama
Mipiti
by Mipiti

retry_verdicts

Retry parked verdict re-evaluations after transient failures such as provider outages or timeouts. Re-runs only the failed verification slots without changing assertions, controls, or verdict content.

Instructions

Re-trigger a model's parked verdict re-evals after a transient failure.

When a verdict re-evaluation fails transiently — a provider outage, exhausted credits, or a timeout — it is parked and reads as "unavailable / treated as unverified", recovering only after a delay. This forces an immediate, non-destructive re-run of ONLY the parked/failed re-eval slots, across every verdict kind (coverage, group-sufficiency, per-control sufficiency, coherence). It changes no assertions, controls, or verdict content, so no IDs churn. Evaluation runs in the background — re-read the sufficiency or verification report shortly after to see updated verdicts.

Prefer this over recompute_verdicts when verdicts are stuck due to an outage: recompute_verdicts force-enqueues coverage + group-sufficiency for the whole model (metered per its estimate) and cannot un-park a job whose inputs are unchanged, whereas this re-arms exactly the failed slots and covers per-control sufficiency + coherence too.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYesID of the threat model whose parked verdicts to retry.
server_versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

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, and it excels: it states the operation is non-destructive, changes no assertions/controls/verdict content, causes no ID churn, runs in the background, and covers all verdict kinds. This gives the agent a clear, trustworthy behavioral model.

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 every sentence adds value: it explains the failure scenario, the effect, the scope, the non-destructive nature, the background execution, and the distinction from recompute_verdicts. It is dense with useful content, though it could be trimmed slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool's behavior, scope, and follow-up recommendations are thoroughly described, and an output schema exists to cover return values. The only notable completeness gap is the ambiguous server_version parameter, but overall the description is nearly sufficient for an agent to invoke the tool correctly.

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?

The schema describes model_id, but server_version has no description and the description text does not compensate for it. Schema description coverage is only 50%, and the description adds no parameter-specific guidance, leaving server_version ambiguous and underspecified.

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 opens with a specific verb and resource: 'Re-trigger a model's parked verdict re-evals after a transient failure.' It clearly distinguishes this tool from recompute_verdicts, which is its closest sibling and does something materially different.

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?

Provides explicit usage criteria: use when a re-eval fails transiently (provider outage, exhausted credits, timeout). It also states when to prefer this over recompute_verdicts and explains why recompute_verdicts is not suitable for un-parking failed jobs. This is model behavior for usage guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mipiti/mipiti-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server