Wever Labs Agentic Rails

Migration scope check

wever_migration-scope-check

Read-only

Agent Migration: submit a migration plan for moving an agent or its work from one service, platform, model or provider to another, as recorded: optionally the source and the target with the kind of move, the plan’s scope as written, each asset the plan names with its class (data, memory, tools, identity, credentials, funds, history, settings, integrations, reputation or other), whether it is moving, staying behind, retiring with the source or undecided, whether the source can export it and how it leaves, and optionally the source’s own inventory of what it holds for the agent. The signed report lists every asset with its status, reads each of data, memory, tools, identity, credentials, funds and history as moving, staying, split or unaddressed, and names a scope that is unbounded: scope stated as everything or the whole account instead of a list, assets the source holds that appear on neither the moving nor the staying list, and assets listed as moving that the source cannot export; then undecided assets and core classes nobody addressed, with the fix for each. This reads an actual planned or completed move: whether an identity or a reputation record could be carried to another service in principle is wever_identity-portability-check or wever_reputation-portability-check, and a single handover of work between parties is wever_handover-check. Verdict migration_scope_unbounded, migration_scope_gaps, migration_scope_unverified or migration_scope_bounded. POST /api/migration-scope-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-scope-check"
  }
}

Input Schema

Name	Required	Description
`label`	No	Optional name recorded in the report.
`assets`	No	Each asset the plan names, moving or staying.
`inventory`	No	What the source holds for the agent, to read the plan’s list against.
`migration`	No
`scope_statement`	No	The plan’s scope as written, read for wording such as everything or the whole account.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 11, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces rather than contradicts them: no network request, fetch, money movement, message, sharing, configuration change or external write, and no data is moved. It adds information annotations cannot carry — 0.10 USDC per call on Base via x402, the 10 free signed-wallet calls per rolling 30 days, the X-Wever-Wallet-Proof binding to exact JSON arguments, and an Ed25519 signed receipt on the report.

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 front-loaded opening is strong, but the body is a single dense paragraph of very long comma-chained sentences enumerating asset classes and report contents twice (once for inputs, once again for what the report reads). The Verdict, Contract and Human page lines are terse and useful, but the core sentences could be shortened or bulleted without losing 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?

For a five-parameter nested-object tool with no output schema, the description supplies what is otherwise missing: the four possible verdicts, what the signed report lists (every asset with status, the seven core classes read as moving/staying/split/unaddressed, and the three unbounded-scope conditions), the fix-per-finding behaviour, and the contract path. An agent knows what it will get back and how to interpret it.

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 80%, so the baseline is already 3, and the description goes beyond it by explaining what the fields are for: scope_statement is read for wording such as 'everything' or 'the whole account', assets carry a class and a disposition among moving/staying/retiring/undecided plus exportability and route, and inventory is the source's own record used to read the plan's list against. It does not add format-level detail (lengths, patterns) or explain how label is used beyond being recorded, so it stops short of a 5.

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 states a specific verb and resource ('submit a migration plan for moving an agent or its work') and then bounds it further: it reads a planned or completed move as recorded. It explicitly names adjacent siblings it is not — identity/reputation portability checks and handover-check — so an agent can separate this tool from its closest neighbours 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 Guidelines5/5

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

Usage is stated positively and negatively: use it for an actual planned or completed move as recorded, and use wever_identity-portability-check, wever_reputation-portability-check or wever_handover-check for the principled-portability and single-handover cases. It also states the input expectation (the plan's scope as written, each named asset, optionally the source's own inventory), which tells the agent what material must exist before calling.

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

All Wever Labs Agentic Rails tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?