Skip to main content
Glama
pgalyen1987

mcp-gate402

by pgalyen1987
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

gate402-mcp

x402 trust

MCP server for Gate402 — pay-per-call agent APIs over HTTP 402 (x402 / USDC on Base). Gives any MCP client a full toolkit with no signup and a free tier on first runs — GPU/CPU compute, open-model LLM inference, a GPU marketplace, a complete Base trading loop (discover → vet → read → execute), and web tools:

Tool

What it does

Price

gate402_infer

Open-model LLM inference (Llama 3.1 8B/70B, Qwen 2.5, Mistral); billed on actual tokens, signed usage receipt

per-token (from $0.05/1M in)

gate402_compute

Rent metered GPU/CPU to run a container job; signed execution receipt

per-second

gate402_scrape

Fetch any public URL, render JS, strip nav/ads → clean LLM-ready Markdown

$0.002

gate402_scrape_stealth

Cloudflare/anti-bot fetch via residential proxies + CAPTCHA solving → clean Markdown

$0.05

gate402_minify

Compress text to cut downstream LLM token spend (~40%)

$0.005 / 10k tok

gate402_dedup

Semantic vector-cache lookup (exact + cosine)

$0.001 hit / $0.003 miss

gate402_onchain

On-chain wallet/token intel on Base (balances, EOA/contract, tx count, token metadata)

$0.01

gate402_dex

Live DEX price / liquidity / 24h volume for a Base token

$0.01

gate402_news

Recent news headlines + bull/bear sentiment for a ticker/topic

$0.02

gate402_edgar

Latest SEC EDGAR filings (10-K/10-Q/8-K) for a US ticker

$0.02

gate402_token_risk

Rug/tradeability verdict for a Base token (score + SAFE/CAUTION/AVOID; liquidity, honeypot sim, holder concentration)

$0.03

gate402_momentum

Momentum + order-flow signal for a Base token (RISING/FALLING + ACCUMULATION/DISTRIBUTION, honeypot-gated)

$0.02

gate402_best_swap

Best-execution intel: which DEX pool + estimated price impact for a trade size

$0.02

gate402_launches

Radar of the freshest Base token launches, lightly pre-screened

$0.02

…plus three free tools that run locally in this process (pure compute — no payment, no key, no network):

Tool

What it does

gate402_token_count

Estimate the token count of a string (budget your context window)

gate402_html_to_md

Convert an HTML string you already have into clean Markdown

gate402_json_repair

Coerce malformed / LLM-mangled JSON into valid JSON

GPU marketplace

Gate402 also routes to third-party GPU/compute providers with escrow-on-success — the buyer is charged only if the provider delivers. Providers keep 85% of each call, paid out on-chain in USDC on Base.

Tool

What it does

gate402_market_infer

LLM inference via the marketplace, routed to the cheapest healthy provider. x402-native (settles on-chain per call — needs an x402 client, not the free-tier key)

gate402_providers

Free. Browse active providers — model, per-call price, reliability

gate402_become_provider

Free. List your own GPU and earn 85%/call — returns the exact sign-message + registration request

How billing works

On first use the server self-claims a free-credit API key from Gate402 and caches it at ~/.gate402-mcp/key.json. Calls draw down that credit. When it runs out, tools return a top-up link instead of failing. To skip the free tier, set GATE402_API_KEY to a funded account (top up).

The payment is the auth — there are no accounts to create.

Related MCP server: AfaAgent x402 API Suite

Install

npm install -g gate402-mcp

Or run without installing via npx gate402-mcp.

Configure your MCP client

Claude Desktop / Claude Code

Add to your MCP config (claude_desktop_config.json, or claude mcp add):

{
  "mcpServers": {
    "gate402": {
      "command": "npx",
      "args": ["-y", "gate402-mcp"]
    }
  }
}

Cursor / Cline / Windsurf

Same shape — point the MCP server command at npx -y gate402-mcp.

Agent frameworks (LangChain, CrewAI, LlamaIndex)

gate402 is a standard stdio MCP server, so any framework with an MCP adapter can load all 17 tools:

LangChain / LangGraph (langchain-mcp-adapters):

from langchain_mcp_adapters.client import MultiServerMCPClient
client = MultiServerMCPClient({"gate402": {"command": "npx", "args": ["-y", "gate402-mcp"], "transport": "stdio"}})
tools = await client.get_tools()   # feed into your agent

CrewAI (MCPServerAdapter):

from crewai_tools import MCPServerAdapter
from mcp import StdioServerParameters
params = StdioServerParameters(command="npx", args=["-y", "gate402-mcp"])
with MCPServerAdapter(params) as tools:
    ...  # pass tools to your Crew

LlamaIndex (McpToolSpec):

from llama_index.tools.mcp import BasicMCPClient, McpToolSpec
tools = McpToolSpec(client=BasicMCPClient("npx", args=["-y", "gate402-mcp"])).to_tool_list()

Once wired, the agent calls the tools autonomously; the free-credit key is claimed on first use, and paid tools draw down from it.

Environment variables

Var

Default

Purpose

GATE402_API_KEY

(unset)

Use a funded account instead of the free tier.

GATE402_BASE_URL

https://gate402.app

Override the gateway (self-hosting / testing).

GATE402_CONFIG_DIR

~/.gate402-mcp

Where the cached free key is stored.

Develop

npm install
npm run build
npm start          # or: npm run dev

License

MIT

Available Tools

7 tools
gate402_dedupA

Semantic vector-cache lookup: exact-match then 0.88 cosine similarity. Returns a cache hit/miss for a query, sub-10ms. Pay-per-call ($0.001 hit / $0.003 miss).

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesText to look up in the cache.
vectorNoOptional embedding to store on a miss.
namespaceNoOptional cache namespace.
storeOnMissNoStore the query on a miss for future hits.

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses critical behavioral traits: exact-match plus cosine similarity threshold (0.88), sub-10ms speed, and pay-per-call pricing. It does not mention potential side effects like cache mutation (though the storeOnMiss parameter suggests optional storage), but overall adds significant value beyond a generic description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that front-load the purpose and key details. Every sentence adds value, with no superfluous information.

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

Completeness3/5

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

The tool has no output schema, so the description should explain return values. It states 'Returns a cache hit/miss for a query' but does not specify the exact format or fields. Given the four parameters, the description could mention optional parameters like vector, namespace, and storeOnMiss. The cost information is helpful, but the description feels slightly incomplete for a production tool.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description does not add additional meaning to the parameters beyond what the schema already provides. Each parameter is adequately described in the schema, and the description does not elaborate on their usage or interactions.

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: a semantic vector-cache lookup using exact-match then 0.88 cosine similarity. It specifies the verb (lookup), resource (cache), and key details (speed, cost). This clearly distinguishes it from sibling tools like gate402_scrape or gate402_token_count.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or sibling comparisons. The cost information is useful but does not constitute explicit usage guidance.

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

gate402_html_to_mdA

FREE. Convert an HTML string you already have into clean Markdown. (To FETCH a live page instead, use gate402_scrape.) No payment required.

ParametersJSON Schema
NameRequiredDescriptionDefault
htmlYesHTML to convert to Markdown.

TDQS

A4.7/5.0
Behavior4/5

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

Description implies a simple, non-destructive conversion. With no annotations, it adequately covers the core behavior, but could mention handling of malformed HTML or limitations.

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-loaded with core action, no unnecessary words.

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 one-parameter conversion tool with full schema description and no output schema, the description is complete and provides all necessary 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?

Schema coverage is 100%, baseline 3. Description adds context that HTML should be already obtained, adding value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it converts an HTML string to Markdown, with specific verb and resource. Distinguishes from sibling gate402_scrape.

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 tells when to use this tool (when you already have HTML) and when to use alternative gate402_scrape (to fetch a live page).

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

gate402_json_repairA

FREE. Coerce malformed / LLM-mangled JSON (trailing commas, single quotes, unquoted keys) into valid JSON. No payment required.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesBroken JSON string to repair.

TDQS

A3.6/5.0
Behavior2/5

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

With no annotations, the description must carry the full burden. It lists types of errors handled but does not disclose behavior on failure (e.g., returns null or error), any destructive actions, or performance characteristics. Minimal transparency beyond basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (one sentence plus a free note). It could be improved by moving the core action before the 'FREE' notice, but it remains direct with no wasted words.

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

Completeness3/5

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

For a simple tool with no output schema, the description explains input and examples but omits output behavior (e.g., returns valid JSON string or null) and any limitations. Adequate but with clear 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?

Schema coverage is 100% for the single parameter 'text', and the description adds valuable examples of input (trailing commas, single quotes, unquoted keys) that go beyond the schema's 'Broken JSON string to repair', providing concrete meaning.

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: to coerce malformed JSON (e.g., trailing commas, single quotes, unquoted keys) into valid JSON. It uses a specific verb 'coerce' and resource 'malformed JSON', and is distinct from sibling tools like dedup or HTML conversion.

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 mentions 'FREE' but provides no explicit guidance on when to use this tool over alternatives. Siblings have different purposes, so implied usage is for JSON repair, but no exclusions or context are given.

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

gate402_minifyA

Compress text to cut downstream LLM token spend (~40%): strips filler, collapses JSON, densifies prose. Pay-per-call ($0.005/10k tokens).

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesText to compress.
formatNoHint for the compressor (default auto).
aggressiveNoCompress harder at some fidelity cost.

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description covers basic behavior (strips filler, collapses JSON, densifies prose) and cost, but omits return format, idempotency, or destructive effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and benefit, no redundant words.

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

Completeness3/5

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

Covers purpose and cost but missing output format or return value explanation, which would be helpful given no 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?

Schema coverage is 100% so parameters are documented; description adds context about compression techniques but no additional param details beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool compresses text to reduce LLM token spend by ~40%, distinguishing it from siblings like dedup or token_count.

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 specifies when to use (to cut token spend) and gives cost details, 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.

gate402_scrapeA

Fetch any public URL, render client-side JS, strip nav/ads, and return clean LLM-ready Markdown. Pay-per-call ($0.002) via Gate402; free tier on first runs.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesPublic URL to fetch and convert to Markdown.

TDQS

A4/5.0
Behavior3/5

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

The description discloses key behaviors: rendering client-side JS, stripping nav/ads, and returning Markdown. It also mentions pricing and free tier. However, it omits details like rate limits, error handling, or authentication requirements, which are important for a web scraping tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: the first describes the core functionality, the second adds pricing context. No wasted words, front-loaded with key purpose.

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 no annotations and no output schema, the description covers the main purpose, input, process, and output format. Missing error cases and size limits, but adequate for typical use.

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

Parameters3/5

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

The input schema has 100% coverage with the 'url' parameter description. The tool description adds no new meaning beyond the schema's 'Public URL'. Baseline is 3 per rules.

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 any public URL, renders client-side JS, strips nav/ads, and returns clean LLM-ready Markdown. It distinguishes from siblings like gate402_scrape_stealth by emphasizing the non-stealth nature and explicit pricing.

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

Usage Guidelines4/5

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

The description explicitly says 'Fetch any public URL', providing clear context for when to use. However, it does not mention when not to use or provide alternatives among siblings, such as gate402_scrape_stealth for stealth scraping.

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

gate402_scrape_stealthA

Hardened headless fetch for JS-heavy or lightly bot-protected pages. Use when gate402_scrape is blocked or returns little content. Pay-per-call ($0.05).

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesProtected URL to scrape.

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description bears full burden. It mentions hardened headless execution and pay-per-call cost, but lacks details on return format, error handling, or limitations such as inability to handle captchas.

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; first sentence states purpose and target, second provides usage guidance and cost. Every word earns its place with no redundancy.

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 a single required param and no output schema, the description sufficiently orients an AI agent about when to use it. Lacks detail on execution behavior and cost implications, but remains adequate for the tool's simplicity.

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

Parameters3/5

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

Schema coverage is 100% and the description adds only slight nuance ('Protected URL') beyond the schema's 'Protected URL to scrape', resulting in marginal added value.

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 it is a 'hardened headless fetch' for JS-heavy or lightly bot-protected pages, distinguishing it from the sibling tool gate402_scrape by specifying a more robust use case.

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 'Use when gate402_scrape is blocked or returns little content', providing direct guidance on when to prefer this tool over its sibling.

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

gate402_token_countB

FREE. Estimate the token count of a string (cl100k/o200k tokenizer). Use to budget context windows. No payment required.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesText to count tokens for.

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It mentions 'FREE' but does not state that it is read-only, has no side effects, or requires authentication. It lacks information on rate limits or output format, leaving transparency gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with two sentences that are front-loaded with key information (FREE, then what it does). Every sentence adds value, no redundancy.

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?

Given the tool's simplicity and lack of output schema, the description covers basic purpose and use case. However, it omits important details like return value format (e.g., integer), any limits on input size, or that the count is approximate. These gaps prevent full completeness.

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

Parameters3/5

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

Schema coverage is 100% with a clear description for 'text'. The tool description adds tokenizer info and usage hint, but does not significantly enhance parameter understanding beyond the schema. Baseline of 3 is appropriate.

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 the tool estimates token count for a string, specifying tokenizer types (cl100k/o200k) and a use case. It distinguishes well from sibling tools which focus on other text operations.

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 mentions 'FREE' and 'Use to budget context windows', providing some context. However, it does not explicitly state when to use this tool vs alternatives, nor give exclusions. Since no sibling does token counting, this is adequate but could be improved.

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

Tool Schema Changelog

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

  1. 7 tool updatesv0.2.0
    • First observedgate402_dedup
    • First observedgate402_html_to_md
    • First observedgate402_json_repair
    • First observedgate402_minify
    • First observedgate402_scrape
    • First observedgate402_scrape_stealth
    • First observedgate402_token_count
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: dedup for cache lookup, html_to_md for conversion, json_repair for fixing JSON, minify for compression, scrape for general scraping, scrape_stealth for hardened scraping, and token_count for token counting. The only potential overlap is between scrape and scrape_stealth, but their descriptions explicitly differentiate them by use case, so no ambiguity.

Naming Consistency4/5

All tools share the 'gate402_' prefix, which is consistent. However, suffixes vary: some are single verbs (dedup, minify, scrape), others are compound with underscores (html_to_md, json_repair, token_count), and one is a phrase (scrape_stealth). This mixed pattern is minor but prevents a perfect score.

Tool Count5/5

With 7 tools, the server covers a well-scoped set of utilities: caching, conversion, repair, minification, scraping (two variants), and token counting. Each tool addresses a distinct need without redundancy, and the count feels appropriate for a utility-focused MCP server.

Completeness4/5

The tool set covers core text processing and web scraping tasks, but there are minor gaps such as the lack of a general format converter (e.g., CSV to JSON) or PDF extraction. However, the existing tools form a coherent set for the advertised functionalities, and no critical operations are missing for the apparent scope.

Maintenance

ActivitySlowing
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

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/pgalyen1987/gate402-mcp'

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