vealth

Prepare a REGEN bridge transaction (non-custodial)

prepare_bridge

Read-onlyIdempotent

Move REGEN between the Regen chain, Osmosis, Arbitrum and Base in ONE transaction the caller signs with their own wallet. Returns a live quote and the exact unsigned transaction; Skip Go's relayers carry every hop after the broadcast: no confirm step, nothing held by this server, free. Five routes: regen→arbitrum, regen→base and base→regen (axlREGEN through Axelar), plus regen→osmosis and osmosis→regen (a plain ICS-20 transfer over regen-1 channel-1 and osmosis-1 channel-8). This tool prepares that ICS-20 leg itself: zero toll, amount out equals amount in, one signed message, timeouts derived live by Skip, and no minimum send; on those two legs destination may be omitted, and the sender's own account re-encoded under the destination prefix is used (same key, same 20 bytes, no new wallet). REGEN held on Osmosis still cannot bridge to Base or Arbitrum directly, so routing it home is a separate call: osmosis→regen first, then regen→base or regen→arbitrum from the regen1 address. Base USDC to REGEN and the reverse take two signed transactions and are not offered here. Outbound sends from the Regen chain to Arbitrum or Base pay Axelar's flat per-transfer toll, which Axelar prices in dollars (about $0.20 to $0.23 across 2026-09-05) and so floats in REGEN terms: 150 to 175 REGEN that day, quoted LIVE at call time and returned as quote.toll_regen. The response is authoritative; the figures in this text are approximate. On those Axelar routes send at least twelve times the live toll in one transfer (returned as quote.min_send_regen, which is null on the Osmosis legs because they have no minimum) and batch rather than dribble; a smaller send is refused with the live toll named.

Input Schema

TableJSON Schema

Name	Required	Description
`amount`	Yes	Amount in whole REGEN (e.g. "5000"). Same 6-decimal unit on every chain.
`sender`	Yes	The caller's OWN address on from_chain (regen1… for regen, osmo1… for osmosis, 0x… for base and arbitrum): the wallet that will sign.
`to_chain`	Yes	Chain the REGEN should end up on.
`from_chain`	Yes	Chain the REGEN is on now.
`destination`	No	The caller's OWN address on to_chain that receives the funds. Required on the Arbitrum and Base routes, where no address can be derived from the sender's. Optional on regen→osmosis and osmosis→regen: when omitted, the sender's own account re-encoded under the destination prefix is used (same key, same 20 bytes, no new wallet).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	No
`tool`	No
`funded`	No
`payUsd`	No
`workId`	No
`claimId`	No
`claimable`	No
`next_call`	No
`proofRule`	No
`fulfillableBy`	No
`definitionOfDone`	No
`needs_from_caller`	No
`notClaimableReason`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed5 schema fields changedSep 6, 2026

changedInput schema / properties / destination / description

Previous value: -"The caller's OWN address on to_chain that receives the funds."New value: +"The caller's OWN address on to_chain that receives the funds. Required on the Arbitrum and Base routes, where no address can be derived from the sender's. Optional on regen→osmosis and osmosis→regen: when omitted, the sender's own account re-encoded under the destination prefix is used (same key, same 20 bytes, no new wallet)."

changedInput schema / properties / from_chain / enum

Previous value: -[
-  "regen",
-  "base",
-  "arbitrum"
-]New value: +[
+  "regen",
+  "base",
+  "arbitrum",
+  "osmosis"
+]

changedInput schema / properties / sender / description

Previous value: -"The caller's OWN address on from_chain (regen1… for regen, 0x… for base) — the wallet that will sign."New value: +"The caller's OWN address on from_chain (regen1… for regen, osmo1… for osmosis, 0x… for base and arbitrum): the wallet that will sign."

changedInput schema / properties / to_chain / enum

Previous value: -[
-  "regen",
-  "base",
-  "arbitrum"
-]New value: +[
+  "regen",
+  "base",
+  "arbitrum",
+  "osmosis"
+]

changedInput schema / required

Previous value: -[
-  "from_chain",
-  "to_chain",
-  "amount",
-  "sender",
-  "destination"
-]New value: +[
+  "from_chain",
+  "to_chain",
+  "amount",
+  "sender"
+]

Changed2 schema fields changedAug 26, 2026
- addedOutput schema / properties / claimable
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / notClaimableReason
```
Added value: +{
+  "type": "string"
+}
```
AddedAug 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Even with readOnlyHint, idempotentHint, and openWorldHint annotations, the description adds substantial behavioral context: no confirm step, nothing held by the server, free relay, live quotes, floating Axelar tolls, minimum-send rules, and refusal behavior for too-small sends. This goes well beyond the annotations and prepares the agent for real-world call behavior.

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?

The description is long, but the tool has many route and fee caveats that warrant this length. Core behavior is front-loaded in the first sentence, and subsequent sentences build logically from routes to fees to minimum-send constraints. It could be tightened slightly, but every sentence contributes needed information.

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?

Given the output schema exists, the description need not restate return values, and it still covers the key operational context: route support, destination derivation, toll behavior, minimums, and failure conditions. An agent has enough information to select this tool and call it correctly with the expected parameters.

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 adds meaningful route-specific semantics: destination may be omitted on the Osmosis legs, sender's address can be re-encoded under the destination prefix, and amount out equals amount in on ICS-20 legs. It complements the schema with operational constraints rather than merely restating field types.

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: preparing a REGEN bridge transaction across Regen, Osmosis, Arbitrum, and Base, returning a live quote and an unsigned transaction the caller signs. It clearly differentiates this from sibling tools by naming its exact five routes and the 'prepare' nature of the action.

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?

The description gives explicit when-to-use guidance for the five supported routes and explicitly calls out exclusions, such as Base USDC to REGEN not being offered and Osmosis-held REGEN needing a separate two-step path. It also tells the agent when a different call sequence is required, which is strong routing guidance.

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

All vealth tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation5/5

Despite 41 tools, each has a highly specific purpose with detailed descriptions that clearly differentiate them. The prepare_/submit_ pairs, domain-specific prefixes (gmx_, regen_), and distinct action types (find, get, verify, etc.) leave little room for confusion. Even closely related tools like funding_quote and prepare_funding or my_work and my_votes are explicitly distinguished.

Naming Consistency3/5

Naming conventions are mixed: some tools use plain nouns (account_statement, board_stats), others use verb_noun patterns (prepare_*, submit_*, get_*), possessive (my_votes, my_work), or descriptive phrases (how_to_claim, retire_and_certify). While not chaotic, the lack of a single consistent pattern reduces predictability. However, prefixes like gmx_ and regen_ provide internal consistency within subdomains.

Tool Count2/5

With 41 tools, the count significantly exceeds the recommended range (3-15) and falls into the 'too many' category (25+). Although the server covers a wide range of features (work lifecycle, Regen governance, GMX trading, anchoring, carbon), this number can overwhelm agents and make selection challenging. A more focused tool set would improve coherence.

Completeness4/5

The tool set covers the core workflows for its stated domains well: work posting/funding/claiming/proofing, Regen governance and token data, GMX position management, anchoring, and carbon estimation. Minor gaps exist (e.g., no GMX order cancellation, no work deletion), but overall the surface is comprehensive enough to accomplish primary use cases without dead ends.

Resources

Need Help?