Skip to main content
Glama

sim_migration_offers

Destructive

List what happens to the edges of a superseded model. Taxonomic edges (hasMember, @type, broader, related, closeMatch, cites, about) are OFFERED: each row gives the edge as it would read on the model's current successor (followed through its supersession chain), whether sim_link's checks pass for it now (passes, refused, or unchecked when the store could not answer), any earlier migrations of it, and the sim_accept_migration call that accepts it. Nothing moves automatically, the old edge stays, and this read writes nothing: offers are computed on read and never stored. Tool-written edges (from/to/feeds, produced, supersededBy), structural edges (isomorphicTo, subnetOf, preservesInvariant, refines) and legacy unregistered predicates STAY with the old model, each with its reason; a structural row names its witnesses and the sim_prove call that would make a new edge for the successor. Stored systems naming the model are listed under systems (sim_system {naming}'s answer, at most 100 rows): a System names exact ids, so supersession changes none of them, and systemsNote names the sim_create_system call with the successor. A chain that cycles, runs past 64 hops, ends at a deleted model or reaches a model now owned by someone else is reported as such, with no target. Accepting needs you to own the superseded model or to have authored the edge, and the edge it becomes must pass its predicate's write rule for you, as sim_link would (hasMember: you own the collection); youMayAccept says whether you may, per edge, and writeRule says why not when only the write rule refuses. 100 edges per page (pass next as after); predicate narrows to one stored predicate (narrower is refused: pass broader). Needs sign-in with read scope (opens OAuth the first time); anonymous over HTTP as GET /api/models/{id}/migrations, with no youMayAccept. Costs 1 compute token per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
afterNothe next value a previous call returned, for the following page
modelYescontent id of the superseded model
predicateNoread only this predicate's edges

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior1/5

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

The annotations declare readOnlyHint=false and destructiveHint=true, but the description asserts 'Nothing moves automatically... this read writes nothing: offers are computed on read and never stored.' That is a direct, serious inconsistency about whether the tool mutates state or destroys anything. Per the rubric this contradiction forces the lowest score despite the otherwise rich behavioral detail (pagination, auth, cost, cycle/hop limits).

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?

It is long and written as a single dense block, but it is front-loaded with the core distinction (offered vs stays) and proceeds in topical order: offered edges, staying edges, systems, error cases, permissions, pagination, auth, cost. Almost every clause carries information; the length is justified by the tool's complexity, though line breaks would improve scanability.

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 no output schema and unreliable annotations, the description covers what a caller needs: the shape of each row class, per-edge fields (passes/refused/unchecked, youMayAccept, writeRule), pagination, auth scopes, anonymous HTTP access, cost, and the cycle/hop/ownership failure modes. Nothing material about invoking it correctly is missing.

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 earns above that by adding real semantics: 'after' is the next token from a previous call (100 edges per page), 'predicate' narrows to one stored predicate and a narrower predicate is refused so you must pass broader, and 'model' must be the superseded model. This genuinely enriches the terse schema descriptions.

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?

States a specific verb and resource — listing what happens to the edges of a superseded model — and immediately differentiates the two edge classes (taxonomic edges OFFERED vs tool-written/structural/legacy edges STAYING). An agent can tell it apart from siblings like sim_edges, sim_accept_migration, or sim_supersede_model 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 Guidelines4/5

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

It routes the agent to the right follow-up tools: sim_accept_migration to accept an offer, sim_prove to generate a structural successor edge, sim_system/sim_create_system for naming systems. It also states the preconditions for accepting (you own the superseded model or authored the edge, plus the predicate write rule). It stops short of an explicit 'call this before/never instead of X' framing, so it is slightly more context than explicit when-to-use guidance.

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