AI 에이전트에게 지갑과 마켓플레이스를 제공하세요.
@gatefare/mcp는 Claude Desktop, Cursor 또는 MCP 호환 에이전트를 Gatefare 유료 HTTP API 카탈로그에 연결하는 Model Context Protocol 서버입니다. 결제는 개방형 x402 표준을 통해 Base 네트워크에서 USDC로 정산되며, 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까지 사용해."
gatefare.io/dashboard/tokens에서 PAT를 발급받고 다음을 추가하세요:
"env": {
"GATEFARE_PAT": "gfpat_..."
}게시자 도구(register_api, list_my_apis, update_api, get_revenue, distribute)가 나타납니다.
"https://api.example.com/sentiment 에 있는 내 API를 호출당 $0.001에 게시해 줘."
Related MCP server: oom-x402-mcp
4개 영역에 걸친 13가지 도구입니다. 설정된 환경 변수에 따라 도구가 자동으로 등록되므로, 에이전트는 사용할 수 없는 도구를 보지 않습니다.
도구 | 설명 |
| 필터(가격, 카테고리, 정렬)를 사용하여 카탈로그 전체 텍스트 검색 |
| 슬러그 또는 |
| API 개수가 포함된 모든 카테고리 목록 |
| 쿼리 문자열에 대한 자동 완성 제안 |
WALLET_PRIVATE_KEY 필요도구 | 설명 |
| 유료 호출 수행. 402 응답 → 서명 → 재시도 자동 처리 |
| Base 네트워크의 USDC + ETH 잔액 및 남은 런타임 예산 확인 |
| N번의 계획된 호출에 대한 총 비용 추정 |
GATEFARE_PAT 필요도구 | 설명 |
| 새로운 유료 API 게시 |
| 통계가 포함된 게시한 API 목록 |
| 메타데이터, 가격, 대상 URL 수정 |
| 수익 시계열 데이터 및 총액 조회 |
| 온체인 |
도구 | 설명 |
| 악의적이거나 도용된 API 신고 (DMCA, 사기, 악성코드 등) |
변수 | 기본값 | 필수 대상 |
|
| — (자체 호스팅 시 재정의) |
| — | 모든 구매자 도구 |
| 무제한 | 선택적 지출 상한선 |
|
| Sepolia 테스트넷의 경우 |
| — | 모든 게시자 도구 |
|
| 상세 로그 출력을 위해 |
사용자: 0.001달러 미만의 날씨 API를 찾아서 "도쿄"에 대해 호출해 줘.
Claude:
max_price: 0.001로gatefare.search_apis호출 중… @alice의demo-weather를 호출당 $0.001에 찾았습니다.slug: "demo-weather",query: {city: "Tokyo"}로gatefare.call_api호출 중… 도쿄는 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)실행 가능한 변형(Claude Desktop, Cursor, Python, TypeScript 및 순수 검색 가이드)은 examples/를 참조하세요.
(에이전트 없이) 백엔드에서 x402 API 비용을 지불하려면 Coinbase의 공식 x402 SDK(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 프록시가 accepts: [{network, payTo, maxAmountRequired, …}]와 함께 402 Payment Required를 반환합니다.
설정된 네트워크에서 해당 금액과 수신자에 대해 EIP-3009 transferWithAuthorization 서명을 생성합니다.
서명된 X-Payment 헤더(base64 인코딩된 JSON, x402 v2)를 포함하여 요청을 재시도합니다.
Gatefare가 서명을 확인하고 USDC 이체를 정산한 뒤, 업스트림 API로 호출을 프록시합니다.
업스트림 응답(및 결제 영수증)을 에이전트에게 전달합니다.
서명은 일회용이며 시간 제한이 있고, 이 특정 수신자(payTo)에 대한 정확한 이체 목적 외에는 절대 기기를 벗어나지 않습니다. 개인 키는 절대 로그에 기록되지 않습니다.
비수탁(Non-custodial). 개인 키는 환경 변수에 저장되며 서명은 로컬에서 이루어집니다. Gatefare 서비스는 절대 키를 볼 수 없습니다.
네트워크 혼동 방지. 메인넷 사용자에게 Sepolia 전용 요구 사항을 반환하는 악의적인 게이트웨이는 거부됩니다. 사용자가 설정하지 않은 체인에 대해서는 절대 서명하지 않습니다.
암호학적으로 안전한 난수(nonce). Date.now() 기반의 충돌이 없습니다.
유효 기간 제한. 서버가 더 긴 시간을 요청하더라도 유효 기간은 1시간으로 제한됩니다.
엄격한 입력 유효성 검사. 슬러그는 ^[a-z0-9_-]+$로 제한되며 URL 인코딩됩니다. 경로 탐색(path traversal)은 불가능합니다. 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
🐦 트위터: @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.
