Pay-per-call MCP data products listed on Feegate. Free discovery, x402 USDC paid queries on Base.
Scored across 6 tools
Most tools have distinct roles (pricing, free listing, paid catalog, health, metrics, product detail). However, list_products and marketplace_catalog both enumerate products and differ mainly by price/depth, while fee_quote overlaps slightly with ping's returned price list, so an agent could occasionally hesitate.
All names are snake_case and readable, but conventions are mixed: verb_noun (list_products, fee_quote), noun_noun (marketplace_catalog, platform_stats, product_detail), and a bare noun (ping). The set lacks a predictable pattern, though nothing is cryptic.
Six tools is well-scoped for a catalog-plus-metrics server: one per major function (pricing, listing, deep catalog, detail lookup, platform metrics, health). No tool feels redundant or missing from the count perspective.
The surface covers the core lifecycle: discovering products free, deep inspection paid, pricing, and platform traffic metrics. Minor gaps exist—no search/filter or category-browse operation, and no explicit seller/vendor lookup—but agents can work around these via list_products and product_detail.
Feegate 合作方案与结算规则报价（免费）：三档抽成（Self-serve 50% / Managed 40% / Enterprise 30%）、一次性服务费、四项单项服务价格、结算周期与最低结算额。给数据持有方推荐合作方式前先调这个拿权威报价。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add useful context — the call is free (免费) and is the authoritative source of pricing — which implies a safe read-only lookup. However, it says nothing about authentication, rate limits, caching/staleness of the quoted prices, or whether the quote is a binding offer, which matters for a pricing tool.
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 sentences, front-loaded with the resource and followed by the concrete contents and the usage cue. The parenthetical percentages are dense but each carries information an agent needs to decide relevance. Minor verbosity from the double enumeration of fees and prices.
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?
With zero parameters, an output schema present, and a simple read-only lookup, the description covers everything an agent needs: what the tool returns, that it costs nothing, and when to invoke it. Return-value detail is correctly left to the output schema.
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 takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies a no-argument, global quote rather than a per-customer calculation.
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 resource (Feegate partnership/settlement fee quote) and enumerates exactly what it returns: three commission tiers with percentages, a one-time service fee, four individual service prices, settlement cycle and minimum settlement amount. This is clearly distinguishable from siblings like product_detail or marketplace_catalog, which describe products rather than pricing/settlement terms.
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 gives an explicit trigger condition: call this first to obtain authoritative pricing before recommending a partnership model to a data holder. That is real when-to-use guidance. It stops short of naming when-not-to-use conditions or pointing at an alternative sibling for related pricing needs, so it falls just below the top mark.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出 Feegate 数据市场全部在售数据产品（免费）：id、名称、供应商、类目、单价、是否认证。付费深查前先调这个拿准确的 product_id。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It usefully signals that the call is free and returns the complete on-sale catalog with a fixed field set, but says nothing about pagination, result caps, auth requirements, or rate limits for a zero-parameter catalog listing.
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, front-loaded with verb and scope, followed by the call-ordering hint. The field enumeration doubles as the return summary, so no sentence is wasted.
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?
Zero parameters plus an output schema mean the heavy lifting is already structured; the description adds the free-vs-paid positioning and the product_id workflow. The only remaining gap is the absence of any read-only/safety statement, which no annotation covers.
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 takes no parameters, so the schema has nothing to explain and the baseline is 4. The description correctly offers no parameter guidance, which is appropriate here.
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?
States a specific verb and resource: list all on-sale data products in the Feegate marketplace, and enumerates exactly which fields come back (id, name, provider, category, unit price, certification flag). It implicitly separates itself from the paid detail tools via '免费' vs '付费深查', though it never names product_detail or marketplace_catalog outright.
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?
Gives an explicit call ordering: run this before any paid deep query in order to obtain an accurate product_id. That is a concrete when-to-use condition with a stated prerequisite. It stops short of naming the alternative tool or saying when not to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Feegate 数据市场全量目录（按次计费 $0.005 USDC）：全部在售数据产品及其类目、单价、工具清单、调用/买家/销售额、可用率。适合做市场全景分析或采购比价。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses per-call pricing ($0.005 USDC), that the result is the full catalog (implying no filtering), and which metrics are returned. It omits rate limits, caching, and explicit read-only framing, which keeps it at 4 rather than 5.
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 sentences: the first front-loads the resource, price, and returned fields, and the second gives the use case. Dense but every clause is informative, though the field enumeration could be trimmed slightly.
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?
No output schema exists, so the description must convey return content, which it does by listing categories, price, tool list, call/buyer/sales metrics, and availability. For a parameterless read tool this is nearly complete, lacking only output size/pagination expectations.
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 takes zero parameters, so there are no parameter semantics to explain; the baseline for 0 params is 4. The description correctly implies no inputs are needed.
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?
States a specific resource ('全量目录' – the full marketplace catalog) and enumerates its contents: categories, unit price, tool list, calls/buyers/sales, availability. It implies a distinction from list_products/product_detail ('全量'), but does not explicitly name or differentiate against siblings.
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 final clause '适合做市场全景分析或采购比价' gives a usage hint (panoramic market analysis / price comparison), but it never says when NOT to use it or points to fee_quote, list_products, or product_detail as alternatives for narrower tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
健康检查，免费。返回服务状态、收款地址、网络与价目表。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does disclose two useful behavioral facts: the call has no cost and it exposes a payment address, which matters for an agent in a paid marketplace. It says nothing about whether the call has side effects, whether it requires authentication, or about rate limits or latency, which leaves gaps for a tool with zero annotation coverage.
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, front-loaded with the operation and its cost profile. The second half enumerates return fields that the output schema already covers, which is mild redundancy rather than waste, since it still helps an agent pick the tool.
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 output schema exists, so return values do not need spelling out, and the description still adds the two things the schema cannot: that the call is free and that it surfaces a payment address. What is missing is guidance on when in a workflow to call it, which for a health-check tool would be genuinely useful.
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 takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly does not invent parameter discussion.
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 identifies a specific operation ("健康检查") and enumerates what it returns (service status, payment address, network, price list). It is unmistakably different from every sibling (gpu_history, gpu_price, list_gpu_models, market_movers, platform_reliability), though it never explicitly contrasts itself with any of 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?
Saying the call is "免费" (free) implies it is a cheap pre-flight/connectivity check, and the way it is framed suggests calling it before spending money on the paid data tools. However, the description never states when to use this tool rather than a sibling, and it gives no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Feegate 平台自身运营指标（按次计费 $0.005 USDC，30 天窗口）：真实访问量、独立访客、AI 爬虫 / 搜索引擎抓取明细（哪家 AI 来抓过、抓了多少次）、热门页面、地区分布。衡量'这个市场有没有真实 Agent 流量'时用。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It adds genuinely useful metadata: per-call cost ($0.005 USDC), a billing model, and a fixed 30-day window, which tells the agent to avoid repeated calls. It doesn't discuss auth or the numeric return format, but for a zero-parameter stats read the risk surface is small.
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?
One compact sentence plus a usage clause, front-loaded with the resource and cost before the metric enumeration. The long parenthetical list is dense but every item is a real capability; nothing is filler, though it's near the limit of what one sentence should carry.
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?
With no parameters and no output schema, the description must convey what comes back, and the enumerated metrics do that adequately. Gaps remain around response shape (time series vs. aggregate, numeric units), but for a zero-arg, low-risk read it is nearly complete.
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?
Zero parameters, so there is nothing to misinterpret; the description correctly avoids inventing parameters. Baseline for a 0-param tool applies, with a small note that the 30-day window is fixed rather than configurable, which preempts a request for a date argument.
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?
States a specific resource (the Feegate platform's own operational metrics) and enumerates the exact content: visits, unique visitors, AI crawler/search-engine fetch breakdown, top pages, geography. None of the sibling tools (fee_quote, list_products, product_detail, ping) touch platform-level telemetry, so it's unmistakably distinct.
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 closing clause "衡量'这个市场有没有真实 Agent 流量'时用" gives a concrete decision context for invoking it. It doesn't name an alternative or state exclusions, but the sibling set (product/catalog/pricing tools) doesn't plausibly compete with a stats endpoint, so the guidance is sufficient without being maximally explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查单个数据产品的完整档案（按次计费 $0.002 USDC）：提供的全部 MCP 工具清单、累计调用次数、买家数、销售额、可用率、数据许可、结算地址、简介。示例: product_detail(product_id='gpu-market')。
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does disclose the critical trait that this is a paid call costing $0.002 USDC. It also enumerates what data is returned, making the read scope clear. It does not explain the payment flow or what happens if funds are insufficient, which keeps it from a 5.
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 dense sentence followed by a compact example, with the core action and cost front-loaded. The long list of returned fields earns its place because there is no output schema, though the sentence is somewhat packed.
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?
There is no output schema or annotations, so the description must cover both behavior and returns; it does so by enumerating the profile fields and disclosing the per-call price. The main remaining gap is operational detail around payment and authorization, which is relevant for a paid tool.
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% for the one parameter, so the description must compensate. It identifies the parameter as a product_id and provides a concrete example value ('gpu-market'), which adds useful format context, but it does not describe accepted ID forms or lookup behavior.
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 states a specific verb and resource: retrieve the full profile of a single data product. The word 'single' implicitly distinguishes it from list-oriented siblings like list_products and marketplace_catalog, but it never names those alternatives explicitly.
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?
Usage is only implied by 'single data product full profile' versus the sibling list tools. There is no explicit guidance on when to use this instead of list_products or marketplace_catalog, and no stated prerequisites such as needing a funded account before paying the $0.002 USDC fee.
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.
fee_quotelist_productsmarketplace_catalogpingplatform_statsproduct_detail8 pay-per-call web intel tools over MCP. Free discovery, calls settle in USDC on Base (x402).
x402 pay-per-call APIs over MCP, settled in USDC on Base for autonomous agents and developers.
Pay-per-call x402 MCP: 22 agent APIs on Base USDC. Crypto, onchain reads, repo safety. From $0.001
9 pay-per-call company intel tools over MCP. Free discovery, calls settle in USDC on Base (x402).
Add one secure layer between your agents and this server.