Skip to main content
Glama

send_payment

Pay a Solana payment request by validating fees, verifying the recipient address and asset match, then signing and sending the transaction.

Instructions

Pay a Solana payment request (from a provider's job feedback). Validates protocol fee, verifies the expected recipient address AND asset match, signs and sends the transaction. PREFER submit_and_pay_job or buy_capability which auto-verify the recipient from the provider's published capability card. Use send_payment only for manual payment flows where you have independently verified the recipient address.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_event_idNoOptional: the Nostr job request event id this payment is for. When given, the payment embeds an elisym memo so it is linkable to the job, and the job is recorded locally so a later submit_feedback rating carries the payment proof.
expected_assetYesRequired: the asset you expect to pay ('sol' or 'usdc'). The payment is refused if the payment_request debits a different asset, closing a currency bait-and-switch where a hostile request swaps SOL for USDC (or vice versa). Verify BOTH the recipient AND the asset independently before paying.
payment_requestYes
expected_solana_recipientYesBase58 Solana address you expect to receive the payment (from the provider card).
Behavior4/5

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

No annotations exist, so the description carries full burden. It discloses key behaviors: validates protocol fee, verifies recipient and asset, signs and sends transaction. However, it omits details on failure modes or transaction irreversibility.

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?

Three sentences: action + validation, sibling preference, manual flow condition. Every sentence earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Absent output schema, the description does not specify return values (e.g., transaction signature) or error cases. For a payment tool, this is a notable gap, but sibling context partly compensates.

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?

The description adds context beyond the schema: links 'expected_asset' to bait-and-switch prevention, and explains 'job_event_id' embeds memo and records job. With 75% schema coverage, it compensates for the missing description on 'payment_request' by implying its role.

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 clearly states it pays a Solana payment request with validation steps. It explicitly distinguishes from sibling tools by recommending submit_and_pay_job and buy_capability for automatic verification, making the scope precise.

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 provides explicit guidance: prefer alternative tools for auto-verification, and use send_payment only for manual flows with independently verified recipient. This clarifies when to use vs. avoid the tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/elisymlabs/elisym'

If you have feedback or need assistance with the MCP directory API, please join our Discord server