Skip to main content
Glama
OOBE-PROTOCOL

SAP MCP Server

by OOBE-PROTOCOL
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

Create SAP Escrow V2

sap_create_escrow_v2

Create V2 escrows for payment settlement using DisputeWindow or CoSigned security modes. Configurable token, price, expiry, and max calls.

Instructions

Local-signer-only direct V2 escrow creation using SDK EscrowV2Module.create. Defaults to DisputeWindow settlementSecurity=2; SelfReport/0 is rejected. Hosted accountless SAP MCP rejects this before x402 payment; hosted users should call sap_escrow_build_create_transaction and finalize locally. SAP MCP context: Payment and settlement flow. Estimate or fetch state before creating escrows or settling calls; write operations require an enabled signer mode and MCP policy approval.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nonceNoOptional escrow nonce as a decimal string. Defaults to 0.
arbiterNoOptional arbiter public key kept for IDL compatibility and dispute workflows.
coSignerNoRequired co-signer wallet public key when settlementSecurity=1 (CoSigned).
maxCallsNoMaximum number of calls covered by the escrow as a decimal string. Use 0 for unlimited when supported by policy.
expiresAtNoOptional expiry timestamp in unix seconds as a decimal string. Defaults to 0 (no expiry).
tokenMintNoOptional SPL payment token mint. Omit/null for native SOL. Use EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v for mainnet USDC x402 escrows.
agentWalletNoAgent owner wallet public key (base58). The V2 escrow PDA is derived from this wallet plus nonce.
pricePerCallNoPrice per served call as a decimal string. Amount in the escrow token smallest unit: lamports for SOL, micro-USDC for USDC, or base units for the configured SPL token.
tokenDecimalsNoPayment token decimals. Defaults to 6 when tokenMint is set, otherwise 9 for native SOL.
initialDepositNoInitial escrow deposit as a decimal string. Amount in the escrow token smallest unit: lamports for SOL, micro-USDC for USDC, or base units for the configured SPL token.
disputeWindowSlotsNoRequired positive dispute window in slots for settlementSecurity=2. Defaults to 2160 (~15 minutes).
settlementSecurityNoV2 settlement security mode. 1=CoSigned (requires coSigner). 2=DisputeWindow (recommended default; requires disputeWindowSlots > 0). SelfReport/0 is deprecated and rejected on-chain.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
contentYesMCP content blocks returned to the caller.
isErrorNoTrue when the tool result represents an application-level error.

Tool Definition Quality

A4.5/5.0
Behavior4/5

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

Annotations indicate readOnlyHint=false and destructiveHint=false. Description adds behavioral context: 'Defaults to DisputeWindow settlementSecurity=2', 'SelfReport/0 is rejected', 'local-signer-only', and rejection for hosted accountless before payment. No contradiction with 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 a single paragraph but packs necessary information efficiently. It front-loads the core purpose and usage constraints. Could be better structured with line breaks, but every sentence adds value without redundancy.

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 12 parameters, schema coverage, output schema existence, and annotations, the description provides sufficient context for correct tool invocation. It explains hosted vs local, prerequisites, and rejection conditions. Minor gap: does not explain output schema structure, but that's covered by output schema.

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?

Schema coverage is 100%, so baseline is 3. Description adds value by stating defaults (settlementSecurity=2, disputeWindowSlots defaults to 2160) and rejecting SelfReport/0, which is not in schema. This enriches parameter understanding beyond basic descriptions.

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 the tool's purpose: 'Local-signer-only direct V2 escrow creation' using a specific SDK method. It distinguishes from sibling tools like sap_escrow_build_create_transaction by specifying when to use each (hosted accountless vs local). The verb-resource pair is explicit.

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 on when not to use (hosted accountless SAP MCP before x402 payment) and alternative tool (sap_escrow_build_create_transaction). Also mentions prerequisites: enabled signer mode and MCP policy approval. No ambiguity.

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/OOBE-PROTOCOL/sap-mcp'

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