Which integrations are available for this server?

Provides a tool to look up whether a GitHub repository is likely to merge an AI-authored or external pull request, using stated AI/contribution policy and historical merge rates to produce a 0-100 score. Provides a tool to assess whether an npm package is safe to install, using registry metadata, install-script usage, OSV advisories, and typosquat risk to produce a 0-100 score. Provides a tool to assess whether a PyPI package is safe to install, using registry metadata, install-script usage, OSV advisories, and typosquat risk to produce a 0-100 score.

How do I use x402-tools?

1. Click on "Deploy 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., "@x402-tools Is the npm package lodash safe to install?" 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.

x402-tools

by vera-agent-dev

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

x402-tools

An MCP server that lets an AI agent pay, per call, for two small trust-signal lookups over the x402 protocol: is this npm/PyPI package safe to install, and will this GitHub repo actually merge an AI-authored or external pull request. The catalog and every price are read live from the seller API at call time — nothing here is hardcoded.

Built and operated by an AI agent, under a human owner

This tool was built by an AI coding agent (Claude), and the paid tools it calls run against a seller API that an AI agent may also autonomously pay and query. A human owner (the repository author) controls the wallet, the spending guard, and the seller side. Treat any output from these tools as a signal, not a guarantee — see "What this does not do" below.

Related MCP server: dyoe-agent-tools-mcp

Tools

Tool	Price	Answers
`list_products`	Free	The live product catalog: ids, paths, prices, input/output schemas.
`package_trust_check`	Fetched live via `list_products` (currently $0.05 USDC)	Is this npm/PyPI package safe to install? Registry metadata, install-script usage, OSV advisories, typosquat risk, 0-100 score.
`repo_merge_lookup`	Fetched live via `list_products` (currently $0.05 USDC)	Will this GitHub repo merge an AI-authored or external PR? Stated AI/contribution policy plus historical merge rates, 0-100 score.

Prices shown above are a snapshot at the time of writing and are never read by the code — always call list_products for the current catalog.

What this does not do

Scores are a heuristic signal built from public metadata (registry fields, advisory databases, repo history). They are not a security audit and not a guarantee that a package is safe or that a PR will merge. Use them as one input among several.

Install

npx (no local checkout)

{
  "mcpServers": {
    "x402-tools": {
      "command": "npx",
      "args": ["-y", "github:vera-agent-dev/x402-tools"],
      "env": {
        "X402_BASE_URL": "https://x402-api.fly.dev"
      }
    }
  }
}

Once published to npm, the same config works with "args": ["-y", "x402-tools"].

Local checkout

git clone https://github.com/vera-agent-dev/x402-tools
cd x402-tools
npm install
npm run build

{
  "mcpServers": {
    "x402-tools": {
      "command": "node",
      "args": ["/absolute/path/to/x402-tools/dist/index.js"],
      "env": { "X402_BASE_URL": "https://x402-api.fly.dev" }
    }
  }
}

Claude Code plugin

This repo ships .claude-plugin/plugin.json, so it installs like any other Claude Code plugin pointing at this GitHub repository.

Plain MCP JSON config

Any MCP-compatible client can use the .mcp.json in this repo directly, or copy its mcpServers.x402-tools block into your own client config.

.mcp.json is a tracked file. Its X402_BUYER_PRIVATE_KEY value is the literal string ${X402_BUYER_PRIVATE_KEY} — an env-var reference, not a real key — for clients that support that substitution. Never replace it with an actual private key and commit that. If your client doesn't support ${VAR} substitution in MCP config, set the env var in your own untracked client config instead of editing this file in place.

Payment flow

list_products is always free and always live — no wallet needed.
Calling a paid tool without X402_BUYER_PRIVATE_KEY set performs the request; on a 402 it returns the decoded challenge (amount, asset, network, payTo) as structured output, plus a short message on how to pay — either by setting the env var, or manually using the snippets in snippets/.
With X402_BUYER_PRIVATE_KEY set, the server wraps fetch with @x402/fetch + @x402/evm and pays automatically, then returns the result plus a payment block (amount, network, transaction hash).
A spending guard, X402_MAX_PRICE_USD (default 0.10), refuses to pay any single challenge above that amount and returns the challenge instead — the same as running with no key configured. This is enforced twice: a local pre-check on the accept matching your configured network, and (authoritatively) via the x402 client's own setSpendControls, which caps whatever accept it actually selects and signs — so a seller offering several accepts across networks/assets can't bypass the cap.

Environment variables

Variable	Default	Purpose
`X402_BASE_URL`	`https://x402-api.fly.dev` (TODO: confirm once deployed)	Base URL of the seller API.
`X402_BUYER_PRIVATE_KEY`	(unset)	Private key of the paying wallet. Omit to run in challenge-only mode.
`X402_NETWORK`	`eip155:8453` (Base)	CAIP-2 network id. Use `eip155:84532` for Base Sepolia testnet.
`X402_MAX_PRICE_USD`	`0.10`	Spending guard: max USD per single paid call.

Security: `X402_BUYER_PRIVATE_KEY`

This is your own wallet's private key, not this project's. Use a dedicated, low-balance wallet you top up only with what you're willing to spend automatically — never your main wallet. The key is read from the environment, used locally to sign payments via viem, and never logged or sent anywhere except as part of a signed x402 payment authorization. Paid tool arguments (e.g. the package name or repo you're looking up) are sent to the seller API as ordinary query parameters — don't pass anything sensitive.

Publishing (maintainer notes)

npm: package name x402-tools, npm publish once ready; update server.json and this README's npx snippet to drop the github: prefix.
MCP Registry: server.json follows the io.github.vera-agent-dev/x402-tools naming convention from the registry schema.

Dev / test

npm install
npm test          # vitest, mocks fetch — no network, no spend
npm run build      # tsc -> dist/
npm run dev        # tsx src/index.ts
npm run smoke      # end-to-end stdio smoke test against a running seller API

Open TODOs

X402_BASE_URL default (https://x402-api.fly.dev) is a placeholder until the seller API is actually deployed.
Not yet published to npm; install via npx github:vera-agent-dev/x402-tools until then.

License

MIT — see LICENSE.

Available Tools

3 tools

list_productsList x402 productsA

Free. Fetches the live product catalog from the x402-tools seller API (prices, ids and schemas are never hardcoded here).

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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It explicitly says 'Free', 'Fetches', and 'live'/'never hardcoded', communicating a read-only, dynamic data retrieval operation with no cost. It does not mention authentication, rate limits, or failure behavior, but for a zero-parameter public list this is acceptable.

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 zero wasted words. The 'Free' qualifier and the main action are front-loaded, and the parenthetical adds useful data-freshness detail without bloat. Every sentence earns its place.

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 tool with no annotations and no output schema, this description provides the core context: what is fetched, from where, that it is live, and that it is free. It mentions prices, ids, and schemas, giving the agent enough to interpret typical results. It could specify the exact response envelope, but the description is complete enough for the tool's simplicity.

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 is empty with 0 parameters, so the baseline of 4 applies. The description adds no parameter-level semantics, but none are needed because there are no inputs to document. There is no gap in parameter understanding.

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 uses a specific verb ('Fetches') and a specific resource ('live product catalog from the x402-tools seller API'), making the tool's purpose unmistakable. It also clarifies that prices, ids, and schemas are live rather than hardcoded. This clearly distinguishes it from unrelated siblings like package_trust_check and repo_merge_lookup.

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 implies the tool should be used when current product catalog data is needed, but it provides no explicit when-to-use or when-not-to-use guidance. It does not name any alternative tools or exclusion conditions. Since the siblings are clearly unrelated in purpose, the absence is minor, but usage is implied rather than stated.

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

package_trust_checkpackage_trust_checkA

Install-safety signals for an npm or PyPI package: registry metadata, install-script usage, OSV advisories, typosquat risk, and a 0-100 trust score. (price: $0.05 USDC per call) [catalog: bundled fallback, API was unreachable at startup]

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Package name
`ecosystem`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

There are no annotations, so the description carries the behavioral burden. It adds useful operational details: the $0.05 USDC cost and the catalog fallback caused by the API being unreachable at startup. Still, it doesn't state that the operation is read-only, how fresh the underlying data is, or how the trust score is calculated.

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 core purpose is front-loaded in a single sentence, followed by a concise list of outputs)Skip the score steps through the dialect so that it reads quickly. The operational parentheticals add relevant context without bloating the description.

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?

There is no output schema, so the description must explain return value shape. It lists the major output categories and the 0-100 trust score, which is enough to invoke the tool. It doesn't cover response format, unknown-package handling, or data-freshness limitations, leaving some post-call ambiguity.

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 schema already covers 'name' and provides an npm/pypi enum. The description repeats the ecosystem options but doesn't add meaningful parameter details beyond the schema. With two simple parameters and 50% schema coverage, this is adequate but not additive.

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?

Clearly specifies a concrete purpose: evaluating install-safety for npm or PyPI packages. Enumerates the signal categories and trust score, so an agent immediately knows what the tool does and how it differs from list_products and repo_merge_lookup.

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 'install-safety signals' framing implies this is meant for vetting a package before installation, and the ecosystem field narrows input. However, there is no explicit when-to-use vs alternatives language or conditions that would trigger choosing this tool over its siblings.

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

repo_merge_lookuprepo_merge_lookupA

Predicts whether a GitHub repository will merge an AI-authored or external pull request, based on its stated AI/contribution policy and historical merge rates. (price: $0.05 USDC per call) [catalog: bundled fallback, API was unreachable at startup]

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes	owner/name, e.g. facebook/react

TDQS

A3.5/5.0

Behavior2/5

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

Annotations are absent, so the description carries the full burden. It discloses the prediction method and notes the price and catalog fallback, but these are meta-information rather than functional behavior. It does not describe error handling, rate limits, side effects, or the nature of the output. This is minimal disclosure for a tool with no 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 is a single, focused sentence that leads with the core purpose. The parenthetical adds relevant operational details (price and fallback status) without bloat. Every element serves a purpose and the structure 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?

With one parameter and no output schema, the description should explain what the caller receives. It explains what is predicted and the basis, but does not specify the output format (e.g., boolean, probability, or detailed breakdown). This gap makes it adequate but not fully complete for a tool without an output schema.

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 schema provides a complete description of the single parameter 'repo' (owner/name format). The tool description does not add any further semantic detail beyond what the schema already states, so it meets the baseline for high schema 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 verb 'predicts' and the specific resource: whether a GitHub repository will merge an AI-authored or external pull request. It also mentions the basis (stated AI/contribution policy and historical merge rates). This is distinct from sibling tools (list_products and package_trust_check), which are unrelated in purpose.

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 implies when to use the tool — when you want to know a repo's merge likelihood for AI/external PRs — but it provides no explicit when-to-use/when-not-to-use guidance or mention of alternatives. Since the siblings are unrelated, this is acceptable but still lacks explicit routing.

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.

3 tool updatesv0.1.0Sep 17, 2026
- First observedlist_products
- First observedpackage_trust_check
- First observedrepo_merge_lookup

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-09-17 08:00 across 3 tools

Disambiguation5/5

Each tool addresses a completely distinct task: fetching product catalog, checking package trust, and predicting PR merges. There is zero functional overlap, so an agent would never confuse which tool to select.

Naming Consistency3/5

Naming mixes conventions: 'list_products' follows verb_noun, while 'package_trust_check' and 'repo_merge_lookup' are noun_verb (object+verb). All use underscores, but the verb placement is inconsistent, which slightly reduces predictability.

Tool Count4/5

With only 3 tools, the server is lean and each tool serves a clear, standalone purpose. The count is appropriate for a specialized utility server, though it borders on minimal.

Completeness4/5

The tools are independent utilities, not part of a lifecycle workflow, so there are no obvious missing CRUD operations. Each tool appears self-contained, though the domain is broad and could potentially support additional related functions (e.g., package details, repo history), but nothing critical is missing.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

blindoracleOAuth
io.github.craigmbrown
Trust layer for the x402 agent economy: 40 pay-per-call SKUs, USDC on Base, verifiable proofs.
Blockchain Finance Autonomous Agents
2
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
LimitGuard Trust Intelligence A
ai.limitguard.api
Entity verification, sanctions screening, and trust scoring for AI agents via x402 micropayments.
Security Autonomous Agents
521
Agentic Endpoints A
com.oliverkiss
Pay-per-call tools for autonomous agents, settled in USDC on Base via x402.
Autonomous Agents Payments & Billing Blockchain
201

Related MCP Servers

x402 MCP Payment
Blockchain Cryptocurrency App Automation
motok2031
F
license
Not graded
quality
C
maintenance
Enables AI agents to access paid content by integrating cryptocurrency payments through the x402 protocol, allowing LLMs to verify payments and retrieve paid resources automatically.
Updated 10 months ago (2025-11-23 10:16 UTC)
1
-
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 3 months ago (2026-07-01 10:19 UTC)
16
-
@hpp-io/x402-mcp-bridgeofficial
Cryptocurrency Autonomous Agents Payments & Billing
hpp-io
A
license
Not graded
quality
B
maintenance
Enables AI agents to autonomously pay for and discover services using HPP USDC.e over the x402 protocol, without API keys or manual signing.
Updated a month ago (2026-08-20 01:23 UTC)
88 npm
Apache 2.0
agent-toolkit-mcp
Developer Tools Blockchain Code Analysis
white-hat-lab
F
license
Not graded
quality
B
maintenance
Provides coding agents with 19 pay-per-call developer utilities, npm supply-chain security checks, and Base blockchain lookups, paid via USDC on Base using x402. No API key needed—payment acts as authentication.
Updated a month ago (2026-08-10 18:05 UTC)
26 npm
-

x402-tools

Built and operated by an AI agent, under a human owner

Tools

What this does not do

Install

npx (no local checkout)

Local checkout

Claude Code plugin

Plain MCP JSON config

Payment flow

Environment variables

Security: X402_BUYER_PRIVATE_KEY

Publishing (maintainer notes)

Dev / test

Open TODOs

Links

License

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

x402 MCP Payment

dyoe-agent-tools-mcp

@hpp-io/x402-mcp-bridgeofficial

agent-toolkit-mcp

Security: `X402_BUYER_PRIVATE_KEY`