Дайте своему ИИ-агенту кошелек и доступ к маркетплейсу.
@gatefare/mcp— это сервер протокола Model Context Protocol (MCP), который подключает Claude Desktop, Cursor или любого другого агента, совместимого с MCP, к каталогу платных HTTP API Gatefare. Платежи осуществляются в USDC в сети Base через открытый стандарт x402 — без SaaS-ключей, подписок и эскроу. Без кастодиального хранения: подписание происходит локально; закрытый ключ никогда не покидает ваш компьютер.
┌─────────────┐ ┌──────────────┐ ┌─────────────────┐
│ 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) или %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"gatefare": {
"command": "npx",
"args": ["-y", "@gatefare/mcp"]
}
}
}Cursor — ~/.cursor/mcp.json или .cursor/mcp.json на уровне проекта:
{
"mcpServers": {
"gatefare": {
"command": "npx",
"args": ["-y", "@gatefare/mcp"]
}
}
}Перезапустите клиент. Теперь у агента есть 5 инструментов только для чтения — поиск и безопасность. Попробуйте:
"Найди в Gatefare API для погоды."
Добавьте env в тот же файл конфигурации:
{
"mcpServers": {
"gatefare": {
"command": "npx",
"args": ["-y", "@gatefare/mcp"],
"env": {
"WALLET_PRIVATE_KEY": "0xYOUR_KEY",
"WALLET_BUDGET_USD": "5.00"
}
}
}
}Инструменты покупателя (call_api, get_wallet_balance, estimate_cost) станут доступны. Лимит WALLET_BUDGET_USD — это защитный механизм во время выполнения; для жесткого ограничения пополняйте кошелек только на ту сумму, которую готовы потратить.
"Какая сейчас погода в Лондоне? Потрать до $0.001."
Получите PAT на gatefare.io/dashboard/tokens и добавьте:
"env": {
"GATEFARE_PAT": "gfpat_..."
}Появятся инструменты издателя (register_api, list_my_apis, update_api, get_revenue, distribute).
"Опубликуй мой API по адресу https://api.example.com/sentiment за $0.001 за вызов."
Related MCP server: oom-x402-mcp
13 инструментов в 4 доменах. Инструменты автоматически регистрируются в зависимости от того, какие переменные окружения установлены — агент никогда не увидит инструмент, который не может использовать.
Инструмент | Описание |
| Полнотекстовый поиск по каталогу с фильтрами (цена, категория, сортировка) |
| Полная информация об одном API по слагу или |
| Все категории с количеством API |
| Автодополнение для поискового запроса |
WALLET_PRIVATE_KEYИнструмент | Описание |
| Совершить платный вызов. Автоматически обрабатывает 402 → подпись → повтор |
| Баланс USDC + ETH в сети Base, плюс оставшийся бюджет |
| Оценка общей стоимости для N запланированных вызовов |
GATEFARE_PATИнструмент | Описание |
| Опубликовать новый платный API |
| Ваши опубликованные API со статистикой |
| Редактирование метаданных, цены, целевого URL |
| Временные ряды доходов + итоги |
| Запуск ончейн-выплаты |
Инструмент | Описание |
| Сообщить о вредоносном / украденном API (DMCA, мошенничество, вредоносное ПО…) |
Переменная | По умолчанию | Требуется для |
|
| — (переопределите для self-hosted) |
| — | Любой инструмент покупателя |
| без ограничений | Опциональный лимит расходов |
|
|
|
| — | Любой инструмент издателя |
|
|
|
Вы: Найди мне API погоды дешевле $0.001 и вызови его для "Токио".
Claude: Вызываю
gatefare.search_apisсmax_price: 0.001… Найденdemo-weatherот @alice по цене $0.001/вызов. Вызываюgatefare.call_apiсslug: "demo-weather",query: {city: "Токио"}… В Токио 22°C, переменная облачность. Оплачено 0.001 USDC. Квитанция: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)Смотрите examples/ для запускаемых вариантов: Claude Desktop, Cursor, Python, TypeScript и пошаговое руководство по поиску.
Если вы хотите оплачивать API стандарта x402 из бэкенда (без агента), используйте официальные SDK x402 от Coinbase — x402-python (PyPI), coinbase/x402/go, …/java или @x402/fetch. Они обрабатывают процесс оплаты; этот MCP-сервер вам не нужен.
Если вы хотите просматривать каталог Gatefare из любого языка программирования, обращайтесь напрямую к REST API: gatefare.io/api/catalog (спецификация OpenAPI 3.1).
Полный разбор того, какой инструмент подходит для какого случая использования, находится в 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/mcpРезультаты инструментов включают isError: true и структурированное тело { error: <code>, message: <human>, details?: <any> }. Коды стабильны — агенты могут использовать их для логики повторных попыток или отображения информации.
Код | Значение |
| Входные данные не прошли валидацию zod |
| Установите |
| Установите |
| Достигнут лимит бюджета |
| На кошельке недостаточно USDC |
| Цена сервера превышает ваш |
| Слаг не существует или приостановлен |
| Платный API вернул не 2xx код, или его ответ 402 был некорректен |
| Gatefare ограничил частоту запросов |
| Не удалось связаться с Gatefare |
| Gatefare вернул 4xx / 5xx ошибку |
Агент вызывает gatefare.call_api { slug: "demo-weather", … }.
Мы делаем GET https://gatefare.io/p/demo-weather (оплаты пока нет).
Прокси Gatefare возвращает 402 Payment Required с accepts: [{network, payTo, maxAmountRequired, …}].
Мы подписываем EIP-3009 transferWithAuthorization на точную сумму и получателя в настроенной сети.
Мы повторяем запрос с подписанным заголовком X-Payment (JSON в base64, x402 v2).
Gatefare проверяет подпись, проводит перевод USDC и проксирует вызов к целевому API.
Мы передаем ответ (и квитанцию об оплате) обратно агенту.
Подпись одноразовая, ограничена по времени и никогда не покидает ваш компьютер для любых целей, кроме этого конкретного перевода этому конкретному payTo. Закрытый ключ никогда не логируется.
Без кастодиального хранения. Закрытые ключи находятся в вашем окружении, подписание происходит локально, ни один сервис Gatefare их не видит.
Устойчивость к путанице сетей. Запросы от вредоносного шлюза, требующего Sepolia для пользователя основной сети, отклоняются — мы никогда не подписываем транзакции для сети, которую пользователь не настраивал.
Криптографически случайные нонсы. Никаких коллизий на основе Date.now().
Окно валидности ограничено 1 часом, даже если сервер запрашивает больше.
Строгая валидация ввода. Слаги имеют вид ^[a-z0-9_-]+$ и URL-кодируются; никакой навигации по путям. targetUrl блокирует file://, localhost, IP метаданных облаков, .local и .internal хосты при регистрации.
Гигиена секретов. Тесты гарантируют, что закрытый ключ и PAT никогда не появятся в stderr / stdout.
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 buildЧтобы использовать локальную сборку в конфигурации клиента:
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=1Проблемы и PR приветствуются. См. CONTRIBUTING.md для ознакомления с рабочим процессом, руководством по стилю и тем, как добавить новый инструмент.
MIT © Gatefare
🌐 Маркетплейс: gatefare.io
📚 Документация API: gatefare.io/docs
🤖 Контекст для LLM (один файл): gatefare.io/llms-full.txt
📐 Спецификация OpenAPI: gatefare.io/openapi.json
🐦 Twitter: @Gatefareio
🔌 Model Context Protocol: modelcontextprotocol.io
💸 Стандарт 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.
