Skip to main content
Glama

sim_reroll

Destructive

Re-run a stored sim_prompt against the SAME parent it originally ran against — a sibling attempt, never a chain: it never derives from the previous attempt's output, only from the original parent, so rerolling ten times leaves ten independent siblings in lineage rather than a chain of ten. Reuses the original prompt's text and system unless you override them here; a prompt with no requestTemplate (stored before sim_prompt said a stored prompt is readable by anyone with its id) has them withheld from every read, so only its author (its lineage's wasAttributedTo) may reroll it reusing them, and anyone else passes text, and system when it has one, of their own. The parent rides along as sim_prompt sends it, withheld fields left out unless you are its author. The original prompt and its result are left untouched; this stores a new prompt and a new result (model or artifact, same rule as sim_prompt) under Activity sim_reroll, and returns the same fields sim_prompt does: a model's warnings, an artifact's content inline, and modelErrors when the reply was model JSON that failed. When called with neither override and the deployment's LLM provider and model are unchanged since the original ran, the response carries a reproducibility field. If the request template (the instruction and settings sim_prompt sends; a prompt's requestTemplate) is unchanged too, it is checked against every prior result this exact prompt has ever produced (via the same forward "produced" relation sim_edges/sim_neighbors can query directly): "verified" if this result content-matches one of them, "diverged" if it doesn't, "not verified" if there's no prior result on record yet. If the template changed since the original ran, it is "not comparable", and the run is stored under a new promptId. Needs sign-in (opens OAuth the first time). Refused if this deployment has no LLM provider configured. The new prompt is readable as sim_prompt's is: without sign-in, by anyone with its id or a result's.

Input Schema

NameRequiredDescriptionDefault
textNooverride the original prompt's text; default reuses it verbatim
promptYesid of the sim_prompt (or earlier sim_reroll) to re-run
systemNooverride the original prompt's system text; default reuses it verbatim

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Against annotations that already flag destructiveHint/idempotentHint, the description adds substantial context: it stores a new prompt and result, leaves the original untouched, requires sign-in via OAuth, is refused when no LLM provider is configured, exposes a reproducibility field, and reports verified/diverged/not verified/not comparable semantics. This is well beyond what the annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core sibling-vs-chain idea is front-loaded, which is good, but the single block is dense with nested parentheticals and run-on clauses that hurt scannability. For a 3-parameter tool the length is disproportionate.

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?

Given no output schema, the description responsibly enumerates the return shape (warnings, inline artifact content, modelErrors, reproducibility, verification status). Auth and refusal conditions are covered. A few referenced concepts are deferred to sim_prompt rather than spelled out, keeping it just short of complete.

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 100%, so the baseline is 3, but the description adds real meaning: overrides default to verbatim reuse, and non-authors are forced to supply their own text/system when fields are withheld. That permission-driven semantics is not present in the schema.

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?

States a specific verb+resource ('re-run a stored sim_prompt') and immediately distinguishes the behavior from a chain by defining it as a sibling attempt against the original parent. The distinction from sim_prompt (which creates the original) is inferable but the description never names sim_prompt as the alternative verb, so it falls short of a clean 5.

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

Usage Guidelines4/5

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

Gives usable conditions: reuse vs override text/system, and the rule that only a prompt's author may reroll when the requestTemplate is withheld, while others must supply their own text/system. It stops short of explicitly saying 'use sim_prompt instead when you want a fresh lineage' — the routing to the sibling is left implicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources