Borro

Prepare: sweep a receiving address into bUSDG now

payto_sweep

Read-onlyIdempotent

An unsigned transaction to sweep the USDG waiting at a receiving address into bUSDG for its owner now (making the address too, if it is not made yet). Borro's keeper sweeps on its own (about every five minutes once 1 USDG waits); this is for sooner. Any wallet may send it; the shares go to the owner. owner defaults to wallet. Simulated from the wallet; nothing is sent.

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": {
      "wallet": "<wallet>"
    },
    "name": "payto_sweep"
  }
}

Input Schema

Name	Required	Description	Default
`owner`	No	Optional: the owner whose address to sweep (0x...), when it is not the sending wallet
`wallet`	Yes	The wallet's address (0x...); the transactions are built for it to sign

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the return type (an unsigned transaction), the simulation behavior ('simulated from the wallet; nothing is sent'), and the permission model ('any wallet may send it; the shares go to the owner'). This is consistent with readOnlyHint=true and idempotentHint=true — an unsigned, simulated transaction changes no state.

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?

Front-loaded with the core action and no filler sentences. However, the parenthetical '(making the address too, if it is not made yet)' is grammatically awkward and briefly muddies whether this tool also creates the address.

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?

With no output schema, the description carries the return-value burden and does so ('an unsigned transaction'). It also covers side effects and who may submit it. Minor gaps remain around prerequisites such as minimum sweepable balance or gas, but nothing essential for correct invocation is missing.

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 a genuinely useful fact the schema omits: 'owner defaults to wallet'. That default is the one piece of semantics an agent needs to decide whether to pass the optional parameter.

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 (build an unsigned transaction that sweeps USDG from a receiving address into bUSDG) plus the timing qualifier 'now'. This is clearly distinguishable from payto_open (creating the address), payto_withdraw (taking funds out), and keeper_jobs (the automatic sweeper).

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?

Explicitly frames the alternative: the keeper already sweeps roughly every five minutes once 1 USDG is waiting, and this tool exists 'for sooner' — a concrete when-to-use condition. It stops short of contrasting with payto_open/payto_withdraw for the edge case where the receiving address doesn't exist yet.

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

All Borro 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?