Wever Labs Agentic Rails

Migration export check

wever_migration-export-check

Read-only

Agent Migration: submit the export taken from the source system for one move, with the plan it serves: how the export is presented (full, partial or a sample), its format (JSON, JSON lines, CSV, a SQL dump, Parquet, XML, an archive, PDF, HTML, a proprietary format, binary or other), the tools or target systems known to read it and when it was taken; and each item the plan lists as moving, or the export holds, with whether it is planned, whether the export contains it, the record count the source’s own record holds, the count the export holds and its format when it differs. The signed report lists every item as complete, missing, extra, short or unreadable, totals the planned items and the source and export records, and names an export that is incomplete: a partial export presented as full, record counts that do not match the source’s own record, and an export in a format nothing named can read; then planned items missing from an export presented as partial, exported items the plan does not list and records exported only as pages a person reads, with the fix for each. Whether a reputation record can be exported from its platform in principle is wever_reputation-portability-check, and the data export section of a handover package is wever_handover-check. Verdict source_export_incomplete, source_export_gaps, source_export_unverified or source_export_complete. POST /api/migration-export-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": {
      "items": "<items>"
    },
    "name": "wever_migration-export-check"
  }
}

Input Schema

Name	Required	Description
`items`	Yes	Each item the plan lists as moving, with what the export holds.
`label`	No	Optional name recorded in the report.
`source_export`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond annotations (readOnlyHint/openWorldHint=false), the description spells out the auth and payment mechanics an agent must implement: bind X-Wever-Wallet-Proof to the exact JSON arguments and tool route, 0.10 USDC per call on Base via x402 exact, and 10 free calls per rolling 30 days. It also defines what the tool will not do (no network request, fetch, money movement, message, sharing, configuration change or external write, no data moved) and that the report carries an Ed25519 signed receipt — all information an agent cannot get from the annotations alone.

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 specification arrives as one very long run-on clause chain, and inline re-enumeration of formats and presentations repeats what the schema already declares. The routing sentence, verdict list, and access/payment mechanics are well-placed at the end, but the middle paragraph requires re-reading to extract the evaluation rules.

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?

For a nested-object, paid, signed-report tool with no output schema, the description is close to self-sufficient: it describes the report's contents (item statuses, totals, named defects with fixes) and the verdict space. Remaining gaps are minor — the precise precedence between source_export_gaps and source_export_unverified is not stated, so an agent cannot predict which verdict wins when both conditions hold.

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 67%, and the prose adds interpretive meaning the schema cannot: items are counted as short when export_count disagrees with the source's own record, an item can be simultaneously planned, present, or extra, and 'presented as full' vs 'partial' determines which conditions count as a failure. It duplicates the enum vocabularies inline (JSON, JSON lines, CSV, SQL dump, Parquet...) rather than adding semantics there, so it earns a 4 rather than 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 opens with a concrete verb and object — submit an export taken from a source system for one move, together with the plan it serves — and states the artifact produced (a signed report classifying each item). It explicitly distinguishes itself from two named siblings (wever_reputation-portability-check for platform portability in principle, wever_handover-check for the data export section of a handover package), so an agent can route without inspecting other schemas.

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?

Usage boundaries are stated through the enumerated outcomes (source_export_incomplete / gaps / unverified / complete) and through named alternative tools for adjacent questions. What's missing is an explicit "do not use when" statement for the closest siblings in the migration family (wever_migration-loss-check, wever_migration-verify-check), which are not mentioned despite being the most likely confusion.

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?