SAP MCP Server

Build SPL Token Transfer Transaction

sap_build_spl_transfer

Build an unsigned SPL token transfer transaction. Returns serialized base64 transaction for the agent to sign locally with sap_payments_finalize_transaction or sap_sign_transaction → sap_submit_signed_transaction. This is the hosted-safe equivalent of spl-token_transfer (which is local-signer-only and cannot run on the hosted accountless server). Builder fee applies.

SAP MCP execution guidance: Intent: hosted unsigned transaction builder. Pricing: paid builder; estimate first, then pay/build and finalize unsigned transactions locally when returned. Routing: paid hosted call; call sap_estimate_tool_cost first, then use sap_payments_call_paid_tool if the runtime cannot handle x402 natively. Signer boundary: hosted reads/builders never receive keypair bytes; value-moving results must be finalized locally when signing is required.

Input Schema

TableJSON Schema

Name	Required	Description
`mint`	No	SPL token mint address in base58.
`amount`	No	Amount of tokens to transfer in base units (respect the mint decimals).
`decimals`	No	Optional expected token decimals. The builder verifies this against the mint account on-chain.
`sourceOwner`	No	Source token account owner public key in base58. This is the fee payer and must sign the transaction locally.
`destinationOwner`	No	Destination wallet public key in base58. The destination ATA will be created if it does not exist.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`content`	Yes	MCP content blocks returned to the caller.
`isError`	No	True when the tool result represents an application-level error.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 22, 2026

changedInput schema / properties / decimals / description

Previous value: -"Token decimals for the mint. Used for display purposes only — the on-chain amount is in base units."New value: +"Optional expected token decimals. The builder verifies this against the mint account on-chain."

AddedJul 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description discloses behaviors not visible in annotations: the output is an unsigned transaction, the hosted path never receives keypair bytes, a builder fee applies, and value-moving results must be finalized locally. This gives the agent a strong safety/signature model before invocation.

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 core purpose is front-loaded and the operational guidance is clearly structured. However, the 'SAP MCP execution guidance' block is long and partly repeats content already present in the input schema description, making the overall description more redundant than necessary.

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 100% parameter coverage, output schema presence, and description covering purpose, output format, fee, routing, and signer boundary, an agent has everything needed to correctly select and invoke this tool.

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% and every parameter already has a thorough description, including the signer boundary for sourceOwner and the ATA creation behavior for destinationOwner. The tool description reinforces these points but adds no new parameter-level semantics beyond what the schema provides, so the baseline 3 is appropriate.

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 opens with a specific verb+resource: 'Build an unsigned SPL token transfer transaction.' It also states the concrete output ('serialized base64 transaction') and distinguishes itself from spl-token_transfer as the hosted-safe equivalent, making the tool's role unmistakable.

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?

It explicitly names the alternative (spl-token_transfer), explains why it cannot be used in this environment ('local-signer-only and cannot run on the hosted accountless server'), and lays out the exact flow: estimate cost first, pay/build, then sign locally via sap_sign_transaction or finalize. It also gives routing guidance for x402 vs sap_payments_call_paid_tool.

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

All SAP MCP Server 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.