Vybe Pay MCP

Send to mutual friend

send_to_user

Send USDC/USDT to a mutual friend. Pass username (@handle) when known, or name (first, last, or full name). Lookup is limited to mutual friends — never invent wallet addresses. If several friends match the name, the tool returns candidates; ask the owner which @username, then retry. Creates a pending pay — money does not move until Approve in Vybe. Trusted mutual friends still Approve once but notify quietly. Related: get_limits, get_spend_balance, get_wallet_balance, list_recent_pays.

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": {
      "amount": "<amount>"
    },
    "name": "send_to_user"
  }
}

Input Schema

Name	Required	Description
`memo`	No	Optional short note shown on the Approve card.
`name`	No	First name, last name, or full name among mutual friends (e.g. Ada or Ada Lovelace). Used when username is omitted, or as an alternate hint.
`token`	No	Stablecoin to send. Defaults to usdc.
`amount`	Yes	Amount as a decimal string, for example 5 or 1.50.
`username`	No	Recipient Vybe @username (with or without @), or a name string if name is omitted. Must resolve to a mutual friend.

Output Schema

Name	Required	Description	Default
`ok`	Yes
`status`	No
`message`	No
`publicId`	No
`matchedBy`	No
`approveUrl`	No
`candidates`	No
`toUsername`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare a non-read-only, non-destructive, non-idempotent, closed-world write, and the description adds the crucial semantics behind those hints: the call only creates a pending pay and no money moves until Approve in Vybe, and trusted friends still require one approval but are notified quietly. It also warns against inventing wallet addresses, which is real behavioral guardrails not present in the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the action and scope in the first clause, then layers preference, disambiguation, and settlement behavior in short ordered sentences. No filler; every sentence carries operational 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?

For a money-moving mutation with an output schema, the definition covers what an agent must know: recipient resolution rules, the ambiguity path, the pending-pay lifecycle, and the safety constraint on addresses. Return shape is covered by the output schema, so nothing essential is missing.

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 coverage is 100%, so username/name/amount/token/memo are already documented. The description adds the preference ordering (username first, name as fallback/hint) and the ambiguity-retry loop, but the schema itself already says 'Prefer @username when known' and 'Must resolve to a mutual friend,' so most of the description's parameter content is duplication rather than new meaning.

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 ('Send USDC/USDT to a mutual friend') plus the scope restriction that defines it (mutual friends only, resolved by @handle or name). An agent can distinguish it from pay_invoice/pay_offering, which target invoices and offerings rather than people.

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?

Gives concrete selection rules: pass @username when known, otherwise name; lookup is bounded to mutual friends; on ambiguous matches, return candidates, ask the owner which @username, then retry. It also lists related tools (get_limits, get_spend_balance, get_wallet_balance, list_recent_pays) but without stating the conditions that would select them, so the routing is clear for this tool but not fully comparative.

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

All Vybe Pay MCP 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?