Which integrations are available for this server?

Enables gasless USDC nanopayments via Circle Gateway, allowing AI agents to pay for API calls per request without needing an API key or account.

How do I use obol-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., "@obol-mcp Find a weather API and get the forecast for New York." 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.

obol-mcp

by superbigroach

Overview Schema Related Servers Score Discussions

TypeScript

Remote

MCP Registry

The MCP registry provides MCP clients with a list of MCP servers, like an app store for MCP servers.

📤 Publish my MCP server | ⚡️ Live API docs | 👀 Ecosystem vision | 📖 Full documentation

Development Status

2025-10-24 update: The Registry API has entered an API freeze (v0.1) 🎉. For the next month or more, the API will remain stable with no breaking changes, allowing integrators to confidently implement support. This freeze applies to v0.1 while development continues on v0. We'll use this period to validate the API in real-world integrations and gather feedback to shape v1 for general availability. Thank you to everyone for your contributions and patience—your involvement has been key to getting us here!

2025-09-08 update: The registry has launched in preview 🎉 (announcement blog post). While the system is now more stable, this is still a preview release and breaking changes or data resets may occur. A general availability (GA) release will follow later. We'd love your feedback in GitHub discussions or in the #registry-dev Discord (joining details here).

Current key maintainers:

Adam Jones (Anthropic) @domdomegg
Tadas Antanavicius (PulseMCP) @tadasant
Toby Padilla (GitHub) @toby
Radoslav (Rado) Dimitrov (Stacklok) @rdimitrov

Related MCP server: navi-x402-mcp

Contributing

We use multiple channels for collaboration - see modelcontextprotocol.io/community/communication.

Often (but not always) ideas flow through this pipeline:

Discord - Real-time community discussions
Discussions - Propose and discuss product/technical requirements
Issues - Track well-scoped technical work
Pull Requests - Contribute work towards issues

Quick start:

Pre-requisites

Docker
Go 1.24.x
ko - Container image builder for Go (installation instructions)
golangci-lint v2.4.0

Running the server

# Start full development environment
make dev-compose

This starts the registry at localhost:8080 with PostgreSQL. The database uses ephemeral storage and is reset each time you restart the containers, ensuring a clean state for development and testing.

Note: The registry uses ko to build container images. The make dev-compose command automatically builds the registry image with ko and loads it into your local Docker daemon before starting the services.

By default, the registry seeds from the production API with a filtered subset of servers (to keep startup fast). This ensures your local environment mirrors production behavior and all seed data passes validation. For offline development you can seed from a file without validation with MCP_REGISTRY_SEED_FROM=data/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION=false make dev-compose.

The setup can be configured with environment variables in docker-compose.yml - see .env.example for a reference.

Pre-built Docker images are automatically published to GitHub Container Registry. Note that the image does not bundle PostgreSQL, so you need to run your own and point the registry at it via MCP_REGISTRY_DATABASE_URL (see docker-compose.yml for a working example):

# Run latest stable release
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:latest

# Run latest from main branch (continuous deployment)
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:main

# Run specific release version
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:v1.0.0

# Run development build from main branch
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:main-20250906-abc123d

Available tags:

Releases: latest, v1.0.0, v1.1.0, etc.
Continuous: main (latest main branch build)
Development: main-<date>-<sha> (specific commit builds)

Publishing a server

To publish a server, we've built a simple CLI. You can use it with:

# Build the latest CLI
make publisher

# Use it!
./bin/mcp-publisher --help

See the publisher guide for more details.

Other commands

# Run lint, unit tests and integration tests
make check

There are also a few more helpful commands for development. Run make help to learn more, or look in Makefile.

Architecture

Project Structure

├── cmd/                     # Application entry points
│   └── publisher/           # Server publishing tool
├── data/                    # Seed data
├── deploy/                  # Deployment configuration (Pulumi)
├── docs/                    # Documentation
├── internal/                # Private application code
│   ├── api/                 # HTTP handlers and routing
│   ├── auth/                # Authentication (GitHub OAuth, JWT, namespace blocking)
│   ├── config/              # Configuration management
│   ├── database/            # Data persistence (PostgreSQL)
│   ├── service/             # Business logic
│   ├── telemetry/           # Metrics and monitoring
│   └── validators/          # Input validation
├── pkg/                     # Public packages
│   ├── api/                 # API types and structures
│   │   └── v0/              # Version 0 API types
│   └── model/               # Data models for server.json
├── scripts/                 # Development and testing scripts
├── tests/                   # Integration tests
└── tools/                   # CLI tools and utilities
    └── validate-*.sh        # Schema validation tools

Authentication

Publishing supports multiple authentication methods:

GitHub OAuth - For publishing by logging into GitHub
GitHub OIDC - For publishing from GitHub Actions
DNS verification - For proving ownership of a domain and its subdomains
HTTP verification - For proving ownership of a domain

The registry validates namespace ownership when publishing. E.g. to publish...:

io.github.domdomegg/my-cool-mcp you must login to GitHub as domdomegg, or be in a GitHub Action on domdomegg's repos
me.adamjones/my-cool-mcp you must prove ownership of adamjones.me via DNS or HTTP challenge

Community Projects

Check out community projects to explore notable registry-related work created by the community.

Available Tools

5 tools

depositDeposit to GatewayA

Fund the agent's Gateway balance once (gas-free spending afterward). Amount in USDC, e.g. '5'.

ParametersJSON Schema

Name	Required	Description	Default
`amount`	Yes	USDC amount to deposit, e.g. '5'

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`tx`	No
`error`	No
`deposited`	No

TDQS

A4.3/5.0

Behavior4/5

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

Annotations indicate a write operation (readOnlyHint=false) and non-destructive nature. The description adds value by noting the deposit is a one-time action that unlocks gas-free spending, and specifies the currency USDC, providing context beyond annotations.

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 concise sentences front-load the purpose and benefit, with no wasted words. Every sentence adds information.

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?

For a simple single-parameter tool with a clear output schema (though not shown), the description sufficiently covers purpose, parameter, and key behavioral outcome. No gaps.

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 description for the parameter 'Amount in USDC, e.g. '5'' adds marginal value beyond the schema's description which already covers the type and format. Schema description coverage is 100%, so baseline is 3.

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 verb 'Fund' and the resource 'agent's Gateway balance', with a unique benefit 'gas-free spending afterward'. It distinguishes from siblings like pay_and_call by being about adding funds rather than spending them.

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 implies use for initial funding with 'once (gas-free spending afterward)', but does not explicitly compare to siblings or state when not to use. However, the purpose is straightforward and the context signals provide sibling names for reference.

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

find_serviceFind a serviceA

Read-only

Search the Obol directory for metered APIs an agent can pay for per call. Results are relevance-ranked (name > category > description). Returns id, price (USDC), description, the callable URL, and a relevance score.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	max results to return (default 20)
`query`	No	what you need, e.g. 'crypto prices' or 'web scraper'

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`count`	Yes
`services`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=true. Description adds ranking details ('name > category > description') and return fields (id, price, description, URL, relevance score), providing useful behavior beyond annotations.

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, first states purpose and scope, second adds ranking and return fields. No unnecessary words, front-loaded with key information.

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 output schema exists, description covers search behavior, ranking, and return fields adequately. No missing context for a search tool with read-only semantics.

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 descriptions cover 100% of parameters. Description adds examples for query ('crypto prices') and states default limit (20), adding practical guidance beyond schema alone.

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?

Description clearly states 'Search the Obol directory for metered APIs an agent can pay for per call.' with specific verb 'Search' and resource 'Obol directory'. Distinguishes from sibling tools like list_service (likely listing all) and pay_and_call (execution after search).

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?

Implies usage for discovering metered APIs, but does not explicitly state when not to use or compare to siblings. Context is clear enough for an AI agent to infer its role in the workflow.

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

get_balanceGet balancesA

Read-only

Get the agent wallet + Gateway USDC balances on Arc testnet.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`error`	No
`address`	No
`walletUsdc`	No
`gatewayAvailableUsdc`	No

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, read-only operation. The description adds network context (Arc testnet) but no new behavioral traits beyond what annotations provide.

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 a single concise sentence that efficiently conveys the tool's purpose without any extraneous content.

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 zero parameters, presence of an output schema, and annotations covering safety, the description is complete. It sufficiently specifies what balances are retrieved and on which network.

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?

The tool has zero parameters, so the description adds no parameter-specific information. With 100% schema coverage (vacuously), a baseline score of 4 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 tool retrieves 'agent wallet + Gateway USDC balances on Arc testnet', specifying the verb, resource, and context. It naturally distinguishes from sibling tools like deposit and pay_and_call, which involve transactions.

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?

The description does not provide explicit guidance on when to use this tool versus alternatives. While the purpose is clear, it lacks mentions of exclusions or comparisons to sibling tools, limiting decision support for the agent.

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

list_serviceList a service for saleA

List (publish) a new service on the Obol marketplace so other agents can discover and pay for it. Requires the seller's Obol API key (OBOL_API_KEY env). Obol auto-issues a real ACK-ID verifiable credential for the seller's wallet and returns the marketplace URL.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	short service name, e.g. 'Crypto Price API'
`docsUrl`	No
`category`	No	e.g. Data, AI, Scraper, Tools
`hostedUrl`	Yes	the public https:// endpoint agents will call
`priceUsdc`	Yes	USDC price per call, e.g. '0.001'
`description`	No
`inputSchema`	No	input params, e.g. 'coin: string'
`skillMarkdown`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`error`	No
`ackDid`	No
`message`	No
`ackIssuer`	No
`marketplaceUrl`	No

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate it is not read-only, not destructive, and open-world. The description adds value by disclosing that Obol auto-issues a verifiable credential and returns the marketplace URL, clarifying side effects beyond what annotations provide.

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 two sentences with no wasted words. The purpose is front-loaded, and key details (API key, credential issuance, URL return) are provided efficiently.

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 has 8 parameters (3 required) and an output schema, the description covers the main purpose and side effects adequately. It could add more guidance on parameter usage, but the schema provides some descriptions.

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 63%, and the description adds no additional meaning to any parameter. It does not compensate for the missing schema descriptions, so the score is at the baseline of 3.

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 lists/publishes a new service on the Obol marketplace for discovery and payment, distinguishing it from sibling tools like find_service (search) and pay_and_call (consume). The verb 'list' and resource 'service' are specific.

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 mentions the prerequisite of the OBOL_API_KEY environment variable, providing clear context for when to use this tool. It does not explicitly exclude cases where alternatives are better, but the sibling tool names imply when to use each.

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

pay_and_callPay for and call a serviceA

Destructive

Pay for and call an Obol metered service via Circle Gateway. Enforces your per-call maxPrice and (with OBOL_API_KEY) your account's daily/weekly/monthly spending limits. Near-limit pays ask you to confirm. Idempotent on retry. Returns the result plus a signed, verifiable payment receipt.

ParametersJSON Schema

Name	Required	Description
`method`	No
`params`	No	query params to pass to the API
`callUrl`	Yes	the service's callUrl from find_service
`maxPrice`	No	max USDC to pay for this call (default 1.0)
`idempotencyKey`	No	reuse across retries; auto-generated if omitted

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`tx`	No
`data`	No
`paid`	No
`error`	No
`receipt`	No
`warning`	No
`declined`	No
`idempotencyKey`	No
`limitRemaining`	No
`responseSafety`	No
`receiptSignature`	No

TDQS

A3.5/5.0

Behavior1/5

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

The description claims 'Idempotent on retry,' but annotations state idempotentHint=false. This direct contradiction severely undermines transparency. Additionally, despite adding some behavioral context (payment receipt, limit enforcement), the contradiction is a critical failure.

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 4 sentences, front-loading the primary purpose. It could be slightly trimmed, but it efficiently covers key points.

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 presence of an output schema for return values, the description adequately covers the tool's behavior (idempotency, limits, confirmation, receipt). It is sufficiently complete for an agent to understand the tool's role.

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 high (80%) so baseline is 3. The description adds minimal value beyond schema: it mentions maxPrice enforcement and idempotency, but these are already implied by 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's purpose: paying for and calling an Obol metered service via Circle Gateway. It distinguishes from sibling tools (deposit, find_service, etc.) by combining payment and service invocation.

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 context on when to use: mentions enforcement of per-call maxPrice and account spending limits, and near-limit confirmation. However, it lacks explicit guidance on when not to use or alternatives to this tool.

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

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

All five tools have clearly distinct purposes: two for funding/balance (deposit, get_balance), two for using services (find_service, pay_and_call), and one for offering a service (list_service). No functional overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., find_service, pay_and_call). The convention is uniform and predictable.

Tool Count5/5

Five tools is well-scoped for the Obol marketplace domain. It covers the essential actions (funding, searching, paying, listing) without excess or deficiency.

Completeness4/5

The tool set covers the core workflows of funding, discovering, paying for, and listing services. However, it lacks tools for updating or deleting listed services, which could be a minor gap in lifecycle management.

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

run.pay B
io.github.PalabreX
Stripe-native marketplace where AI agents discover and pay per call for API services.
Payments & Billing Agent Orchestration
221
agentictrade A
io.github.miranttie
AI service marketplace — agents discover, call, and pay for API services automatically.
AI & Machine Learning Agent Orchestration Payments & Billing
522
Scrollport
com.scrollport
Verified, pay-per-use API tools for AI agents through one authenticated connection.
Agent Orchestration Developer Tools
1
x711 — Universal Agent Gas Station B
io.github.0580iris-lang
Pay-per-use tool API for AI agents. Free tier, x402 USDC micropayments, or API key.
AI & Machine Learning Payments & Billing
472

Related MCP Servers

@1ly/mcp-serverofficial
Blockchain Cryptocurrency Payments & Billing
1lystore
A
license
Not graded
quality
D
maintenance
Enables AI agents to discover, pay for, and sell APIs using crypto on Solana and Base networks, with support for automated x402 payments.
Updated 6 months ago (2026-03-05 15:10 UTC)
81
3
MIT
navi-x402-mcp
Cryptocurrency Weather Services Language Translation
mobileappbyharis
A
license
A
quality
F
maintenance
Enables AI agents to access paid tools like crypto prices, weather, translation, and web intelligence via per-request USDC payments on Base, with no API keys or subscriptions.
Updated 3 months ago (2026-06-11 10:07 UTC)
15
45
MIT
@arispay/payagent-mcpofficial
Cryptocurrency Payments & Billing
arispay-inc
A
license
A
quality
A
maintenance
Enables AI agents to call paid APIs and settle HTTP 402 payment challenges with USDC on Base, without private keys ever being involved.
Updated 7 days ago (2026-08-27 10:33 UTC)
7
911
MIT
x402-mcp
Blockchain Cryptocurrency Payments & Billing
nirholas
A
license
A
quality
C
maintenance
Enables AI agents to discover, inspect, and pay for paid HTTP and MCP services using USDC on Solana with a self-custodial wallet.
Updated 17 days ago (2026-08-17 02:58 UTC)
4
39
5
Inno Setup

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/superbigroach/obol-mcp'

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

MCP Registry

Development Status

Contributing

Quick start:

Pre-requisites

Running the server

Publishing a server

Other commands

Architecture

Project Structure

Authentication

Community Projects

More documentation

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@1ly/mcp-serverofficial

@arispay/payagent-mcpofficial

Latest Blog Posts

MCP directory API