Dale a tu agente de IA una billetera y un mercado.
@gatefare/mcpes un servidor del Protocolo de Contexto de Modelo (MCP) que conecta Claude Desktop, Cursor o cualquier agente compatible con MCP al catálogo de APIs HTTP de pago de Gatefare. Los pagos se liquidan en USDC en Base mediante el estándar abierto x402: sin claves SaaS, sin suscripciones, sin depósito en garantía. Sin custodia: la firma se realiza localmente; la clave privada nunca abandona tu máquina.
┌─────────────┐ ┌──────────────┐ ┌─────────────────┐
│ 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) o %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"gatefare": {
"command": "npx",
"args": ["-y", "@gatefare/mcp"]
}
}
}Cursor — ~/.cursor/mcp.json o .cursor/mcp.json a nivel de proyecto:
{
"mcpServers": {
"gatefare": {
"command": "npx",
"args": ["-y", "@gatefare/mcp"]
}
}
}Reinicia el cliente. El agente ahora tiene 5 herramientas de solo lectura: descubrimiento + seguridad. Prueba:
"Busca APIs de clima en Gatefare."
Añade env a la misma configuración:
{
"mcpServers": {
"gatefare": {
"command": "npx",
"args": ["-y", "@gatefare/mcp"],
"env": {
"WALLET_PRIVATE_KEY": "0xYOUR_KEY",
"WALLET_BUDGET_USD": "5.00"
}
}
}
}Las herramientas de comprador (call_api, get_wallet_balance, estimate_cost) estarán disponibles. El límite WALLET_BUDGET_USD es una red de seguridad en tiempo de ejecución; para un límite estricto, financia la billetera solo con lo que estés dispuesto a gastar.
"¿Qué clima hace en Londres ahora mismo? Gasta hasta $0.001."
Obtén un PAT en gatefare.io/dashboard/tokens y añade:
"env": {
"GATEFARE_PAT": "gfpat_..."
}Aparecerán las herramientas de editor (register_api, list_my_apis, update_api, get_revenue, distribute).
"Publica mi API en https://api.example.com/sentiment por $0.001 por llamada."
Related MCP server: oom-x402-mcp
13 herramientas en 4 dominios. Las herramientas se autorregistran según las variables de entorno configuradas; el agente nunca ve una herramienta que no puede usar.
Herramienta | Descripción |
| Búsqueda de texto completo en el catálogo con filtros (precio, categoría, orden) |
| Detalles completos de una API por slug o |
| Todas las categorías con recuento de APIs |
| Sugerencias de autocompletado para una cadena de búsqueda |
WALLET_PRIVATE_KEYHerramienta | Descripción |
| Realiza una llamada de pago. Maneja 402 → firma → reintento automáticamente |
| USDC + ETH en Base, más el presupuesto restante en tiempo de ejecución |
| Costo total proyectado para N llamadas planificadas |
GATEFARE_PATHerramienta | Descripción |
| Publica una nueva API de pago |
| Tus APIs publicadas con estadísticas |
| Edita metadatos, precio, URL de destino |
| Series temporales de ingresos + totales |
| Activa el pago |
Herramienta | Descripción |
| Reporta una API maliciosa / robada (DMCA, fraude, malware…) |
Variable | Predeterminado | Requerido para |
|
| — (anular para autoalojamiento) |
| — | Cualquier herramienta de comprador |
| ilimitado | Límite de gasto opcional |
|
|
|
| — | Cualquier herramienta de editor |
|
|
|
Tú: Encuéntrame una API de clima de menos de $0.001 y llámala para "Tokio".
Claude: Llamando a
gatefare.search_apisconmax_price: 0.001… Encontrédemo-weatherde @alice a $0.001/llamada. Llamando agatefare.call_apiconslug: "demo-weather",query: {city: "Tokio"}… Tokio está a 22°C, parcialmente nublado. Pagado 0.001 USDC. Recibo: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)Consulta examples/ para ver variantes ejecutables: Claude Desktop, Cursor, Python, TypeScript y un tutorial de descubrimiento puro.
Si quieres pagar por APIs x402 desde un backend (sin agente), usa los SDKs oficiales de x402 de Coinbase: x402-python (PyPI), coinbase/x402/go, …/java o @x402/fetch. Ellos manejan el flujo de pago; no necesitas este servidor MCP.
Si quieres navegar por el catálogo de Gatefare desde cualquier lenguaje, accede a la API REST directamente: gatefare.io/api/catalog (especificación OpenAPI 3.1).
Desglose completo de qué herramienta se ajusta a cada caso de uso en 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/mcpLos resultados de las herramientas incluyen isError: true y un cuerpo estructurado { error: <code>, message: <human>, details?: <any> }. Los códigos son estables; los agentes pueden usarlos para lógica de reintento o visualización.
Código | Significado |
| La entrada falló la validación zod |
| Configura |
| Configura |
| Se alcanzó el límite de presupuesto en tiempo de ejecución |
| La billetera no tiene suficiente USDC |
| El precio del servidor excede tu |
| El slug no existe o está suspendido |
| La API de pago devolvió un código distinto a 2xx, o su 402 estaba mal formado |
| Gatefare limitó la tasa de la solicitud |
| No se pudo contactar con Gatefare |
| Gatefare devolvió un 4xx / 5xx |
El agente llama a gatefare.call_api { slug: "demo-weather", … }.
Hacemos GET https://gatefare.io/p/demo-weather (aún sin pago).
El proxy de Gatefare devuelve 402 Payment Required con accepts: [{network, payTo, maxAmountRequired, …}].
Firmamos una EIP-3009 transferWithAuthorization por esa cantidad exacta y destinatario en la red configurada.
Reintentamos la solicitud con el encabezado X-Payment firmado (JSON codificado en base64, x402 v2).
Gatefare verifica la firma, liquida la transferencia USDC y hace proxy de la llamada a la API upstream.
Devolvemos la respuesta upstream (y un recibo de pago) al agente.
La firma es de un solo uso, limitada en tiempo y nunca abandona tu máquina para ningún propósito que no sea esta transferencia exacta a este payTo exacto. La clave privada nunca se registra.
Sin custodia. Las claves privadas viven en tu entorno, la firma ocurre localmente, ningún servicio de Gatefare las ve nunca.
Resistente a la confusión de red. Se rechaza cualquier puerta de enlace maliciosa que devuelva requisitos exclusivos de Sepolia a un usuario de la red principal; nunca firmamos para una cadena que el usuario no configuró.
Nonces criptográficamente aleatorios. Sin colisiones basadas en Date.now().
Ventana de validez limitada a 1 hora incluso si el servidor solicita más.
Validación de entrada estricta. Los slugs son ^[a-z0-9_-]+$ y están codificados en URL; no hay recorrido de ruta. targetUrl bloquea file://, localhost, IPs de metadatos en la nube, .local y hosts .internal en el momento del registro.
Higiene de secretos. Las pruebas aseguran que la clave privada y el PAT nunca aparezcan en stderr / stdout, nunca.
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 buildPara usar una copia local en la configuración de tu cliente:
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=1Las incidencias y PRs son bienvenidos. Consulta CONTRIBUTING.md para el flujo de trabajo, la guía de estilo y cómo añadir una nueva herramienta.
MIT © Gatefare
🌐 Mercado: gatefare.io
📚 Documentación de API: gatefare.io/docs
🤖 Contexto LLM (archivo único): gatefare.io/llms-full.txt
📐 Especificación OpenAPI: gatefare.io/openapi.json
🐦 Twitter: @Gatefareio
🔌 Protocolo de Contexto de Modelo: modelcontextprotocol.io
💸 Estándar x402: 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.
x402 pay-per-call APIs over MCP, settled in USDC on Base for autonomous agents and developers.
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.
