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つの読み取り専用ツール（検索と安全性）を利用できるようになります。試してみましょう：
"Search Gatefare for weather APIs." (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 の上限は実行時のセーフティネットです。厳密な上限を設定したい場合は、使っても良い金額だけをウォレットに入金してください。
"What's London's weather right now? Spend up to $0.001." (今のロンドンの天気は？0.001ドルまで使って)
gatefare.io/dashboard/tokens でPATを取得し、以下を追加します：
"env": {
"GATEFARE_PAT": "gfpat_..."
}公開者用ツール（register_api、list_my_apis、update_api、get_revenue、distribute）が表示されます。
"Publish my API at https://api.example.com/sentiment for $0.001 per call." (私のAPI https://api.example.com/sentiment を1コール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テストネットの場合は |
| — | 公開者用ツール全般 |
|
| 詳細なstderr出力には |
あなた: Find me a sub-$0.001 weather API and call it for "Tokyo". (0.001ドル以下の天気APIを探して、「東京」でコールして)
Claude: Calling
gatefare.search_apiswithmax_price: 0.001… Founddemo-weatherby @alice at $0.001/call. Callinggatefare.call_apiwithslug: "demo-weather",query: {city: "Tokyo"}… Tokyo is 22°C, partly cloudy. Paid 0.001 USDC. Receipt:settled-tx-0x9a…(東京は22度、曇り時々晴れ。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 への送金以外の目的でマシンから出ることはありません。秘密鍵がログに記録されることもありません。
ノンカストディアル。 秘密鍵は環境変数内に存在し、署名はローカルで行われるため、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=1Issueや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.
