Skip to main content
Glama
elisymlabs

elisym

Official
by elisymlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

send_payment

Pay a Solana payment request after verifying the recipient address and asset match. Validates the protocol fee, signs, and sends the transaction for manual payment flows.

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', 'usdc', or 'lsm' - lsm is mainnet-only). The payment is refused if the payment_request debits a different asset, closing a currency bait-and-switch where a hostile request swaps one asset for another. 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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.44
    • changedInput schema / properties / expected_asset / description
      Previous value: -"Required: 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."New value: +"Required: the asset you expect to pay ('sol', 'usdc', or 'lsm' - lsm is mainnet-only). The payment is refused if the payment_request debits a different asset, closing a currency bait-and-switch where a hostile request swaps one asset for another. Verify BOTH the recipient AND the asset independently before paying."
    • changedInput schema / properties / expected_asset / enum
      Previous value: -[
-  "sol",
-  "usdc"
-]New value: +[
+  "sol",
+  "usdc",
+  "lsm"
+]
  2. Changed2 schema fields changedv0.1.43
    • changedInput schema / properties / expected_asset / description
      Previous value: -"Optional: the asset you expect to pay ('sol' or 'usdc'). When set, the payment is refused if the payment_request debits a different asset. Verify BOTH the recipient AND the asset independently before paying."New value: +"Required: 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."
    • changedInput schema / required
      Previous value: -[
-  "payment_request",
-  "expected_solana_recipient"
-]New value: +[
+  "payment_request",
+  "expected_solana_recipient",
+  "expected_asset"
+]
  3. Changed2 schema fields changedv0.1.42
    • addedInput schema / properties / expected_asset
      Added value: +{
+  "description": "Optional: the asset you expect to pay ('sol' or 'usdc'). When set, the payment is refused if the payment_request debits a different asset. Verify BOTH the recipient AND the asset independently before paying.",
+  "enum": [
+    "sol",
+    "usdc"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / job_event_id
      Added value: +{
+  "description": "Optional: 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.",
+  "maxLength": 128,
+  "type": "string"
+}
  4. Addedv0.1.37
  5. Removedv0.1.36
  6. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the key behaviors: validates protocol fee, verifies recipient and asset, signs and sends the transaction. It also (indirectly) signals refusal behavior via the expected_asset parameter description. It could go further by mentioning irreversibility or that funds are actually transferred, but 'pay' and 'sends the transaction' make the side effect clear enough.

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, zero filler. The core action is front-loaded, followed by the verification steps, and then the usage preference. The capitalized PREFER is a slight stylistic quirk but draws attention to the key routing guidance. Every sentence earns its place.

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?

The description covers purpose, verification logic, and sibling routing, but with no output schema and no annotations, an agent is left without knowledge of what the function returns (e.g., transaction signature) or what error conditions look like (insufficient funds, expired request). For a financial transaction tool, this is a meaningful gap, though the core usage context is strong.

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 description coverage is 75% (payment_request has no schema description). The tool description adds marginal context by identifying payment_request as coming from a provider's job feedback, and emphasizes the need to verify recipient and asset. However, it does not explain the structure or format of a payment_request, leaving a gap for the one undocumented parameter. This is better than bare schema but does not fully compensate.

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 a specific action ('Pay a Solana payment request'), identifies the source ('from a provider's job feedback'), and enumerates the safety checks (protocol fee, recipient and asset verification). It explicitly contrasts with sibling tools (submit_and_pay_job, buy_capability) by naming what this one is not, giving an agent immediate differentiation.

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?

Explicit guidance: PREFER submit_and_pay_job or buy_capability for auto-verified payments, and use send_payment only for manual flows with independently verified recipient. This gives clear when-to and when-not-to instructions, naming alternatives and the condition that selects them—nothing is left to inference.

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

Deploy Server

Other Tools