Which integrations are available for this server?

Provides tools for creating, settling, disputing, and refunding escrows on Ethereum and other EVM chains. Enables publishing evidence to IPFS and submitting it on-chain for arbitration.

How do I use dpay-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dpay-mcp Send 0.01 ETH to 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 with a 1-day settlement window." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

dpay-mcp

by programmaman

Overview Schema Related Servers Score Discussions

TypeScript

Remote

dpay-mcp

A MCP server for creating, settling, disputing, and refunding escrows on EVM chains.

Quick Start

Configure the MCP server in your client. Restart, then tell your agent what to do.

VS Code

Add to .vscode/mcp.json:

{
  "servers": {
    "dpay": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@rakelabs/dpay-mcp"],
      "env": {
        "RPC_URL": "${env:RPC_URL}",
        "CHAIN_ID": "${env:CHAIN_ID}",
        "PRIVATE_KEY": "${env:PRIVATE_KEY}",
        "ALLOWED_TOKENS": "${env:ALLOWED_TOKENS}"
      }
    }
  }
}

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "dpay": {
      "command": "npx",
      "args": ["-y", "@rakelabs/dpay-mcp"],
      "env": {
        "RPC_URL": "${RPC_URL}",
        "CHAIN_ID": "${CHAIN_ID}",
        "PRIVATE_KEY": "${PRIVATE_KEY}",
        "ALLOWED_TOKENS": "${ALLOWED_TOKENS}"
      }
    }
  }
}

Done

Restart your client. Ask your agent:

I want to do business on chain, what's your wallet address?

Related MCP server: base-escrow-mcp

More Client Options

Inline values (less secure)

Quick start — replace with your values:

Claude Desktop:

{
  "mcpServers": {
    "dpay": {
      "command": "npx",
      "args": ["-y", "@rakelabs/dpay-mcp"],
      "env": {
        "RPC_URL": "https://eth-mainnet.g.alchemy.com/v2/YOUR_KEY",
        "CHAIN_ID": "1",
        "PRIVATE_KEY": "0x...",
        "ALLOWED_TOKENS": "ETH:0.1:0.01"
      }
    }
  }
}

VS Code:

{
  "servers": {
    "dpay": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@rakelabs/dpay-mcp"],
      "env": {
        "RPC_URL": "https://eth-mainnet.g.alchemy.com/v2/YOUR_KEY",
        "CHAIN_ID": "1",
        "PRIVATE_KEY": "0x...",
        "ALLOWED_TOKENS": "ETH:0.1:0.01"
      }
    }
  }
}

Windows

npx can hang on Windows. Use cmd /c instead:

Claude Desktop:

{
  "mcpServers": {
    "dpay": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@rakelabs/dpay-mcp"],
      "env": {
        "RPC_URL": "https://eth-mainnet.g.alchemy.com/v2/YOUR_KEY",
        "CHAIN_ID": "1",
        "PRIVATE_KEY": "0x...",
        "ALLOWED_TOKENS": "ETH:0.1:0.01"
      }
    }
  }
}

Other MCP Clients

Use command: "npx" with args: ["-y", "@rakelabs/dpay-mcp"] and pass env vars through your client config.

Development

git clone https://github.com/programmaman/dpay-mcp.git
cd dpay-mcp
npm install

export RPC_URL=https://eth-mainnet.g.alchemy.com/v2/YOUR_KEY
export CHAIN_ID=1
export PRIVATE_KEY=0x...
export ALLOWED_TOKENS=ETH:0.1:0.01

npm run dev

Agent Prompt Examples

I want to do business on chain, what's your wallet address?

Send 0.01 ETH to 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 with a 1-day settlement window.

The agent handles the rest. Tool definitions describe every action — creating payments, checking status, settling, disputing, refunding. Just tell the agent what you need, or let it do what it wants.

Tools

Tool	Description	Use case
`whoami`	Returns wallet address, chain ID, factory, and spending limits	Start of session
`eth_create_payment`	Creates an ETH escrow	Pay someone in ETH
`erc20_create_payment`	Creates an ERC20 escrow and handles approval	Pay someone in USDC or another token
`payment_info`	Reads on-chain payment state	Check current status
`raise_dispute`	Starts arbitration	Payment is disputed
`submit_evidence`	Publishes evidence to IPFS and submits it on-chain	Prove a case in arbitration
`settle`	Claims funds after the settlement window	You are the payee and time has passed
`refund`	Returns funds to the payer voluntarily	You are the payee and want to refund

Workflows

Create  whoami -> eth_create_payment or erc20_create_payment
Settle  payment_info -> settle (payee only, after settlement window)
Dispute payment_info -> raise_dispute -> submit_evidence
Refund  payment_info -> refund (payee only)

Configuration

Set these environment variables before starting the server.

Required

RPC_URL: EVM RPC endpoint
CHAIN_ID: Chain ID. Use 1 for Ethereum mainnet.
ALLOWED_TOKENS: Spending limits. Format described below.

Optional

PRIVATE_KEY: Wallet private key. Omit for a disposable wallet.
MIN_SETTLEMENT_WINDOW_SEC: Minimum settlement window in seconds.
FACTORY_ADDRESS: Payment factory contract address. Omit if the factory is known for your chain.
POLICY_WEBHOOK_URL: URL for external compliance checks. Fail-closed.
POLICY_WEBHOOK_TOKEN: Bearer token for the policy webhook.
EVIDENCE_IPFS_ENDPOINT: Remote IPFS endpoint. Omit for in-process Helia.
EVIDENCE_IPFS_AUTH_TYPE: Auth type: bearer, basic, or none.
EVIDENCE_IPFS_AUTH_TOKEN: Token for bearer auth.
EVIDENCE_IPFS_USERNAME: Username for basic auth.
EVIDENCE_IPFS_PASSWORD: Password for basic auth.
EVIDENCE_IPFS_HEADERS: Extra HTTP headers as JSON. Example: {"network":"public"}
EVIDENCE_IPFS_UPLOAD_FIELDS: Multipart fields as JSON. Example: {"network":"public"}
EVIDENCE_IPFS_FILE_FIELD: Multipart field name for the file blob.
EVIDENCE_IPFS_GATEWAYS: Comma-separated IPFS gateway URLs for readable links.

ALLOWED_TOKENS format

ALLOWED_TOKENS=ETH:0.1:0.01,0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48:500:100

Each entry is address:session_budget:max_per_tx. Built-in aliases are ETH and USDC.

When ALLOWED_TOKENS is set, the server rejects transactions that:

use a token not in the list
exceed the per-transaction limit
exceed the session budget

The server will not start without ALLOWED_TOKENS. This prevents an agent from spending without limits.

Wallets

If you omit PRIVATE_KEY, the server creates a random wallet on first start. The key is saved to ~/.dpay-mcp/wallet-key. Set PRIVATE_KEY later to reuse the same wallet.

Scripts

Command	Purpose
`npm run dev`	Start the server with tsx (hot reload)
`npm start`	Build and start from compiled JavaScript
`npm run inspector`	Open the MCP Inspector UI

Project Structure

src/
  index.ts                   server startup and tool registration
  dpay-signer.ts             transaction signing and submission
  config-enforcer.ts         spending limit checks
  natural-language-converter.ts  ETH and ERC20 unit conversion
  evidence-client.ts         IPFS evidence publishing (worker thread bridge)
  evidence-worker.ts         Helia worker thread
  payment-store.ts           payment record persistence
  error-format.ts            revert data decoding
  policy-webhook.ts          external compliance check
test/                        tests

License

Apache 2.0

Available Tools

8 tools

erc20_create_paymentA

Creates an ERC20 payment contract.ONLY for ERC20 tokens — do NOT use for ETH. Call exactly as: {"tool":"erc20_create_payment","args":{"tokenAddress":"0x...","payeeAddress":"0x...","tokenAmount":"1","settlementWindowSec":"86400"}}

ParametersJSON Schema

Name	Required	Description
`tokenAmount`	Yes	Amount in token units. Example: "1" for 1 USDC.
`payeeAddress`	Yes	The recipient address
`tokenAddress`	Yes	The ERC20 token contract address
`settlementWindowSec`	Yes	Settlement window in seconds from now. Example: "86400" for 1 day. The server computes the absolute timestamp from the latest block.

TDQS

A4.1/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only says 'Creates an ERC20 payment contract' without mentioning side effects (like requiring token approval), whether it is destructive, or what the return value is. This is minimal transparency.

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?

The description is concise with two sentences: one stating purpose and constraint, one providing the exact call format. No redundant words, and critical information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a simple creation tool but lacks context about prerequisites (e.g., need to have approved the contract to spend tokens), return value, and post-creation steps. With no output schema and no annotations, more context would improve completeness.

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 each parameter is already described. The description adds value by providing an example call format and clarifying tokenAmount format with '1 for 1 USDC'. This goes beyond the schema's 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 creates an ERC20 payment contract and explicitly distinguishes from ETH usage by stating 'ONLY for ERC20 tokens — do NOT use for ETH.' The sibling tool `eth_create_payment` confirms this differentiation.

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?

The description provides explicit usage guidance: when to use (for ERC20 tokens) and when not to use (for ETH). It also gives an exact example call with parameters, making it very clear for the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

eth_create_paymentA

Creates an ETH payment contract. ONLY for ETH — do NOT use for USDC or other ERC20 tokens. Call exactly as: {"tool":"eth_create_payment","args":{"payeeAddress":"0x...","etherAmount":"0.01","settlementWindowSec":"86400"}}

ParametersJSON Schema

Name	Required	Description
`etherAmount`	Yes	Amount in ETH. Example: "0.001" for 0.001 ETH.
`payeeAddress`	Yes	The recipient address
`settlementWindowSec`	Yes	Settlement window in seconds from now. Example: "86400" for 1 day. The server computes the absolute timestamp from the latest block.

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It describes the action but omits key details such as potential ETH expenditure, irreversibility, and required permissions.

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?

The description is extremely concise: two sentences and an example call. It front-loads the core purpose and constraints without any unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose and usage constraints but lacks information about return values, error handling, or state changes. For a payment tool, this is adequate but not complete.

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%, so baseline is 3. The description adds an example call that shows parameter format, adding marginal value beyond the schema 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 creates an ETH payment contract and explicitly restricts usage to ETH only, distinguishing it from sibling tools like erc20_create_payment.

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 warns against using for USDC or other ERC20 tokens, providing clear guidance on when not to use. It includes an example call but does not explicitly mention alternatives like erc20_create_payment.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

payment_infoA

Read the on-chain state for a payment. Call exactly as: {"tool":"payment_info","args":{"paymentAddress":"0x..."}}

ParametersJSON Schema

Name	Required	Description	Default
`paymentAddress`	Yes	The DisputablePayment contract address

TDQS

A4.5/5.0

Behavior4/5

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

Discloses it is a read operation (no state change) and accesses on-chain state. Without annotations, this is adequate; no hidden side effects.

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?

Two sentences with zero wasted words. Front-loaded with purpose, then call format.

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?

Adequate for a simple read tool. Does not describe return values, but output schema is absent; however, given sibling diversity, it covers the needed context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds value beyond schema by showing the exact call format with the parameter. Schema already has 100% coverage, but the description reinforces usage.

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 reads the on-chain state for a payment, distinguishing it from sibling tools like erc20_create_payment or raise_dispute.

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?

Provides an exact call format, implying usage when needing to read payment state. Lacks explicit when-not-to-use or alternatives, but siblings are clearly different.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

raise_disputeA

Raise a Kleros dispute for a PAID payment before the settlement time passes. Call exactly as: {"tool":"raise_dispute","args":{"paymentAddress":"0x..."}}

ParametersJSON Schema

Name	Required	Description	Default
`paymentAddress`	Yes	The DisputablePayment contract address

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states the action without disclosing consequences, prerequisites, or side effects. For a dispute tool, this is insufficient.

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 very short (two sentences) and front-loaded with the action. No unnecessary text, though it could include more context without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete. It does not explain what happens after the dispute is raised, which is critical for a high-stakes 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 coverage is 100% for the single parameter, and the description adds no extra meaning beyond the schema's description. 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 the action (raise a Kleros dispute), the specific context (for a PAID payment), and a condition (before settlement time passes). It distinguishes from sibling tools like settle or refund.

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 provides clear timing guidance ('before the settlement time passes') and an exact call example. However, it does not explicitly exclude use cases or mention alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

refundA

Voluntarily send the funds back to the payer. Only the payee should call this. Call exactly as: {"tool":"refund","args":{"paymentAddress":"0x..."}}

ParametersJSON Schema

Name	Required	Description	Default
`paymentAddress`	Yes	The DisputablePayment contract address

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the burden. It implies a voluntary, safe action but does not disclose side effects, permissions, or outcome details beyond the call example. Adequate but not thorough.

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 sentences: purpose, usage guideline, exact call format. No unnecessary words, front-loaded with critical info.

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?

For a simple tool with one parameter and no output schema, the description is reasonably complete. It covers what, who, and how. Could mention success indication but the example suffices.

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 a description for 'paymentAddress'. The tool description only repeats it in the example, adding no extra meaning beyond the schema. Baseline score for high coverage.

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 action ('Voluntarily send the funds back to the payer') and specifies the resource (payer). It distinguishes from sibling tools like raise_dispute and settle by focusing on refund.

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 states who should call ('Only the payee should call this') and provides an exact JSON call format. Lacks explicit when-not-to-use conditions, but the context is clear for the intended user.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

settleA

Claim payment funds after the settlement window has passed. Only the payee should call this. Call exactly as: {"tool":"settle","args":{"paymentAddress":"0x..."}}

ParametersJSON Schema

Name	Required	Description	Default
`paymentAddress`	Yes	The DisputablePayment contract address

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It states the tool claims funds (likely a transfer) and specifies the caller. However, it does not disclose behavior if called too early, error states, whether it's irreversible, or required permissions beyond 'payee.'

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 sentences with no wasted words. First sentence states purpose, second states caller, third gives exact call format. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only one parameter, no output schema, and no nested objects, the description provides all necessary information: purpose, caller, and exact usage format. It is complete for an agent to select and invoke correctly.

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?

The input schema has 100% coverage with a clear description for 'paymentAddress'. The description adds an example call with the parameter, but does not provide additional meaning beyond the schema. 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 the action ('claim payment funds'), the resource ('payment funds'), and a condition ('after the settlement window has passed'). It also specifies the caller ('Only the payee should call this.'), distinguishing it from sibling tools like refund or raise_dispute.

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 who should call ('Only the payee') and provides an exact JSON call example. While it doesn't explicitly list when not to use, the context implies it's for claiming after settlement window. Sibling tool names (e.g., refund, raise_dispute) provide implicit alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

submit_evidenceA

Publish evidence for an existing dispute. Call exactly as: {"tool":"submit_evidence","args":{"paymentAddress":"0x...","argument":"short factual explanation"}}

ParametersJSON Schema

Name	Required	Description	Default
`argument`	No	A factual account of what happened with this payment, from your perspective. Jurors will read this to understand the context of the dispute.
`paymentAddress`	Yes	The DisputablePayment contract address

TDQS

A3.8/5.0

Behavior3/5

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

Mentions that jurors read evidence but does not disclose side effects, idempotency, or limits. No annotations provided, so more detail expected.

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?

Two sentences with a clear code block; no wasted words.

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?

Sufficient for a simple tool with two params; lacks behavioral details but overall adequate.

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 has 100% coverage; description only adds a usage example without significant new meaning beyond schema.

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?

Clear verb 'Publish' and resource 'evidence for an existing dispute' distinguishes from sibling tools like raise_dispute which creates the dispute.

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?

Provides an example call format but does not explicitly state when to use this vs alternatives like raise_dispute or refund.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

whoamiA

Discover the current wallet, chain, factory address, and spending limits. Call exactly as: {"tool":"whoami","args":{}}

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description must disclose behavior. It correctly indicates this is a read-only operation (discover) and lists the returned items. No side effects are mentioned, which is appropriate for a query tool. Sufficient for a zero-parameter tool.

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?

Two sentences, no wasted words. The example call is immediately useful. Front-loaded with the purpose, then the exact invocation. Excellent conciseness.

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?

Although there is no output schema, the description explicitly lists what the tool returns (wallet, chain, factory address, spending limits), providing adequate information for an agent to understand the result. For a simple query tool, this is complete enough.

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?

With zero parameters, no additional semantics are needed. The description includes a JSON example showing the empty args, which adds clarity. Baseline 4 is appropriate since schema coverage is 100% and description adds value through the example.

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: 'Discover the current wallet, chain, factory address, and spending limits.' It uses specific verbs and nouns, and distinguishes itself from sibling tools which are all action-oriented (e.g., erc20_create_payment, raise_dispute).

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?

Provides an explicit call example, guiding the agent on how to invoke the tool correctly. While it doesn't explicitly contrast with siblings, the purpose is distinct enough that an agent can infer when to use this tool (to get identity info) vs alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.1.7Jun 30, 2026
- First observederc20_create_payment
- First observedeth_create_payment
- First observedpayment_info
- First observedraise_dispute
- First observedrefund
- First observedsettle
- First observedsubmit_evidence
- First observedwhoami

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool has a distinct purpose: separating ERC20 and ETH payment creation, plus dedicated tools for info, dispute, refund, settle, evidence, and wallet info. No two tools overlap in function.

Naming Consistency4/5

All names use snake_case and follow a verb_noun pattern (e.g., create_payment, raise_dispute), though the token type prefix on erc20_create_payment and eth_create_payment introduces a minor inconsistency. Still predictable.

Tool Count5/5

8 tools provide a focused yet complete set for the decentralized payment domain. Each tool is justified and the count is well-scoped for the server's purpose.

Completeness4/5

Covers the essential lifecycle: create, settle, dispute, evidence, refund, and wallet info. Missing a cancel tool for the payer, but the core workflows are covered adequately.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

agentic-commerce A
io.bosonprotocol
MCP server for Boson Protocol — on-chain agentic commerce for physical & digital goods.
Blockchain E-commerce & Retail Autonomous Agents
632
runtime
com.formatho
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
Developer Tools Blockchain Security
1
modern-treasury A
io.usefulapi
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
Finance Payments & Billing
172
mcp-server A
com.blockscout
MCP server for Blockscout
Blockchain Web3 & Decentralized Tech Search
16244

Related MCP Servers

wallet-generator-mcp
Blockchain Web3 & Decentralized Tech
kukapay
A
license
B
quality
D
maintenance
An MCP server for batch-generating wallets compatible with Ethereum and all EVM-compatible chains.
Updated a year ago (2025-07-02 01:45 UTC)
1
1
MIT
base-escrow-mcp
Blockchain Cryptocurrency Finance
lordbasilaiassistant-sudo
A
license
A
quality
D
maintenance
MCP server for AI agents to create and manage P2P escrow deals on Base (ETH or ERC-20).
Updated 6 months ago (2026-03-07 14:35 UTC)
8
16
1
MIT
agent-insurance-mcp-server
Finance Autonomous Agents
AiAgentKarl
A
license
A
quality
D
maintenance
MCP server for AI agent transaction insurance and escrow — protect agent-to-agent payments with smart escrow, dispute resolution, and risk scoring.
Updated 5 months ago (2026-04-03 16:29 UTC)
11
MIT
pact-mcp
Autonomous Agents Finance Cryptocurrency
pact-layer
A
license
Not graded
quality
A
maintenance
MCP server for Pact, an escrow protocol for agent-to-agent commerce, enabling agents to create pacts, fund escrow, deliver work, and settle with an LLM evaluator as dispute backstop.
Updated 2 months ago (2026-07-15 11:06 UTC)
17
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/programmaman/dpay-mcp'

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