Skip to main content
Glama

Migration loss check

wever_migration-loss-check
Read-only

Agent Migration: submit what one move loses, as recorded: each loss (history, reputation, settings, an integration, records, data, identity, funds or other) with why it is lost (no equivalent on the target, held only inside the source, not in the export, given up by choice or other), whether the plan’s loss list names it, whether the principal was told, when, and whether the principal accepted it; optionally each integration the agent uses on the source with its target equivalent, the records that exist only inside the source, and the cutover time. The signed report lists every loss with its status, counts the losses by class, lists the integrations with no equivalent and the source-only records missing from the loss list, and names losses that are undisclosed: losses that appear nowhere in the plan, including integrations with no target equivalent and records held only inside the source, and losses the principal was never told about; then losses told only after the cutover and losses the principal has not accepted, with the fix for each. This reads what an actual move loses: whether a reputation record or an identity could be carried to another platform in principle is wever_reputation-portability-check or wever_identity-portability-check. Verdict losses_undisclosed, losses_gaps, losses_unverified or losses_disclosed. POST /api/migration-loss-check. Reads only the material in the call: no network request, fetch, money movement, message, sharing, configuration change or external write, and no data is moved. Paid URL: 0.10 USDC per call on Base via x402 exact, with the shared 10 signed-wallet free calls per rolling 30 days. Bind X-Wever-Wallet-Proof to the exact JSON arguments and the tool route. Returns a report with an Ed25519 signed receipt. Contract: /api/agent-migration-contract. Human page: https://weverlabs.com/agent-migration/.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "wever_migration-loss-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNoOptional name recorded in the report.
lossesNoEach loss the move causes.
cutover_atNoWhen the switch-over happens, to read when the principal was told against it.
source_onlyNoRecords that exist only inside the source, such as platform reviews or an internal audit log.
integrationsNoEach integration on the source, with its target equivalent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the supplied readOnly/openWorld/destructive annotations, the description adds material behaviour: it enumerates what the call will not do (no network fetch, money movement, message, sharing or external write, no data moved), discloses the paid x402 pricing (0.10 USDC on Base, 10 signed-wallet free calls per rolling 30 days), requires an X-Wever-Wallet-Proof header bound to the exact JSON arguments and route, and states the return is an Ed25519 signed receipt. That is the kind of detail an agent cannot infer from annotations.

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?

Purpose is front-loaded, but the middle is a run-on that restates the same loss attributes twice and re-explains 'undisclosed' at length, then piles on endpoint, safety, pricing, auth, output and links in one block. Nothing is off-topic, yet several clauses could be cut without loss of meaning.

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?

There is no output schema, and the description compensates by enumerating the report's contents (every loss with status, counts by class, integrations with no equivalent, source-only records missing from the loss list, disclosure gaps with fixes) and the four verdict outcomes. Combined with the auth and payment details, an agent has everything needed to call it and interpret the result.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents label, losses, source_only, integrations and cutover_at, including nested field meanings; the description largely restates them ('each loss … with why it is lost … whether the principal was told, when, and whether the principal accepted it'). It adds some framing by tying fields together (cutover_at is read against told_at; source_only and integrations feed the undisclosed-loss detection), but it never notes that the whole payload is optional (required: []). Baseline 3 fits.

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 opening clause states a specific verb and resource — submit the recorded losses of one move and receive a signed report with a verdict — and the definition explicitly carves out the neighbouring question ('whether a reputation record or an identity could be carried to another platform in principle is wever_reputation-portability-check or wever_identity-portability-check'). An agent can distinguish this from the portability siblings without opening a 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 names one concrete alternative and the condition that selects it (portability-in-principle questions belong to the reputation/identity portability checks), which gives the agent real routing guidance. It does not say when to prefer this over other migration siblings such as the cutover, mapping, or report checks, so exclusions remain partial.

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