IDPHANTOM MCP Server

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.

Input Schema

TableJSON Schema

Name	Required	Description
`amount`	Yes	Token amount in smallest units (6 decimals for USDC), e.g. '2500000' = $2.50.
`chain_id`	Yes	EVM chain ID: 8453 = Base mainnet.
`metadata`	No	Optional free-form key/value object attached to the quote (surfaced in receipts).
`payer_wallet`	Yes	EVM address of the payer wallet (0x..., checksummed).
`asset_contract`	Yes	ERC-20 token contract to pay with, e.g. USDC on Base: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913.
`payer_agent_id`	No	Optional A2A agent card ID of the payer, for discovery and audit.
`idempotency_key`	Yes	Unique client-generated key; safe retries return the same quote instead of duplicating it.
`recipient_wallet`	Yes	EVM address of the recipient wallet (0x...).
`recipient_agent_id`	No	Optional A2A agent card ID of the recipient.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`content`	Yes
`isError`	No	True when the API call failed; text carries { error: { code, message } }.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.6Oct 1, 2026

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