Give your AI agent a wallet and a marketplace.
@gatefare/mcpis a Model Context Protocol server that connects Claude Desktop, Cursor, or any MCP-compatible agent to the Gatefare catalog of paid HTTP APIs. Payments settle as USDC on Base via the open x402 standard — no SaaS keys, no subscriptions, no escrow. Non-custodial: signing happens locally; the private key never leaves your machine.
┌─────────────┐ ┌──────────────┐ ┌─────────────────┐
│ Claude / │ MCP stdio │ @gatefare/mcp│ HTTP + x402 │ gatefare.io │
│ Cursor / │ ─────────────► │ (this repo)│ ─────────────► │ proxy + │
│ your agent │ │ │ │ catalog │
└─────────────┘ └──────┬───────┘ └─────────────────┘
│
│ EIP-3009 sign
▼
┌─────────────┐
│ Base USDC │
└─────────────┘Claude Desktop — ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"gatefare": {
"command": "npx",
"args": ["-y", "@gatefare/mcp"]
}
}
}Cursor — ~/.cursor/mcp.json or project-level .cursor/mcp.json:
{
"mcpServers": {
"gatefare": {
"command": "npx",
"args": ["-y", "@gatefare/mcp"]
}
}
}Restart the client. The agent now has 5 read-only tools — discovery + safety. Try:
"Search Gatefare for weather APIs."
Add env to the same config:
{
"mcpServers": {
"gatefare": {
"command": "npx",
"args": ["-y", "@gatefare/mcp"],
"env": {
"WALLET_PRIVATE_KEY": "0xYOUR_KEY",
"WALLET_BUDGET_USD": "5.00"
}
}
}
}Buyer tools (call_api, get_wallet_balance, estimate_cost) become available. The
WALLET_BUDGET_USD cap is a runtime safety net — for a hard cap, fund the wallet with
only what you're willing to spend.
"What's London's weather right now? Spend up to $0.001."
Get a PAT at gatefare.io/dashboard/tokens and add:
"env": {
"GATEFARE_PAT": "gfpat_..."
}Publisher tools (register_api, list_my_apis, update_api, get_revenue,
distribute) appear.
"Publish my API at https://api.example.com/sentiment for $0.001 per call."
Related MCP server: StatePulse API
13 tools across 4 domains. Tools auto-register based on which env vars are set — the agent never sees a tool it can't use.
Tool | Description |
| Full-text search the catalog with filters (price, category, sort) |
| Full details for one API by slug or |
| All categories with API counts |
| Autocomplete suggestions for a query string |
WALLET_PRIVATE_KEYTool | Description |
| Make a paid call. Handles 402 → sign → retry automatically |
| USDC + ETH on Base, plus remaining runtime budget |
| Project total cost for N planned calls |
GATEFARE_PATTool | Description |
| Publish a new paid API |
| Your published APIs with stats |
| Edit metadata, price, target URL |
| Revenue time series + totals |
| Trigger on-chain |
Tool | Description |
| Report a malicious / stolen API (DMCA, fraud, malware…) |
Var | Default | Required for |
|
| — (override for self-hosted) |
| — | Any buyer tool |
| unlimited | Optional spend cap |
|
|
|
| — | Any publisher tool |
|
|
|
You: Find me a sub-$0.001 weather API and call it for "Tokyo".
Claude: Calling
gatefare.search_apiswithmax_price: 0.001…
Founddemo-weatherby @alice at $0.001/call.
Callinggatefare.call_apiwithslug: "demo-weather",query: {city: "Tokyo"}…
Tokyo is 22°C, partly cloudy. Paid 0.001 USDC. Receipt:settled-tx-0x9a…
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
server = StdioServerParameters(
command="npx",
args=["-y", "@gatefare/mcp"],
env={"WALLET_PRIVATE_KEY": "0x...", "WALLET_BUDGET_USD": "1.00"},
)
async with stdio_client(server) as (r, w):
async with ClientSession(r, w) as s:
await s.initialize()
result = await s.call_tool(
"gatefare.call_api",
arguments={"slug": "demo-weather", "query": {"city": "Tokyo"}},
)
print(result.content[0].text)See examples/ for runnable variants: Claude Desktop, Cursor, Python,
TypeScript, and a pure-discovery walkthrough.
If you want to pay for x402 APIs from a backend (no agent), use Coinbase's
official x402 SDKs — x402-python (PyPI), coinbase/x402/go, …/java, or
@x402/fetch. They handle the
payment flow; you don't need this MCP server.
If you want to browse the Gatefare catalog from any language, hit the
REST API directly: gatefare.io/api/catalog
(OpenAPI 3.1 spec).
Full breakdown of which tool fits which use case in
docs/integrations.md.
# Run the server in foreground; talks JSON-RPC over stdio.
npx -y @gatefare/mcp
# In another terminal, send a frame:
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | \
npx -y @gatefare/mcpTool results include isError: true and a structured body
{ error: <code>, message: <human>, details?: <any> }. Codes are stable —
agents can switch on them for retry / surfacing logic.
Code | Meaning |
| Input failed zod validation |
| Set |
| Set |
| Runtime budget cap hit |
| Wallet doesn't have enough USDC |
| Server's price exceeds your |
| Slug doesn't exist or is suspended |
| Paid API returned non-2xx, or its 402 was malformed |
| Gatefare rate-limited the request |
| Could not reach Gatefare |
| Gatefare returned a 4xx / 5xx |
The agent calls gatefare.call_api { slug: "demo-weather", … }.
We GET https://gatefare.io/p/demo-weather (no payment yet).
The Gatefare proxy returns 402 Payment Required with accepts: [{network, payTo, maxAmountRequired, …}].
We sign an EIP-3009 transferWithAuthorization for that exact amount and recipient on the configured network.
We retry the request with the signed X-Payment header (base64-encoded JSON, x402 v2).
Gatefare verifies the signature, settles the USDC transfer, and proxies the call to the upstream API.
We hand the upstream response (and a payment receipt) back to the agent.
The signature is single-use, time-bounded, and never leaves your machine for any
purpose other than this exact transfer to this exact payTo. The private key
is never logged.
Non-custodial. Private keys live in your env, signing happens locally, no Gatefare service ever sees them.
Network confusion-resistant. A malicious gateway returning Sepolia-only requirements to a mainnet user is rejected — we never sign for a chain the user didn't configure.
Cryptographically random nonces. No Date.now()-based collisions.
Validity window clamped to 1 hour even if the server requests more.
Strict input validation. Slugs are ^[a-z0-9_-]+$ and URL-encoded;
no path traversal. targetUrl blocks file://, localhost, cloud
metadata IPs, .local, and .internal hosts at registration time.
Secret hygiene. Tests assert that the private key and PAT never appear in stderr / stdout, ever.
git clone https://github.com/gatefareio/mcp-server.git
cd mcp-server
npm install
npm run typecheck
npm test # 138 unit tests
npm run test:e2e # 10 e2e tests against live gatefare.io (set GATEFARE_E2E=1)
npm run buildTo use a local checkout in your client config:
npm link
# in claude_desktop_config.json:
# "command": "gatefare-mcp"src/
├── index.ts # entry — wires stdio transport
├── server.ts # McpServer instance + tool registration
├── config.ts # env parsing, capability detection
├── client.ts # REST client (wraps fetch)
├── x402.ts # 402 parsing + EIP-3009 signing
├── types.ts # shared types + GatefareError
└── tools/
├── discovery.ts # search_apis, get_api, list_categories, suggest
├── buyer.ts # call_api, get_wallet_balance, estimate_cost
├── publisher.ts # register_api, list_my_apis, update_api, get_revenue, distribute
└── safety.ts # report_abusetests/
├── config.test.ts # env parsing edges
├── client.test.ts # HTTP client error mapping
├── x402.test.ts # signing + parsing primitives
├── x402-flow.test.ts # full 402 → sign → retry handshake (mocked fetch)
├── server.test.ts # capability-driven tool registration
├── init.test.ts # subprocess: bootstrap, env crashes, secret leakage
├── stdio-protocol.test.ts # stdout pollution + recovery from tool errors
├── stability.test.ts # 100 concurrent calls, memory baseline, ReDoS
├── tools/
│ ├── discovery.test.ts
│ ├── buyer.test.ts
│ ├── buyer-flow.test.ts
│ ├── publisher.test.ts
│ └── safety.test.ts
└── integration/
└── e2e.test.ts # real gatefare.io, gated by GATEFARE_E2E=1Issues and PRs welcome. See CONTRIBUTING.md for the workflow, style guide, and how to add a new tool.
Gatefare ships three first-party packages. They share the same x402 protocol and the same backend, so a project can mix them as needed:
Package | Where | When to use |
| npm | Drop into Claude Desktop / Cursor / any MCP host to give the agent tools for catalog discovery + paid calls |
npm | TypeScript / JavaScript agents that pay APIs in code, outside MCP | |
PyPI | Python agents (LangChain, LlamaIndex, etc.) |
MIT © Gatefare
🌐 Marketplace: gatefare.io
📚 API docs: gatefare.io/docs
🤖 LLM context (single file): gatefare.io/llms-full.txt
📐 OpenAPI spec: gatefare.io/openapi.json
🐦 Twitter: @Gatefareio
🔌 Model Context Protocol: modelcontextprotocol.io
💸 x402 standard: x402.org
Get full details for a specific API by slug, or by handle + urlName pair. Returns pricing, stats, uptime, and publisher info.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | API slug, e.g. 'demo-weather' | |
| handle | No | Publisher handle | |
| urlName | No | API URL name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description adds limited behavioral context. It usefully states what is returned, but it does not disclose behavior for edge cases such as no identifier provided or both slug and handle+urlName supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler, with the primary action and identifier modes front-loaded. Every phrase contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists return fields, which helps since there is no output schema. However, the schema marks all parameters optional while the description implies at least one identifier is required, and it does not clarify exclusivity or what happens with conflicting lookup modes. This is a meaningful gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds value beyond the schema by explicitly pairing handle with urlName as a combined lookup mode, which is not conveyed by the individual parameter descriptions or the lack of required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('specific API'), and clearly identifies the two lookup modes: by slug or by handle + urlName pair. It also lists the returned content (pricing, stats, uptime, publisher info), which distinguishes it from sibling search/list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: when you need full details for a known API. However, it does not explicitly contrast with sibling tools like search_apis or suggest, nor does it state when one lookup mode should be preferred over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available API categories in the Gatefare catalog with API counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 stating the result includes API counts per category and that the operation covers all categories. It does not discuss pagination or return shape, but for a zero-parameter catalog list this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states exactly what the tool returns without filler. Every word earns its place, and the key scope ('all available') and the useful detail ('with API counts') are included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, read-only list operation with no output schema, the description is complete enough for an agent to call and interpret the result. It clearly says what is returned (categories with API counts) and implies an unfiltered catalog-wide response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema covers all possible inputs at 100%. The description adds no parameter-specific detail needed to invoke the tool correctly, and the baseline for a zero-parameter tool is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('all available API categories in the Gatefare catalog'), adding the detail that API counts are included. This clearly distinguishes it from sibling tools like search_apis or get_api without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for broad catalog enumeration, making it a reasonable precursor to searching or retrieving specific APIs. However, it does not explicitly state when to choose this over siblings or mention any exclusions, leaving usage context somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the publisher of an API and return their positive-only trust badges: Established (>=3 months tenure), Top contributor (>=1M lifetime successful calls), Highly rated (>=4.5 avg across >=10 reviews). New publishers come back unmarked — absence of badges is NOT a warning, just a lack of accumulated signal. Use this BEFORE calling an unfamiliar API to gauge counterparty risk.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | API slug, e.g. 'demo-weather' | |
| handle | No | Publisher handle | |
| urlName | No | API URL name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description adds crucial interpretive context: badges are positive-only, and absence of badges is 'NOT a warning, just a lack of accumulated signal.' This prevents the agent from misreading an unmarked result as a negative signal, which is highly valuable behavior disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the purpose, the badge criteria, the important absence-is-not-warning caveat, and when to use it. The most actionable guidance is front-loaded, with no filler or repetition of annotation fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's safety profile via annotations, the badge semantics, the new-publisher case, and the recommended usage moment. With no output schema, the description does not specify the exact return shape, and the relationship between the three optional parameters remains ambiguous, but the core decision-making context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 schema describes each parameter individually, but the description does not clarify how slug, handle, and urlName relate—whether they are aliases, which takes precedence if multiple are supplied, or whether any one is sufficient. The description adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Look up the publisher of an API' and return their trust badges. It also differentiates itself from sibling tools like get_api and search_apis by focusing on publisher reputation rather than API details or discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Use this BEFORE calling an unfamiliar API to gauge counterparty risk.' It does not explicitly name alternatives or exclusion conditions, but the 'before calling an unfamiliar API' guidance is clear enough for an agent to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report an API for abuse — CSAM, fraud, malware, copyright, trademark, etc. Returns a reference ID for tracking. Submitting a report does not guarantee removal; trust & safety reviews each report.
| Name | Required | Description | Default |
|---|---|---|---|
| apiSlug | Yes | ||
| details | Yes | ||
| category | Yes | ||
| reporterEmail | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating, non-idempotent action. The description adds valuable context beyond the annotations: reports are reviewed by trust & safety, removal is not guaranteed, and a tracking reference ID is returned. It does not disclose every side effect, but it sets expectations appropriately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: what the tool does, what it returns, and an important caveat about outcomes. The content is front-loaded and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity tool with four parameters and no output schema, the description covers the key operational context: purpose, return value, and non-guarantee of removal. Parameter semantics are weak, but the schema itself documents field constraints, and annotations cover side-effect hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters and fails to do so. The description does not explain apiSlug, category, details, or optional reporterEmail beyond what the schema already provides. It only echoes abuse categories already visible in the enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Report an API for abuse'), lists relevant abuse categories, and notes the return value (reference ID). It is distinct from siblings by nature, but it does not explicitly name or contrast any sibling tool, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clear: submit an abuse report for an API with categories like CSAM, fraud, malware, and copyright. There are no explicit when-not-to-use instructions or alternative tool references, but the scope is specific enough that an agent would not confuse it with search, get, or suggest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the publisher-pasted representative response for an API. This is what the publisher claims their API returns on a typical successful call. Compare against gatefare.get_api's captured example (what we actually got from probing) to spot inconsistencies BEFORE you pay. Capped at 4 KiB UTF-8 by the platform. Returns null when the publisher has not provided a sample (older listings).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | API slug, e.g. 'demo-weather' | |
| handle | No | Publisher handle | |
| urlName | No | API URL name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses a 4 KiB UTF-8 size cap and the null-return behavior for older listings. These are operational constraints an agent needs to know and are not present in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero fluff: purpose, usage/comparison, and constraints are each front-loaded. Every sentence earns its place and no redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 3 schema-covered parameters and no output schema, the description covers the essential behavioral details (size cap, null case) and gives a clear comparison workflow. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter (slug, handle, urlName) already has a clear description. The tool description adds no extra parameter semantics, which is acceptable given the high schema coverage; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Fetch the publisher-pasted representative response for an API') and immediately differentiates it from the sibling gatefare.get_api by contrasting the publisher-pasted sample with the captured example from probing. This makes the tool's unique role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs when to use this tool: compare the sample against gatefare.get_api's captured example to spot inconsistencies BEFORE paying. It also implicitly advises on fallback behavior by noting it returns null when no sample exists, giving the agent clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Gatefare catalog for paid APIs by text, price, category, or sort order. Returns paginated results with publisher info.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| sort | No | Sort order | |
| query | No | Full-text search query | |
| category | No | Category slug | |
| max_price | No | Maximum price in USD | |
| include_testnet | No | Include testnet APIs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent behavior, so no safety disclosure is needed. The description adds that results are paginated and include publisher info, but does not describe pagination shape or other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences front-load the action and filters and add a useful one-line result summary. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with 6 optional parameters fully described by the schema, the description is largely sufficient. It covers paid-only scope and result content, though there is no output schema to detail pagination fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mirrors the filters (text, price, category, sort), but adds no semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Search the Gatefare catalog for paid APIs') and enumerates filter dimensions. It is clear, though it does not explicitly differentiate itself from siblings like get_api or suggest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for catalog discovery but gives no guidance on when to choose this over get_api for detail retrieval or suggest for query completion. No alternatives or exclusion conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Autocomplete search suggestions for API discovery.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for autocomplete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds only that it provides autocomplete suggestions, which is useful but does not disclose additional behavior such as result limits, ordering, or whether the suggestions reflect previously seen queries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant content. Every word adds useful context, and it remains appropriately concise for a tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only autocomplete tool with one parameter and rich annotations, the description is largely complete. It could be improved by noting what the suggestions are based on or expected response shape, but an agent can correctly invoke the tool with just `query`.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single `query` parameter is already described as 'Search query for autocomplete'. The description adds no further parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides autocomplete search suggestions for API discovery, using a specific resource and intent. It is distinguishable from siblings like gatefare.search_apis and gatefare.get_api, though it does not explicitly name or contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for autocomplete-style suggestion queries but gives no explicit guidance on when to use it versus siblings such as gatefare.search_apis. There is no mention of exclusions, prerequisites, or alternative tool selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.1gatefare.get_apigatefare.list_categoriesgatefare.publisher_reputationgatefare.report_abusegatefare.sample_responsegatefare.search_apisgatefare.suggestScored across 7 tools
Each tool has a clearly distinct purpose: search, details, categories, suggestions, reporting, reputation, and sample responses. Even get_api and sample_response are well-separated by their descriptions.
Most tools follow the verb_noun pattern (search_apis, get_api, list_categories, report_abuse), but suggest and publisher_reputation deviate (bare verb, noun_noun). Overall snake_case and gatefare prefix maintain readability.
Seven tools is ideal for this domain, covering discovery, inspection, reputation, and feedback without bloat or redundancy.
The surface fully covers the API catalog workflow: search, suggest, categories, detailed lookups, publisher trust evaluation, sample response verification, and abuse reporting—no obvious dead ends or missing critical operations.
8 pay-per-call web intel tools over MCP. Free discovery, calls settle in USDC on Base (x402).
Discover and pay for APIs with USDC credits. No wallet, no gas, MCP-native marketplace.
Pay-per-action access to APIs and MCP tools over Lightning L402 and Base USDC x402.
Pay for HTTP APIs and charge for your own: x402 micropayments in USDC on Base.
