Wever Labs Agentic Rails

Migration mapping check

wever_migration-mapping-check

Read-only

Agent Migration: submit the field and concept mapping between the source and the target of one move: each source field or concept with the target field it lands in, its disposition (mapped, merged into one target field with others, dropped, or with no counterpart on the target), whether the plan names the drop, the unit, currency or time zone on each side with the conversion between them, the status or category values each side uses with the value map between them, and the data type on each side; and optionally every field the source schema holds. The signed report lists every mapping as carried, changing meaning, dropped or unstated, every drop with whether the plan names it, and every meaning change with its unit, stranded values and type, and names a mapping that corrupts data without failing: fields dropped silently or never mentioned, fields with no counterpart on the target the plan does not name, fields that keep their name while their unit or currency changes with no conversion, and status values with nowhere to land; then several source fields poured into one target field and data type changes with no conversion, with the fix for each. Whether an asset class can be carried to another service in principle is wever_identity-portability-check or wever_reputation-portability-check. Verdict mapping_corrupts, mapping_gaps, mapping_unverified or mapping_faithful. POST /api/migration-mapping-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

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "mappings": "<mappings>"
    },
    "name": "wever_migration-mapping-check"
  }
}

Input Schema

Name	Required	Description
`label`	No	Optional name recorded in the report.
`mappings`	Yes	Each field or concept on the source with where it lands on the target.
`source_fields`	No	Every field the source schema holds, to read for fields the mapping never mentions.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 11, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial context beyond them: no network request, fetch, money movement, message, sharing, configuration change or external write, and no data moved. It also discloses the paid access model (0.10 USDC per call on Base via x402 exact, 10 signed-wallet free calls per rolling 30 days), the X-Wever-Wallet-Proof binding requirement, and the Ed25519 signed receipt returned with 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 purpose is front-loaded, but the description is a dense, multi-clause run-on that repeats much of the input schema field-by-field before getting to the verdict and report content. The pricing, auth and contract details earn their place, but the mapping-field enumeration could be shortened considerably.

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, the description explains the report contents (every mapping as carried, changing meaning, dropped or unstated; drops and whether named; meaning changes with stranded values; corruption patterns and fixes) and the verdict set. Combined with full schema coverage, annotations and the contract/human-page links, an agent has enough to call it correctly.

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 every parameter already has an inline description. The prose restates the mapping fields (disposition, named_in_plan, units, value maps, types, source_fields) in a narrative that explains how they combine into findings, which adds some interpretive value, but the description does not add syntax, format or edge-case detail beyond what the schema already provides.

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: submit the field and concept mapping between source and target of one move, and check it for corruption or gaps. It names the verdicts (mapping_corrupts, mapping_gaps, mapping_unverified, mapping_faithful) and explicitly routes asset-class portability questions to wever_identity-portability-check and wever_reputation-portability-check, so an agent can distinguish it from those siblings.

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 gives clear context for when to call it—when you have a field/concept mapping for a single migration move—and explicitly names two alternative tools for a related but different question (whether an asset class can be carried in principle). It does not explicitly cover the closest migration siblings such as loss-check, scope-check or verify-check, so the when-not guidance is partial but real.

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?