Free read-only tools: Market402 x402 index search, operator track records, PDF price quotes.
Scored across 6 tools
The tools are generally distinct, each handling a unique function like catalog retrieval, service searching, or quality checking. There is minimal overlap, though the general concept of 'get' is repeated across different resources.
The naming convention is highly consistent, primarily utilizing a `verb_noun` structure (e.g., get_catalog, search_x402_services, quote_parse). The use of suffixes like '_precheck' fits naturally within the pattern.
With only 6 tools, the set is extremely well-scoped and appropriate for what appears to be a curated entry point or discovery layer of a complex marketplace platform.
The surface is strong for discovery and pre-validation (getting quotes, checking samples, running pre-checks). However, there appears to be a gap in direct post-purchase operations or the actual execution/fulfillment of a service.
Mart402 product catalog: all products, prices, payment config, error codes, rate limits. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| body | Yes | JSON body of the underlying call (see /samples/{product} for each product's shape) |
| status | Yes | HTTP status of the underlying call (200 result, 402 payment terms, 4xx input error) |
| how_to_pay | No | |
| receipt_id | No | set on paid results; free re-fetch via get_receipt |
| payment_required | No | true when status is 402: body holds x402 payment terms, not a result. Pay and call again with x_payment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds genuinely non-structured context: the call is free, and it returns payment config, error codes, and rate limits — useful in an x402/pay-per-call ecosystem. It stops short of saying whether the catalog is cached or how often it changes.
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 telegraphic sentence with the resource front-loaded and the cost signal last; nothing is wasted. The fragment style ('Free.') is slightly clipped but still unambiguous and appropriately sized for a zero-arg 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?
With zero parameters, rich annotations, and an output schema that already documents return values, the description needs only to identify the resource and its scope — which it does. Enumerating the returned categories (prices, payment config, error codes, rate limits) is a helpful bonus rather than a requirement.
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 per the rubric the baseline is 4 and there is nothing for the description to disambiguate. No parameter detail is required or missing.
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 (Mart402 product catalog) and enumerates what it contains: products, prices, payment config, error codes, rate limits. An agent can tell this is a discovery/metadata endpoint rather than a data-processing tool. It does not distinguish itself from the one plausible sibling, search_x402_services, which is a minor gap.
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 only usage signal is the trailing word 'Free,' which implies a cost advantage over paid x402 siblings but never states when to call this versus search_x402_services. There is no statement of prerequisites, ordering, or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free recorded sample response for a paid product (from real production runs, marked sample:true) - see the exact response shape before paying anything. Available: document-pipeline, enrich, extract, jp-bonus-net, jp-business-days, jp-company, jp-consumption-tax, jp-crypto-tax, jp-dependent-threshold, jp-mortgage, jp-overtime-wage, jp-payroll-net, jp-payroll-suite, jp-payslip-audit, jp-retirement-tax, jp-social-insurance, meal-vision, ocr, parse, pdf-info, pdf-merge, pdf-pages, portrait-analysis, report-pack, structured, style-profile, style-report, verify.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | One of: document-pipeline, enrich, extract, jp-bonus-net, jp-business-days, jp-company, jp-consumption-tax, jp-crypto-tax, jp-dependent-threshold, jp-mortgage, jp-overtime-wage, jp-payroll-net, jp-payroll-suite, jp-payslip-audit, jp-retirement-tax, jp-social-insurance, meal-vision, ocr, parse, pdf-info, pdf-merge, pdf-pages, portrait-analysis, report-pack, structured, style-profile, style-report, verify. Product id (see the enum) |
| Name | Required | Description |
|---|---|---|
| body | Yes | JSON body of the underlying call (see /samples/{product} for each product's shape) |
| status | Yes | HTTP status of the underlying call (200 result, 402 payment terms, 4xx input error) |
| how_to_pay | No | |
| receipt_id | No | set on paid results; free re-fetch via get_receipt |
| payment_required | No | true when status is 402: body holds x402 payment terms, not a result. Pay and call again with x_payment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds genuinely useful behavioral context beyond that: the payload is a *recorded* production response, it is free, and it is flagged with sample:true, which tells the agent the data is illustrative and not live processing of its own input.
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 first sentence is well front-loaded and earns its place, but the trailing 'Available: ...' clause reprints all 28 enum members that already appear in the schema, roughly doubling the length with zero added information.
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?
An output schema exists, so return values need not be explained, and the single parameter is fully documented. The description covers what the sample is, where it comes from, and how it is flagged, leaving only minor gaps (e.g. whether the sample corresponds to the same shape as the live paid call).
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 the single 'product' parameter is a fully enumerated, documented string, so the schema carries the semantics. The description's product list simply restates the same enum values verbatim and adds no syntax, format, or selection meaning beyond it — baseline 3.
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+resource ('Free recorded sample response for a paid product') and makes the scope explicit: it returns a preview of the exact response shape rather than doing the work. This cleanly separates it from the paid sibling tools (document_pipeline, enrich_company, ocr_image, etc.), which an agent can distinguish without opening either 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?
Gives a clear selection context: 'see the exact response shape before paying anything', i.e. call this when previewing a paid product's output rather than invoking the paid tool. It does not name an explicit alternative or a when-not-to-use condition, so it falls short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free 12-week measured score history for any x402 operator from the Market402 index (weekly series, trend, volatility, badge). Check a seller's record before your agent pays an unfamiliar endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| operator | Yes | operator domain, e.g. mart402.com |
| Name | Required | Description |
|---|---|---|
| body | Yes | JSON body of the underlying call (see /samples/{product} for each product's shape) |
| status | Yes | HTTP status of the underlying call (200 result, 402 payment terms, 4xx input error) |
| how_to_pay | No | |
| receipt_id | No | set on paid results; free re-fetch via get_receipt |
| payment_required | No | true when status is 402: body holds x402 payment terms, not a result. Pay and call again with x_payment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, openWorld, and non-destructive behavior. The description adds meaningful context beyond those: the data is free, spans a 12-week window, and includes weekly series, trend, volatility, and badge, which helps the agent understand the payload without contradicting 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?
Two sentences, front-loaded with the core resource and data content, followed immediately by the usage condition. 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 simple read-only lookup with an output schema and complete annotations, the description supplies what is needed: what the tool returns, what the 12-week window means, and when to invoke it. Parameter requirements are fully documented in the schema, so no critical gap remains.
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 one parameter with 100% schema description coverage, including an example domain. The description adds no syntax or format details beyond the schema, 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?
States a specific resource — 12-week measured score history for an x402 operator from the Market402 index — with the key returned dimensions (weekly series, trend, volatility, badge). It does not explicitly differentiate from sibling tools such as search_x402_services, so it falls short of a 5.
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?
Provides a clear use condition: 'Check a seller's record before your agent pays an unfamiliar endpoint.' It gives context but does not name alternatives or when-not-to-use cases, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE analyzability check before paying for portrait_analysis: is a face detectable, is the photo quality good enough (clipping/color cast)? Deterministic, no LLM. 10/hour/IP.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | No | Absolute http(s) URL of the image (JPEG/PNG/WebP) | |
| image_base64 | No | Base64-encoded image bytes (alternative to image_url) |
| Name | Required | Description |
|---|---|---|
| body | Yes | JSON body of the underlying call (see /samples/{product} for each product's shape) |
| status | Yes | HTTP status of the underlying call (200 result, 402 payment terms, 4xx input error) |
| how_to_pay | No | |
| receipt_id | No | set on paid results; free re-fetch via get_receipt |
| payment_required | No | true when status is 402: body holds x402 payment terms, not a result. Pay and call again with x_payment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by disclosing that the check is deterministic and uses no LLM, and by stating a concrete rate limit of 10/hour/IP. Annotations already cover safety traits like read-only and idempotent, and the description adds useful operational context.
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?
Front-loads the free pre-check purpose, then tightly lists the checks, deterministic nature, and rate limit. Every clause earns its place with no redundancy.
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 two-parameter pre-check tool with full schema coverage and an output schema, the description covers purpose, usage routing, determinism, and rate limit. Nothing essential for correct invocation 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 description coverage is 100% and both parameters are fully documented there, so the description is not required to add parameter meaning. It does not add syntax or format details beyond the schema, which is the baseline-3 case.
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: a free analyzability check on a portrait photo, including what it verifies (face detection, quality issues like clipping/color cast). It explicitly positions itself as distinct from portrait_analysis by being the pre-check before paying.
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?
Names the alternative tool portrait_analysis and states the condition for using this one: before paying for the full analysis. This gives an agent a clear routing rule without needing to inspect either schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free quote for PDF parsing: page count, route (text/scan-OCR) and the exact final price, before any payment. Use the returned quote_id with parse_document (on /mcp or /mcp/docs).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | PDF URL |
| Name | Required | Description |
|---|---|---|
| body | Yes | JSON body of the underlying call (see /samples/{product} for each product's shape) |
| status | Yes | HTTP status of the underlying call (200 result, 402 payment terms, 4xx input error) |
| how_to_pay | No | |
| receipt_id | No | set on paid results; free re-fetch via get_receipt |
| payment_required | No | true when status is 402: body holds x402 payment terms, not a result. Pay and call again with x_payment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive, so the safety profile is done. The description adds genuinely new context the annotations don't carry: the operation is free, no payment occurs, and the returned quote_id is the credential for the follow-up parse_document call.
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, no filler, and the value proposition ('free', 'exact final price', 'before any payment') is front-loaded where the agent needs it.
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?
An output schema exists, so return-value documentation isn't required, and the description still previews the key return fields and the quote_id handoff. The only gap is any precondition on the input URL, which is minor for this simple one-param 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?
One parameter with 100% schema description coverage ('PDF URL'), so the schema handles the semantics. The description adds nothing about URL constraints (public accessibility, size limits), so the baseline 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?
States a specific verb and resource (quote a PDF parse) plus what the quote contains: page count, route, and exact price. It clearly distinguishes itself from parse_document by framing itself as the free pre-payment step.
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?
Explicitly positions the tool as coming 'before any payment' and tells the agent to use the returned quote_id with parse_document. It doesn't spell out when to skip this tool (e.g., if a quote is already held), so it stops short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Market402 verified index of the whole x402 economy by capability (e.g. 'ocr', 'market-data'). Every result is a real, probed resource with a measured 402 Score. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Capability keyword, e.g. 'ocr', 'market-data', 'weather' | |
| limit | No | Maximum results (default 10) |
| Name | Required | Description |
|---|---|---|
| body | Yes | JSON body of the underlying call (see /samples/{product} for each product's shape) |
| status | Yes | HTTP status of the underlying call (200 result, 402 payment terms, 4xx input error) |
| how_to_pay | No | |
| receipt_id | No | set on paid results; free re-fetch via get_receipt |
| payment_required | No | true when status is 402: body holds x402 payment terms, not a result. Pay and call again with x_payment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely useful behavioral context beyond that: results are real probed resources, each carries a measured 402 Score, and the call is free — none of which the annotations convey.
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, front-loaded with the action and index identity, then the differentiator (verified/probed, scored) and the cost note. No 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?
With an output schema present, return structure needn't be explained, and the description covers scope, result trust, and cost. It could say slightly more about query semantics (multi-word, matching behavior) but is essentially complete for a two-parameter read 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 100%, so both parameters (q, limit) are already documented in the schema, including defaults and example keywords. The description's mention of 'by capability' and examples largely duplicates the schema rather than adding syntax or validation detail, so baseline 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?
States a specific verb (Search) and resource (the Market402 verified index of x402 services) with the query dimension (by capability) called out. An agent immediately knows this is a capability-keyword search over a curated service catalog, distinct from every sibling tool listed.
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 phrase 'Search ... by capability' implies when to use it, and the examples ('ocr', 'market-data') guide query construction, but there is no explicit when-to-use/when-not statement and no named alternative among the many unrelated siblings. Usage is implied rather than specified.
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.
get_catalogget_sampleoperator_historyportrait_precheckquote_parsesearch_x402_servicesSEC filings, insider trades, 13F, IPO calendar, macro & FX MCP tools via x402.
Four market-statistics tools + a free qd_ key by email: 1 anonymous look, then 10 calls/UTC day.
Read-only market research: index funds, event cards, CLOB data, fund analytics. No orders.
Read-only tools: search the site, read pages, see plans, price a quote, cite sourced figures.
Add one secure layer between your agents and this server.
