Skip to main content
Glama
Sign In
IDPHANTOM MCP Server

IDPHANTOM MCP Server

by Arbromagency-Sato
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Quote a payment

quote_payment
Idempotent

Generates an IDPHANTOM payment quote with a transparent 0.5% platform fee (min $0.01 USDC) and returns an EIP-712-ready payment intent. Quoting never moves funds.

Instructions

Create an IDPHANTOM payment quote with transparent platform fee (0.5%, min $0.01 USDC). Returns a payment intent ready for the payer's EIP-712 signature. Free: quoting never moves funds.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "payer_wallet": "<payer_wallet>",
      "recipient_wallet": "<recipient_wallet>",
      "asset_contract": "<asset_contract>",
      "amount": "<amount>",
      "chain_id": "<chain_id>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "quote_payment"
  }
}

Input Schema

NameRequiredDescriptionDefault
amountYesToken amount in smallest units (6 decimals for USDC), e.g. '2500000' = $2.50.
chain_idYesEVM chain ID: 8453 = Base mainnet.
metadataNoOptional free-form key/value object attached to the quote (surfaced in receipts).
payer_walletYesEVM address of the payer wallet (0x..., checksummed).
asset_contractYesERC-20 token contract to pay with, e.g. USDC on Base: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913.
payer_agent_idNoOptional A2A agent card ID of the payer, for discovery and audit.
idempotency_keyYesUnique client-generated key; safe retries return the same quote instead of duplicating it.
recipient_walletYesEVM address of the recipient wallet (0x...).
recipient_agent_idNoOptional A2A agent card ID of the recipient.

Output Schema

NameRequiredDescriptionDefault
contentYes
isErrorNoTrue when the API call failed; text carries { error: { code, message } }.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.6

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds substantive context beyond them: the platform fee (0.5%, min $0.01 USDC), the fact that no funds move, and the returned artifact (payment intent for EIP-712 signature). Minor omissions like expiry/TTL of the quote.

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 short sentences, front-loaded with what it creates, followed by the return artifact and the safety/cost reassurance. Every sentence earns its place with no padding.

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?

With a 9-parameter schema at full description coverage, annotations covering safety, and an output schema for return values, the description supplies the essential missing pieces (fee, no-fund-movement, signature-readiness). Only quote validity/expiry and idempotency semantics are left implicit.

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% across all 9 parameters, so the schema fully documents each field; baseline 3 applies. The description adds fee context but no additional per-parameter meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Create an ... payment quote') and what it produces ('a payment intent ready for the payer's EIP-712 signature'). It does not explicitly distinguish itself from siblings authorize_payment/submit_payment/verify_payment, though the quote-vs-execute distinction is fairly self-evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Free: quoting never moves funds' implies this is the safe pre-step before signing/submitting, which lets an agent infer when to call it. However, there is no explicit when-not guidance or named alternative (e.g. use authorize_payment once the quote is signed).

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