SAP MCP Server

Prepare SAP MCP Action

sap_prepare_action

Read-onlyIdempotent

Free intent-level preflight planner for SAP MCP. Call before paid calls, swaps, registry writes, escrow, identity updates, external x402 calls, premium streams, or transaction finalization. It returns the correct hosted/local route, fresh-data requirements, max-price guidance, confirmation policy, retry rules, proof-tape shape, and forbidden actions without charging x402.

SAP MCP execution guidance: Intent: SAP MCP tool workflow. Pricing: free; call directly without x402. Routing: free hosted call; call directly and keep it small/exact when possible. 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
`intent`	No	Closest user intent. Use registry-write for agent registration, update-agent for profile/image updates, swap for token swaps, escrow for SAP Escrow V2, external-x402 for third-party x402 agents, and premium-stream for premium plugin streams/webhooks.
`toolName`	No	Exact hosted or local tool name being planned, such as jupiter_getOrder, sap_update_agent, sap_create_escrow_v2, or sap_payments_register_agent.
`userGoal`	No	Short user-facing goal in natural language, used only to tailor the plan and proof-tape shape.
`maxPriceUsd`	No	Optional user or policy x402 spend cap for this planned action. Agents should normally estimate first and use estimate × 1.25.
`estimatedNotionalUsd`	No	Optional estimated trade, escrow, or value-moving notional in USD for confirmation-policy guidance.
`hasSubmittedSignature`	No	Set true when a transaction signature was already submitted. The planner will route to verification before any retry.
`hasUnsignedTransaction`	No	Set true when a hosted builder already returned unsigned transaction bytes that should be finalized locally.

Output Schema

TableJSON Schema

Name	Required	Description
`intent`	Yes	Normalized intent used for routing.
`success`	Yes	Whether the action preparation plan was generated.
`toolName`	Yes	Tool name provided for the planned action, or null when omitted.
`userGoal`	Yes	Goal provided by the user, or null when omitted.
`retryRules`	Yes	Safe retry rules for x402, RPC, hosted signer guards, and submitted signatures.
`nextToolCalls`	Yes	Exact recommended next tool calls.
`maxPricePolicy`	Yes	How to set maxPriceUsd and when to estimate paid call cost.
`paidOrWriteRoute`	Yes	Canonical paid/write route, including local bridge or hosted builder path.
`freshDataRequired`	Yes	Fresh data that must be fetched before user-facing claims, payment, signing, or execution.
`proofTapeTemplate`	Yes	Audit object shape the agent should fill during execution.
`confirmationPolicy`	Yes	Whether confirmation is required and why.
`freePreflightTools`	Yes	Free tools that should be called before paid/write execution for this intent.
`sessionContextPacket`	Yes	Shared SAP MCP session routing, freshness, memory, and forbidden-action rules.
`userFacingPreviewShape`	Yes	Fields that should appear in a compact human preview before value-moving work.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true and idempotentHint=true, indicating a safe, read-only operation. The description adds value by detailing the tool returns planning data without charging x402, and explains the signer boundary and routing behavior. This enhances the agent's understanding beyond the annotations.

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 description is concise, with two paragraphs: the first clearly states purpose and when to call, and the second provides execution guidance. Key information is front-loaded. The length is appropriate for the tool's complexity, with no superfluous content.

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?

Given the tool's role as a preflight planner with 7 parameters and no required ones, the description covers purpose, usage scenarios, pricing, routing, and signer boundary. An output schema exists, so the omission of return details is acceptable. The description is sufficiently complete for an agent to understand when and how to use 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 description coverage is 100%, and the schema itself provides detailed descriptions for each parameter (e.g., enum values for intent with specific use cases, examples for toolName). The tool description does not add significant per-parameter detail beyond the schema, but provides overall context that helps interpret the parameters. 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 clearly states 'Free intent-level preflight planner for SAP MCP' and lists specific scenarios (paid calls, swaps, etc.) to call it before. This distinguishes it from sibling tools that perform the actual actions, making the purpose unambiguous and well-defined.

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?

The description explicitly states when to use this tool ('Call before paid calls, swaps, registry writes, etc.') and provides guidance on pricing ('free; call directly without x402') and routing ('free hosted call; keep it small/exact'). While it implies when not to use (after executing an action), it does not list explicit alternatives or exclusions.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0

Disambiguation4/5

Tools are organized by protocol prefix (e.g., adrena_, jupiter_, sap_) which helps distinguish domains. Within each protocol, tool names clearly indicate actions (e.g., openPosition, getQuote). However, with 360 tools, some cross-protocol overlaps (e.g., multiple swap tools) and many similar fetch tools in the sap_* family require careful reading of descriptions to disambiguate.

Naming Consistency4/5

Each protocol group follows a consistent naming convention (e.g., snake_case for adrena_, camelCase for 3land, sap_ prefix for SAP SDK tools). The mix of conventions across protocols is acceptable, though a uniform style would improve predictability. Minor inconsistency: hyphenated names like metaplex-nft_ vs underscores.

Tool Count2/5

360 tools is far too many for a well-scoped MCP server. This aggregates dozens of protocols and SAP-specific features, making navigation difficult. The server would benefit from being split into focused micro-servers (e.g., SAP identity, Jupiter DEX, NFT tools). The current count overwhelms the coherence of the set.

Completeness4/5

The tool set covers a vast range of Solana ecosystem activities: token operations, swaps, staking, NFT management, bridging, oracle data, identity registration, chat, escrow, subscriptions, and premium streaming. Major lifecycle operations are present, though some niche subdomains may have missing functions (e.g., detailed governance or lending management). Overall, it's comprehensive for the intended scope.

Prepare SAP MCP Action

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources