SAP MCP Server

Submit Signed Transaction

sap_submit_signed_transaction

Destructive

Submit a signed Solana transaction produced by sap_sign_transaction through the configured RPC endpoint. Use this instead of custom sendRawTransaction scripts so policy, retries, and audit stay inside SAP MCP.

SAP MCP execution guidance: Intent: SAP MCP tool workflow. Pricing: paid value-action; preview cost and transaction effects before user confirmation. 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
`encoding`	No	Input encoding
`intentId`	No	Optional caller-provided id binding submission, confirmation, and audit output.
`commitment`	No	Desired confirmation status before returning success. Defaults to confirmed.
`maxRetries`	No	Maximum RPC send retries
`skipPreflight`	No	Skip RPC preflight checks
`submitRelayUrl`	No	Optional submit relay URL. Must be HTTPS, localhost, or 127.0.0.1.
`submitViaRelay`	No	When true, submit through the hosted OOBE relay. The relay only broadcasts already-signed bytes and never signs. Defaults to false for this local tool.
`signedTransaction`	No	Signed serialized transaction
`confirmationTimeoutMs`	No	Bounded confirmation wait in milliseconds. Defaults to 90000; maximum 180000.

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 changedJul 24, 2026

addedInput schema / description

Added value: +"Submit Signed Transaction input schema. Intent: SAP MCP tool workflow. Pricing: paid value-action; preview cost and transaction effects before user confirmation. 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. Use exact field names from this schema; do not guess aliases or include private key material."

Changed5 schema fields changedJul 19, 2026

addedInput schema / properties / commitment

Added value: +{
+  "description": "Desired confirmation status before returning success. Defaults to confirmed.",
+  "enum": [
+    "processed",
+    "confirmed",
+    "finalized"
+  ],
+  "type": "string"
+}

addedInput schema / properties / confirmationTimeoutMs

Added value: +{
+  "description": "Bounded confirmation wait in milliseconds. Defaults to 90000; maximum 180000.",
+  "type": "number"
+}

addedInput schema / properties / intentId

Added value: +{
+  "description": "Optional caller-provided id binding submission, confirmation, and audit output.",
+  "type": "string"
+}

addedInput schema / properties / submitRelayUrl

Added value: +{
+  "description": "Optional submit relay URL. Must be HTTPS, localhost, or 127.0.0.1.",
+  "type": "string"
+}

addedInput schema / properties / submitViaRelay

Added value: +{
+  "description": "When true, submit through the hosted OOBE relay. The relay only broadcasts already-signed bytes and never signs. Defaults to false for this local tool.",
+  "type": "boolean"
+}

First observedJul 13, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already indicate destructive and non-idempotent behavior. Description adds that it handles retries, audit, and stays within SAP MCP, providing extra context beyond annotations.

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

Conciseness3/5

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

First sentence is concise, but the description includes a lengthy block of SAP MCP execution guidance that appears boilerplate and reduces conciseness. Structured but not optimally succinct.

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?

Covers key aspects: submission through configured RPC, retries, audit, and commitment. The output schema exists so return values need not be described. Lack of error handling detail is minor given the schema coverage.

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% with descriptions for all 9 parameters. Description does not add new information about parameters but includes a caution about not including private key material, which is marginally helpful. Baseline 3 applies.

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?

Explicitly states it submits a signed Solana transaction produced by sap_sign_transaction, distinguishing it from custom sendRawTransaction scripts. The verb 'submit' and resource 'signed transaction' are clear.

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 recommends using this instead of custom scripts for policy, retries, and audit. SAP MCP guidance provides context on when to use paid tool variants, though some guidance is generic.

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.