What can you do with this server?

Use this MCP server to call SWARM’s paid x402 tools, paying per call in USDC on Base with no API key or account. * Run deterministic utilities ($0.02): UUIDs, hashes, base64 encode/decode, URL encode/decode, secure passwords, timestamp conversion. * Scan a public GitHub repo with code_health ($0.05): TODO/FIXME debt, oversized files, stray console.log, hardcoded-secret heuristics, README/.gitignore/LICENSE hygiene. Repos over 25 MB refused before payment. * Get a one-page live-web researched summary ($0.75) on a topic, with linked sources; typically 60–120s, allow 180s. * Get a full Markdown report ($0.99) on a topic, live-web researched with linked sources; typically 2–4 min, allow 360s. * Tools list and quote without SWARM_WALLET_KEY; SWARM_MAX_USD blocks calls above a set price before signing. Charged only on success.

Which integrations are available for this server?

Integrates with SWARM's x402-paid service shop, enabling agents to call paid tools such as code health scans, live-web summaries and reports, and utility operations, with per-call USDC payments on Base.

How do I use swarm-x402-mcp?

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., "@swarm-x402-mcp scan the GitHub repo expressjs/express for code health" 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.

swarm-x402-mcp

by swarm-agent-operator

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

swarm-x402-mcp

MCP server with paid tools: your agent pays per call in USDC on Base. No API key, no account.

MCP server for SWARM, an autonomous agent that sells small services over x402. Add it to Claude Code, Cursor, Claude Desktop or any MCP client. Your agent can then call SWARM's services and pay per call in USDC on Base. You need no account and no API key, and you are charged only when the service delivers.

Tools

Four tools. Each one calls SWARM's shop over the network and, with a wallet key, pays in USDC, so none is read-only; every tool declares this in its MCP annotations (readOnlyHint: false, openWorldHint: true):

Tool	What you send	What you get	Price
`code_health`	a public GitHub repo URL	static scan: TODO/FIXME debt, oversized files, secret heuristics, hygiene	$0.05
`summary`	a topic	one-page brief, researched on the live web, sources linked	$0.75
`report`	a topic	full Markdown report, researched on the live web, sources linked	$0.99
`utilities`	an operation (`uuid`, `hash`, `base64`, …)	UUIDs, hashes, base64, URL encoding, passwords, timestamps	$0.02

Related MCP server: thebuyside-x402-agent

Install

You need Node.js 20 or newer. Use a dedicated wallet holding only a few dollars of USDC on Base for SWARM_WALLET_KEY.

Claude Code

claude mcp add --transport stdio swarm --env SWARM_WALLET_KEY=0x… --env SWARM_MAX_USD=1 -- npx -y swarm-x402-mcp

Cursor (~/.cursor/mcp.json) and Claude Desktop (Settings → Developer → Edit Config)

{
  "mcpServers": {
    "swarm": {
      "command": "npx",
      "args": ["-y", "swarm-x402-mcp"],
      "env": {
        "SWARM_WALLET_KEY": "0x…",
        "SWARM_MAX_USD": "1"
      }
    }
  }
}

SWARM_WALLET_KEY: the private key of the wallet that pays. Without it, the tools still list and quote; they explain the price and don't pay.
SWARM_MAX_USD (default 1): the server refuses any call priced above this, before signing anything.

How payment works

Each call first reads SWARM's 402 quote without paying. It checks that the network is Base mainnet and that the price is under your limit. Then it pays with the official x402 client (@x402/fetch). SWARM verifies the payment, does the work, and settles only if the work succeeded.

Available Tools

4 tools

code_healthGitHub repo health scanA

Static scan of a public GitHub repo: TODO/FIXME debt, oversized files, secret heuristics, hygiene. Price: $0.05 per call. Calls SWARM's shop over the network and, with SWARM_WALLET_KEY set, pays in USDC on Base via x402 (the live quote is checked against SWARM_MAX_USD before paying; charged only on success).

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes	Public GitHub repo URL, e.g. https://github.com/owner/repo

TDQS

A3.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, openWorldHint=true and idempotency; the description goes well beyond that by disclosing price ($0.05/call), that it makes a network call to SWARM's shop, that SWARM_WALLET_KEY enables USDC payment on Base via x402, that the live quote is checked against SWARM_MAX_USD, and that charging occurs only on success. This is exactly the extra behavioral context an agent needs before triggering a paid, network-dependent call.

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?

Two sentences, front-loaded with purpose, then price and payment mechanics. Every clause carries information, though the second sentence packs several distinct facts (network call, wallet key, chain, protocol, price cap, billing condition) into one long run-on.

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?

Payment and execution semantics are covered thoroughly, but with no output schema the description never indicates what the scan returns (report format, findings structure, scoring). For a paid scan tool whose result the agent must interpret, that gap is a real omission.

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?

There is one parameter, fully documented in the schema (100% coverage) including a URL example. The description only reinforces the 'public GitHub' constraint and adds no syntax or format detail beyond what the schema already provides, so the baseline 3 applies.

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 gives a specific verb and resource ('Static scan of a public GitHub repo') and enumerates what is checked: TODO/FIXME debt, oversized files, secret heuristics, hygiene. That is far more informative than the name alone. It does not, however, differentiate this tool from its generic siblings (utilities, summary, report).

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?

Usage is implied by 'public GitHub repo' — the agent can infer the scope and that it must supply a repo URL. There is no explicit when-to-use / when-not-to-use guidance and no routing to or away from the sibling tools, leaving selection to inference.

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

reportFull web research reportA

A full Markdown report on a topic, researched on the live web at request time, sources linked. Price: $0.99 per call. Calls SWARM's shop over the network and, with SWARM_WALLET_KEY set, pays in USDC on Base via x402 (the live quote is checked against SWARM_MAX_USD before paying; charged only on success).

ParametersJSON Schema

Name	Required	Description
`topic`	Yes	What to research
`context`	No	Why you need it, or what you already know
`requirements`	No	Anything the result must cover

TDQS

A3.7/5.0

Behavior5/5

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

With annotations only covering hints (openWorld, non-idempotent, non-destructive), the description carries the real burden and does so well: it discloses the $0.99 per-call price, that it calls an external service over the network, that payment is USDC on Base via x402, that a wallet key is required, that the live quote is checked against SWARM_MAX_USD, and that charging happens only on success. These are exactly the side-effect and auth facts an agent needs before invoking a paid tool.

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?

Two sentences, front-loaded with the deliverable and format, followed by cost and payment mechanics; no filler. Slightly dense toward the end with payment plumbing, but every clause conveys actionable information.

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 paid network tool with no output schema, the description covers the return artifact (full Markdown report with linked sources), cost, auth, and billing semantics. It omits expected latency or failure/refund behavior, which would round it out, but nothing essential to correct invocation is missing.

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

Parameters3/5

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

Schema description coverage is 100% and all three parameters (topic, context, requirements) are documented in the schema, so the baseline of 3 applies. The description adds no further meaning about how 'context' or 'requirements' shape the report, but it does not need to.

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 states a concrete verb+resource: it produces a full Markdown research report on a topic, gathered from the live web with linked sources. That is specific and distinguishable from a plain summarizer, but it never explicitly contrasts itself with the sibling 'summary' tool, so sibling differentiation is only implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no explicit when-to-use / when-not-to-use guidance and no alternative tool is named, even though 'summary' is an obvious near-neighbor. The only conditional information is a payment prerequisite (SWARM_WALLET_KEY, SWARM_MAX_USD), which is behavioral rather than a selection guideline.

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

summaryOne-page web research briefA

A one-page brief on a topic, researched on the live web at request time, sources linked. Price: $0.75 per call. Calls SWARM's shop over the network and, with SWARM_WALLET_KEY set, pays in USDC on Base via x402 (the live quote is checked against SWARM_MAX_USD before paying; charged only on success).

ParametersJSON Schema

Name	Required	Description
`topic`	Yes	What to research
`context`	No	Why you need it, or what you already know
`requirements`	No	Anything the result must cover

TDQS

A3.9/5.0

Behavior5/5

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

The description discloses far more than the annotations: it makes a network call, requires SWARM_WALLET_KEY, costs $0.75 per call in USDC on Base via x402, checks the live quote against SWARM_MAX_USD before paying, and charges only on success. Preconditions, side effect, and billing semantics are all explicit.

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?

Front-loaded with the purpose in the first sentence, then price, then payment mechanics. The parenthetical is dense but each clause (wallet key, quote check, charge-on-success) carries distinct, decision-relevant information rather than padding.

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

Completeness4/5

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

With no output schema, the description still conveys the return shape (one-page brief, linked sources) and the key risk (paid call). Minor gaps remain: error/failure behavior, latency, and freshness of the live research are not addressed.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents topic, context, and requirements. The description adds no parameter-level meaning beyond that, which is the correct baseline of 3 when the schema does the heavy lifting.

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 states a specific deliverable ("a one-page brief on a topic"), how it's produced ("researched on the live web at request time"), and what comes back ("sources linked"). It is clear on its own, but it never distinguishes itself from the sibling "report", which could plausibly be confused with a research brief.

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?

Usage is only implied: an agent can infer it should call this when it needs a researched web brief. There is no explicit when-to-use versus alternatives (e.g. report), no when-not to call, and no guidance on reusing results to avoid repeat charges.

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

utilitiesSWARM utilitiesA

UUIDs, hashes, base64, URL encoding, secure passwords and timestamp conversion. Price: $0.02 per call. Calls SWARM's shop over the network and, with SWARM_WALLET_KEY set, pays in USDC on Base via x402 (the live quote is checked against SWARM_MAX_USD before paying; charged only on success).

ParametersJSON Schema

Name	Required	Description
`n`	No	How many to generate
`t`	No	Timestamp to convert
`op`	Yes	Operation, e.g. uuid, hash, base64, password, timestamp (see https://swarm-agent.net/openapi.json)
`algo`	No	Hash algorithm
`text`	No	Input text, for operations that take one
`length`	No	Password length

TDQS

A3.7/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing a concrete cost ($0.02/call), the network flow (calls SWARM's shop), the payment rail (USDC on Base via x402 gated on SWARM_WALLET_KEY), the spend guardrail (quote checked against SWARM_MAX_USD) and that charging occurs only on success. The annotations only flag openWorld/non-idempotent; the description supplies the financially material behavior an agent must know before invoking.

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?

Two sentences, front-loaded with the operation list and followed by the pricing/payment constraint; no filler. Slightly dense on payment mechanics but every clause carries decision-relevant information.

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 multi-op dispatcher with no output schema, the description covers the operation families and the non-obvious payment/guardrail behavior, and delegates op details to the referenced openapi.json. What is missing is which parameters apply to which op, but that is explicitly pointed to externally.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all six parameters and the baseline is 3. The description adds no per-parameter meaning beyond naming the operation families, leaving op-to-parameter mapping to the external openapi.json link.

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 first sentence enumerates the concrete operations (UUID, hash, base64, URL encoding, passwords, timestamps), so the agent knows what the tool produces despite the generic name 'utilities'. It does not differentiate itself from the unrelated siblings (code_health, summary, report), but those are clearly distinct domains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus the alternatives, nor prerequisites beyond the payment note. It tells the agent how billing works but not when the dispatcher is the right call.

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.

4 tool updatesv0.1.2Oct 7, 2026

Changedcode_health2 fields changed

addedInput schema / $schema

Added value: +"http://json-schema.org/draft-07/schema#"

changedInput schema / properties / repo / description

Previous value: -"Public GitHub repository URL, e.g. https://github.com/owner/name."New value: +"Public GitHub repo URL, e.g. https://github.com/owner/repo"

Changedreport5 fields changed

addedInput schema / $schema

Added value: +"http://json-schema.org/draft-07/schema#"

changedInput schema / properties / context / description

Previous value: -"Optional background you already have."New value: +"Why you need it, or what you already know"

changedInput schema / properties / requirements / description

Previous value: -"Optional format or angle to follow."New value: +"Anything the result must cover"

changedInput schema / properties / topic / description

Previous value: -"What to research."New value: +"What to research"

removedInput schema / properties / topic / minLength
```
Removed value: -1
```

Changedsummary5 fields changed

addedInput schema / $schema

Added value: +"http://json-schema.org/draft-07/schema#"

changedInput schema / properties / context / description

Previous value: -"Optional background you already have."New value: +"Why you need it, or what you already know"

changedInput schema / properties / requirements / description

Previous value: -"Optional format or angle to follow."New value: +"Anything the result must cover"

changedInput schema / properties / topic / description

Previous value: -"What to research."New value: +"What to research"

removedInput schema / properties / topic / minLength
```
Removed value: -1
```

Changedutilities13 fields changed

addedInput schema / $schema

Added value: +"http://json-schema.org/draft-07/schema#"

changedInput schema / properties / algo / description

Previous value: -"Hash algorithm (op=hash). Default sha256."New value: +"Hash algorithm"

changedInput schema / properties / length / description

Previous value: -"Password length (op=password). Default 16."New value: +"Password length"

changedInput schema / properties / length / maximum

Previous value: -128New value: +9007199254740991

changedInput schema / properties / length / minimum

Previous value: -4New value: +-9007199254740991

changedInput schema / properties / n / description

Previous value: -"How many UUIDs (op=uuid). Default 1."New value: +"How many to generate"

changedInput schema / properties / n / maximum

Previous value: -100New value: +9007199254740991

changedInput schema / properties / n / minimum

Previous value: -1New value: +-9007199254740991

changedInput schema / properties / op / description

Previous value: -"Which utility to run. Anything other than the listed ones is treated as `timestamp`."New value: +"Operation, e.g. uuid, hash, base64, password, timestamp (see https://swarm-agent.net/openapi.json)"

removedInput schema / properties / op / enum

Removed value: -[
-  "uuid",
-  "hash",
-  "base64-encode",
-  "base64-decode",
-  "url-encode",
-  "url-decode",
-  "password",
-  "timestamp"
-]

changedInput schema / properties / t / description

Previous value: -"The timestamp to convert (op=timestamp)."New value: +"Timestamp to convert"

changedInput schema / properties / t / type

Previous value: -"string"New value: +[
+  "string",
+  "number"
+]

changedInput schema / properties / text / description

Previous value: -"The input for hash, base64-* and url-*."New value: +"Input text, for operations that take one"

4 tool updatesv0.1.0Oct 5, 2026
- First observedcode_health
- First observedreport
- First observedsummary
- First observedutilities

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-10-07 09:55 across 4 tools

Disambiguation4/5

Each tool targets a different service: miscellaneous utilities, repo code scanning, web research brief, and web research report. Summary and report overlap in that both do live web research, but the one-page brief versus full Markdown report distinction is clear from descriptions and pricing.

Naming Consistency4/5

All names are lowercase noun-style labels, which is consistent enough for this service-catalog style server. The only minor deviation is code_health using an underscore while the others are single words, but this remains predictable and readable.

Tool Count4/5

Four tools is a reasonable, compact surface for a paid service aggregator where each tool maps to a distinct offering. It is slightly thin, but no tool feels redundant or out of scope.

Completeness3/5

The tools cover four concrete paid operations, but the surface lacks supporting operations for a payment-oriented server, such as checking wallet balance, previewing quotes, or querying transaction status. Agents can perform the main calls, but dead ends around payment state and service discovery remain.

Maintenance

ActivityNo data

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Fatstack A
net.fatstack
Paid MCP tools behind one endpoint. Agents pay per call in USDC on Base via x402.
Payments & Billing Web3 & Decentralized Tech
151
mcp-server A
io.github.apihubio
Discover and pay for APIs with USDC credits. No wallet, no gas, MCP-native marketplace.
Cryptocurrency Payments & Billing
92
AIPP Monetize A
dev.aipp
Pay-per-action access to APIs and MCP tools over Lightning L402 and Base USDC x402.
Payments & Billing Cryptocurrency Blockchain
31
WORKMINE A
io.github.Tamerlan0606
x402 pay-per-call APIs over MCP, settled in USDC on Base for autonomous agents and developers.
Blockchain Cryptocurrency Payments & Billing
81

Related MCP Servers

monospay-mcpofficial
Cryptocurrency Blockchain Payments & Billing
monospay
A
license
Not graded
quality
D
maintenance
Pay per MCP tool call in USDC on Base. Non-custodial settlement, no admin keys, 30 bps fee.
Updated 6 months ago (2026-04-13 21:56 UTC)
MIT
thebuyside-x402-agent
Blockchain Cryptocurrency Payments & Billing
jaysperspective
A
license
A
quality
D
maintenance
The MCP gateway that lets any AI agent discover and pay metered APIs on Base or Solana — without the user wiring payments themselves.
Updated 22 days ago (2026-09-17 11:45 UTC)
3
17 npm
1
Apache 2.0
x402-gateway-mcp
Cryptocurrency Payments & Billing
Marysbrain
A
license
A
quality
F
maintenance
Enables MCP clients to access all endpoints of an x402 gateway by paying real-time microtransactions (USDC on Base) per API call, with automatic tool discovery and spend guardrails.
Updated a month ago (2026-09-04 00:35 UTC)
23
60 npm
MIT
GlianaAI MCP Serverofficial
AI & Machine Learning Image & Video Processing Audio Processing
Gliana-Labs
A
license
A
quality
B
maintenance
Enables pay-per-call access to 90+ generative AI models and utility tools via any MCP client, with no signup or API key, using wallet-based USDC payments on Base, Tempo, or Solana.
Updated 16 days ago (2026-09-23 09:10 UTC)
7
73 npm
MIT

swarm-x402-mcp

Tools

Install

How payment works

Links

Available Tools

TDQS

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

monospay-mcpofficial

thebuyside-x402-agent

x402-gateway-mcp

GlianaAI MCP Serverofficial