What can you do with this server?

This server provides read-only discovery tools for exploring and onboarding to the Hermes Plant Agent Commerce Assurance platform before making paid API calls. Capabilities: * Fetch the x402 Payment Manifest (hermesplant_x402_manifest): Retrieve the live x402 manifest to discover the active network, USDC asset details, facilitator URL, payTo address, endpoint prices, and payment-policy metadata. * Fetch the LLMs Catalog (hermesplant_llms_catalog): Access the agent-readable /llms.txt catalog covering all available deterministic finance, quant, safety, and payment-policy services. * Fetch the API Catalog (hermesplant_api_catalog): Retrieve the RFC 9727-style machine-readable API catalog including OpenAPI links, MCP metadata links, pricing metadata, and provider contact details. * Fetch the Hosted MCP Server Card (hermesplant_mcp_server_card): Get the hosted MCP server descriptor to discover the Streamable HTTP MCP endpoint, advertised capabilities, pricing policy, and integration metadata. * List Hosted Tools (hermesplant_list_hosted_tools): Introspect the hosted MCP endpoint to list all advertised tool names, descriptions, and input schemas before wiring up an x402-capable runtime. ⚠️ Note: All five tools are strictly read-only — none sign wallet messages, approve transactions, invoke paid endpoints, or spend USDC. They expose the discovery layer needed to prepare for interacting with Hermes Plant's paid services.

Which integrations are available for this server?

Demonstrates a finance-agent crew that uses Hermes Plant endpoints within the CrewAI framework. Provides a shell-based example for making Hermes Plant API calls with the x402 payment handshake, useful for inspecting the payment flow. Shows a LangChain Tool wrapper that enables Hermes Plant API calls in LangChain-based agents. Provides a Python example using the x402 package to integrate with Hermes Plant's deterministic finance APIs. Offers a TypeScript example using x402-fetch and the MCP SDK to call Hermes Plant endpoints programmatically.

How do I use Hermes Plant — Agent Commerce Assurance?

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., "@Hermes Plant — Agent Commerce Assurance Compute Black-Scholes price for AAPL call option with strike $150, 30 days to expiry." 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.

Hermes Plant — Agent Commerce Assurance

by JesseGdotIO

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Hermes Plant MCP Server

Glama score

Runnable MCP server and integration examples for Hermes Plant, the Agent Commerce Assurance layer that lets AI agents preflight, approve, and prove consequential actions. Start with a one-cent action-safety check, route only high-risk actions into signed review evidence, and pay per call over x402.

What's here: a runnable stdio MCP bridge for registry crawlers and local clients, plus drop-in examples in curl, TypeScript, Python, CrewAI, LangChain, and MCP client configs for Claude Desktop / Cline / Cursor.

Install the Action Safety skill

Install the public, fail-closed Action Safety skill for Codex, Claude Code, Cursor, and other Agent Skills-compatible clients:

npx skills@1.5.18 add JesseGdotIO/hermesplant-mcp-server --skill protect-agent-action

The skill calls the one-cent quick gate before an exact consequential action, binds the result to that unchanged action, and escalates high or critical risk only when the additional $0.25 is authorized. Review triage is never treated as human approval and the skill never expands the caller's permissions.

Source: skills/protect-agent-action · Install guide and trust boundary

Related MCP server: dyoe-agent-tools-mcp

Use the hosted MCP connector

For the complete production tool surface, use the canonical Hermes Plant — Agent Commerce Assurance connector on Glama. It exposes Action Safety, Spend Assurance, signed evidence, payment-policy checks, and the component x402 tools through the live Streamable HTTP endpoint.

This repository is the portable, no-secret discovery bridge. It lets registry crawlers and local clients inspect the live catalog and payment contracts without signing a wallet message or spending funds. The hosted connector is the buyer-facing path for invoking the production tools.

Glama registry

Hermes Plant MCP Server Glama card

This repo is arranged for Glama to build and inspect the MCP server without secrets or funded wallets:

glama.json declares the GitHub maintainer.
The root Dockerfile starts the stdio MCP server in mcp-server/.
npm run smoke:mcp lists all local MCP tools and fetches the live x402 manifest.
GitHub Actions validates the MCP server, Docker image, shell examples, and no-spend TypeScript/Python client contracts with their real dependencies.

A Glama release is still an account-side action, not a GitHub release. After claiming the server in Glama, use the Dockerfile admin page to deploy the build, wait for the build test to pass, then publish a Glama release version. That release unlocks Glama's Server Coherence and Tool Definition Quality scoring.

Complementary MCP servers

Hermes Plant governs consequential actions and payments; these independent servers cover adjacent layers of an agent stack:

SINT Protocol — capability authorization and policy enforcement before execution.
AgentPay MCP — non-custodial wallet execution with spend limits and approval queues.
Agent Security Scanner MCP — repository, package, prompt, and skill security scanning.

These links describe functional complementarity, not partnerships or endorsements.

Start with an assurance workflow

Workflow	Use it for	Tracked entrypoint
Action Safety	Preflight shell, Git, SQL, deploy, x402, and MCP actions; escalate high-risk work into review plus a signed receipt.	Open workflow
Spend Assurance	Check payment policy, wallet context, and evidence before an agent spends.	Open workflow
Investment Evidence	Run deterministic underwriting and return verifiable evidence in one paid call.	Open workflow

Use the free API key for up to 250 calls/month, the $29/month Agent API Pass for regular volume, or per-call USDC on Base. Public proof and machine-readable contracts are available at hermesplant.com/proof and hermesplant.com/openapi.json.

Component catalog

Nineteen hosted x402 endpoints remain available as composable utilities:

Endpoint	Use it for	Hosted path
DealAnalyzer	DCF, IRR, XIRR, NPV	/agent-services/dealanalyzer
Waterfall	LP/GP private-equity distribution waterfalls	/agent-services/waterfall
Options	Black-Scholes pricing + Greeks	/agent-services/options
Bond	Yield, duration, convexity	/agent-services/bond
CashflowLens	Cash-flow projection + sensitivity	/agent-services/cashflowlens
PortfolioGuard	Portfolio risk scoring	/agent-services/portfolioguard
WalletGuard	Wallet AML + sanctions screening	/agent-services/walletguard
EmailGuard	Email reputation + risk	/agent-services/emailguard
DestructGuard	Block destructive AI-agent commands	/agent-services/destructguard
MCP risk	Score MCP server risk before connecting	/agent-services/mcp-risk
Evidence	Evidence bundle for paid calls	/agent-services/evidence
Payment policy	Inspect/score an x402 payment policy	/agent-services/payment-policy
ReviewQueue	Human-in-the-loop approval routing	/agent-services/reviewqueue

Agents discover endpoints through OpenAPI, llms.txt, the x402 manifest, the API catalog, MCP metadata, or agent skills. The workflow links above carry source-specific attribution so registry traffic can be evaluated against paid calls instead of impressions.

How an x402 call works

Client                    Hermes Plant                 Facilitator
  |                            |                            |
  | POST /endpoint             |                            |
  |--------------------------->|                            |
  | 402 Payment Required       |                            |
  | + PAYMENT-REQUIRED         |                            |
  |<---------------------------|                            |
  | sign payment locally       |                            |
  | POST /endpoint             |                            |
  | + PAYMENT-SIGNATURE        |                            |
  |--------------------------->| verify signature           |
  |                            |--------------------------->|
  |                            | ok                         |
  |                            |<---------------------------|
  | 200 OK + result            | settle payment             |
  |<---------------------------|--------------------------->|

Client makes an HTTP request.
Server replies with 402 Payment Required plus a PAYMENT-REQUIRED header carrying the price, network, asset, recipient, and timeout.
Client parses the challenge, signs a USDC transfer authorization locally, and replays the request with a PAYMENT-SIGNATURE header.
Server verifies the signature via the facilitator, runs the work, settles the payment on-chain, and returns 200 OK with the result plus a PAYMENT-RESPONSE header.

The full spec lives at github.com/x402-foundation/x402.

Discovery surfaces

These let any agent or human self-onboard without help:

hermesplant.com/llms.txt - agent-readable catalog
hermesplant.com/openapi.json - full OpenAPI 3.1
hermesplant.com/.well-known/x402 - x402 manifest with facilitator, network, asset, prices, and payTo metadata
hermesplant.com/.well-known/api-catalog - RFC 9727-style API catalog
hermesplant.com/.well-known/mcp/server-card.json - MCP server descriptor
hermesplant.com/mcp - Streamable HTTP MCP endpoint

MCP tools in this repo

The runnable stdio server exposes five read-only discovery tools:

Tool	Purpose
`hermesplant_x402_manifest`	Fetch the live x402 manifest before paid calls.
`hermesplant_llms_catalog`	Fetch the agent-readable `llms.txt` catalog.
`hermesplant_api_catalog`	Fetch the machine-readable API catalog.
`hermesplant_mcp_server_card`	Fetch the hosted MCP server descriptor.
`hermesplant_list_hosted_tools`	Introspect the hosted Streamable HTTP MCP endpoint and list its advertised tools.

These local tools do not sign wallet messages, approve transactions, call paid endpoints, or spend USDC. They expose the discovery layer that clients need before invoking paid hosted tools.

Quickstart

Pick the runtime that matches your stack:

Runtime	Folder	Notes
`curl` / Bash	curl/	Pure shell; useful for inspecting the 402 handshake
TypeScript	typescript/	Uses `@x402/fetch` + `@modelcontextprotocol/sdk`
Python	python/	Uses the `x402` package
CrewAI	crewai/	Finance-agent crew calling Hermes endpoints
LangChain	langchain/	LangChain `Tool` wrapping Hermes
MCP config	mcp-config/	One-paste config for Claude Desktop / Cline / Cursor
MCP server	mcp-server/	Runnable stdio MCP bridge for discovery, server-card inspection, and hosted-tool listing

Run the MCP server locally

npm install
npm run smoke:mcp
npm start

MCP server registry build

This repo includes a root glama.json and root Dockerfile for MCP registry crawlers:

docker build -t hermesplant-mcp-server .
docker run --rm -i hermesplant-mcp-server

The container starts the stdio MCP bridge in mcp-server/, which exposes Hermes Plant discovery tools and hosted MCP metadata without requiring API keys.

Wallet setup

The guarded paid-call examples require:

A funded wallet on Base mainnet with chain id 8453.
Enough USDC for the selected endpoint and a small amount of ETH for gas.
EVM_PRIVATE_KEY plus the explicit opt-in HERMES_ALLOW_PAYMENT=1.

The included CashflowLens clients cap payment requirements at $0.20 USDC and register only Base mainnet. Leave the opt-in unset for imports and tests. Never commit a private key. These production examples do not claim testnet support; use an x402 test resource server for testnet integration work.

Status

These examples target the production deployment at hermesplant.com. Endpoint signatures may evolve, so cross-reference openapi.json and the /.well-known/x402 manifest before going to production.

Contributing

Issues and PRs welcome. New runtime? New framework? Open a PR with one working example and a tight README.

License

MIT - see LICENSE.

Available Tools

5 tools

hermesplant_api_catalogA

Read-onlyIdempotent

Inspect

Fetches Hermes Plant's RFC 9727-style API catalog from /.well-known/api-catalog. Use this when a client needs machine-readable service discovery, OpenAPI links, MCP metadata links, pricing metadata, and provider contact details. This read-only tool returns raw JSON text and performs no paid API calls.

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?

Discloses read-only nature, no paid API calls, and returns raw JSON text. Adds value beyond annotations (e.g., well-known URL, no cost). Consistent with readOnlyHint and idempotentHint.

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 defines purpose, second provides usage and behavioral notes. No wasted words, front-loaded with key action.

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 zero-parameter, no-output-schema tool, description covers key aspects: endpoint, content, and cost. Could elaborate on response structure, but sufficient for basic selection.

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?

No parameters; schema coverage is 100% trivially. Description correctly omits parameter details. Baseline score of 4 for zero-parameter tool.

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 verb 'fetches', resource 'RFC 9727-style API catalog from /.well-known/api-catalog', and scope (machine-readable service discovery, OpenAPI links, etc.). Differentiates from siblings by specifying its unique output.

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 when to use ('when a client needs machine-readable service discovery...'). Does not list alternatives or when not to use, but context is clear given sibling tools serve different purposes.

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

hermesplant_list_hosted_toolsA

Read-onlyIdempotent

Inspect

Connects to Hermes Plant's hosted Streamable HTTP MCP endpoint and lists the tools it advertises. Use this to inspect tool names, descriptions, and input schemas before wiring an x402-capable runtime. This read-only introspection call does not invoke paid tools, sign wallet messages, approve payments, or spend USDC.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds 'does not invoke paid tools, sign wallet messages, approve payments, or spend USDC,' providing concrete behavioral boundaries that are not in 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 precise sentences, no redundancy. First sentence states core purpose, second adds usage context and behavioral implications. Every sentence justifies its existence.

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 no output schema and rich annotations, description fully covers purpose, usage, and behavioral traits. Mentions endpoint type (Streamable HTTP MCP) for additional context.

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?

No parameters in schema (100% coverage). Description does not need to add parameter info; baseline 4 applies.

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 it lists tools from Hermes Plant's hosted endpoint, distinguishing it from sibling catalog tools that serve different purposes. Verb 'list' and resource 'hosted tools' 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 Guidelines5/5

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

Explicitly says 'Use this to inspect tool names, descriptions, and input schemas before wiring an x402-capable runtime.' Also lists what it does not do, helping agents avoid misuse.

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

hermesplant_llms_catalogA

Read-onlyIdempotent

Inspect

Fetches Hermes Plant's /llms.txt catalog for agent-readable onboarding context. Use this to understand the available deterministic finance, quant, safety, and payment-policy services before selecting an endpoint. This read-only tool returns plain text documentation and does not execute paid work.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds 'returns plain text documentation and does not execute paid work', which is valuable behavioral context beyond the 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?

The description consists of two short, front-loaded sentences with no redundant information. Every sentence adds value: first states the action, second provides usage and behavior.

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 read-only tool with no parameters and no output schema, the description fully covers what the tool does (returns plain text documentation) and its purpose (onboarding context). No gaps.

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?

There are zero parameters, so baseline score is 4. The description does not need to add parameter meaning since there are none.

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?

The description clearly states it fetches the /llms.txt catalog for onboarding context. It specifies the purpose: 'to understand the available deterministic finance, quant, safety, and payment-policy services'. While it doesn't explicitly differentiate from siblings, the usage context is clear.

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 usage guidance: 'Use this to understand the available ... services before selecting an endpoint.' This tells the agent when to use it. It doesn't mention when not to use or alternatives, but the context is sufficient.

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

hermesplant_mcp_server_cardA

Read-onlyIdempotent

Inspect

Fetches Hermes Plant's MCP server descriptor from /.well-known/mcp/server-card.json. Use this to discover the hosted Streamable HTTP MCP endpoint, advertised capabilities, pricing policy, and integration metadata. This read-only tool returns raw JSON text and does not connect to a wallet or spend funds.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds value by specifying the return format ('raw JSON text') and financial safety ('does not connect to a wallet or spend funds'), going 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 concise (two sentences), front-loaded with the action, and every sentence adds necessary information without redundancy.

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 no parameters and no output schema, the description fully explains its purpose, return value, and safety characteristics. There are no gaps in understanding how to use the tool.

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 input schema has zero parameters, so the baseline is 4. The description does not need to add parameter semantics as there are none.

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 ('Fetches Hermes Plant's MCP server descriptor') and the resource ('/.well-known/mcp/server-card.json'). It distinguishes from sibling tools like hermesplant_llms_catalog by specifying the exact endpoint and its purpose.

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 explains when to use the tool: 'Use this to discover the hosted Streamable HTTP MCP endpoint, advertised capabilities, pricing policy, and integration metadata.' It also notes it is read-only and does not spend funds, but lacks explicit when-not or alternative tools.

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

hermesplant_x402_manifestA

Read-onlyIdempotent

Inspect

Fetches Hermes Plant's live x402 manifest from /.well-known/x402. Use this before paid API or MCP calls to discover the active network, USDC asset, facilitator URL, payTo address, endpoint prices, and payment-policy metadata. This read-only tool returns raw JSON text and never signs payments, approves wallet transactions, calls paid endpoints, or spends funds.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description goes beyond by explicitly confirming it returns raw JSON text and never performs payment-related actions. No contradictions.

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 no wasted words. The purpose and behavioral constraints are front-loaded. Every sentence adds value.

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 no output schema, the description explains the content of the returned data (network, asset, facilitator, etc.) and the tool's read-only nature. It fully covers the necessary context for a no-parameter 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 has zero parameters with 100% coverage via description. The description does not add parameter-level meaning since there are none, which is acceptable. Baseline of 3 applies.

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 fetches the live x402 manifest from a specific well-known endpoint. It uses specific verbs ('Fetches... manifest from...') and resource naming, which is distinct from sibling tools that list hosted tools or catalogs.

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?

Explicitly states when to use: 'Use this before paid API or MCP calls'. Also clarifies what it does not do: 'never signs payments, approves wallet transactions, calls paid endpoints, or spends funds'. This provides clear guidance on appropriate usage.

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.3/5.0

Disambiguation5/5

Each tool fetches a distinct piece of metadata (llms.txt, API catalog, server card, hosted tools, x402 manifest) with no functional overlap, so an agent can clearly differentiate them.

Naming Consistency5/5

All tools follow the consistent pattern 'hermesplant_<resource>', using lowercase snake_case throughout, making the naming predictable and uniform.

Tool Count4/5

Five tools is a reasonable number for a discovery-oriented server, though the set covers only introspection and no actual domain operations, which slightly reduces appropriateness.

Completeness2/5

The tool set lacks any tools for the purported domain (finance, quant, safety, payment-policy), providing only discovery metadata. Agents cannot perform any actual actions, leaving significant gaps.

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

Vibe Springs A
net.vibesprings
Pay-per-use weather, environment, finance, and on-chain intelligence tools for AI agents via x402.
Weather Services Finance Blockchain
252
Polyform A
org.polyform
Pay-per-call data APIs for AI agents. USDC on Base via x402. 33 tools, no signup.
Cryptocurrency AI & Machine Learning
501
Concierge Intel B
xyz.conc-exe
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Finance Blockchain
202
DDG Agent Services B
io.github.daedalusdevelopmentgroup
Pay-per-call x402 gateway: agent tools, OpenAI-compatible LLM, market data, RPC, security audits.
Payments & Billing Agent Orchestration
262

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)
160
3
MIT
dyoe-agent-tools-mcp
Autonomous Agents Cryptocurrency Web Scraping
bjyoe2016
F
license
A
quality
C
maintenance
Pay-per-call tools for AI agents including trust checks, due diligence, market data, and human-verified approvals, settled in USDC on Base via the x402 protocol.
Updated 2 months ago (2026-07-01 10:19 UTC)
16
boo-x402-mcp
Blockchain Web3 & Decentralized Tech Cryptocurrency
lucle87
A
license
A
quality
C
maintenance
Enables AI agents to access crypto/web3 data across 5 chains with pay-per-call billing in USDC via x402, no API key required, and built-in spend caps.
Updated 2 months ago (2026-07-12 08:26 UTC)
36
47
MIT
kerdos-x402-mcp
Cryptocurrency Finance
Singlishman
A
license
Not graded
quality
D
maintenance
Exposes Kerdos Market Intelligence APIs as tools for AI trading agents, with pay-per-call in USDC via the x402 protocol—no API keys or subscriptions required.
Updated 4 months ago (2026-04-27 11:11 UTC)
60
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/JesseGdotIO/hermesplant-mcp-server'

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

Hermes Plant MCP Server

Install the Action Safety skill

Use the hosted MCP connector

Glama registry

Complementary MCP servers

Start with an assurance workflow

Component catalog

How an x402 call works

Discovery surfaces

MCP tools in this repo

Quickstart

Run the MCP server locally

MCP server registry build

Wallet setup

Status

Contributing

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@1ly/mcp-serverofficial

Latest Blog Posts

MCP directory API