Skip to main content
Glama
deenesjakoruzh
stagproject

Mirelia-Structured-Data-Marketplace

by stagproject
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

USPTO Structured Patent Marketplace (MCP Server)

USPTO patent data marketplace powered by the Model Context Protocol (MCP) and x402 on-chain payments. Provides AI-optimized JSON patent datasets for competitive intelligence, prior art search, R&D agents, LLMs, and quants. Currently exclusively hosting AI-ready patents from IPC/CPC Sections G (Physics & Computing) and H (Electricity).

Core Architecture & Performance:

  • High-Throughput ETL Pipeline: Engineered with Google Cloud Run, capable of processing up to 6,000 USPTO XML documents daily.

  • Advanced AI Enrichment: Leverages Gemini Batch APIs for asynchronous, large-scale data parsing, extracting key claims, business value propositions, and AI-driven importance scores.

  • Continuous Updates: Currently hosting over 3,000+ AI-ready patents, securely maintained and continuously expanded via daily automated pipelines.

Discovery & connect (xpay + MCP)

Primary URL for agents (xpay proxy):

https://mirelia-structured-data-marketplace.mcp.xpay.sh/mcp?key=YOUR_XPAY_KEY

Get an API key at xpay.tools. Search the catalog with xpay_discover(query: "USPTO patent competitive intelligence") on the master MCP endpoint.

Discovery file

URL

llms.txt (xpay)

https://mirelia-structured-data-marketplace.mcp.xpay.sh/llms.txt

skill.md (xpay)

https://mirelia-structured-data-marketplace.mcp.xpay.sh/skill.md

mcp.json

https://mirelia-structured-data-marketplace.mcp.xpay.sh/.well-known/mcp.json

MCP Registry

io.github.stagproject/mirelia-structured-data-marketplace

GitHub spec

llms.txt

Upstream (Cloud Run): https://mirelia-structured-data-marketplace-1065601264332.us-central1.run.app — serves /llms.txt, /.well-known/mcp.json, and MCP at /mcp. Register this URL in the xpay publisher dashboard.

Deploy to Cloud Run

gcloud run deploy mirelia-structured-data-marketplace `
  --source . `
  --region us-central1 `
  --allow-unauthenticated `
  --port 8080

After deploy, confirm xpay upstream URL matches the new Cloud Run URL, then re-sync tools in the xpay dashboard.

xpay publisher checklist (required for inbound calls)

  1. Upstream URL in xpay.tools → MCP Servers:
    https://mirelia-structured-data-marketplace-1065601264332.us-central1.run.app/mcp

  2. Pricing: set search_single_patents and search_packages to $0 or $0.01; purchase tools can stay higher (on-chain data fee is separate).

  3. Verification: Account → Creator Settings → Apply with GitHub stagproject/mirelia-structured-data-marketplace (do not use mirelia.site).

  4. Re-sync tools after deploy so xpay regenerates llms.txt / skill.md from updated descriptions.

  5. Optional: request Competitive Intelligence collection placement via xpay support.

MCP Registry

Republish server.json when the public URL changes:

mcp-publisher publish ./server.json

Related MCP server: patent-mcp

🚀 Directives for Autonomous Trading Agents (MPP v1.0 Protocol)

You are authorized to acquire data following this strictly defined 3-step 402 Payment workflow. NEVER hallucinate transaction hashes. Dual-wallet support (EOA and AA) is fully implemented.

Phase 1: Discover & Evaluate

Use discovery tools to find target data.

  • search_single_patents: Query individual patents ($0.50) using primary_cpc, cross_domain_cpc, or keyword. Returns lightweight ROI metadata and patent_id.

  • search_packages: Query bulk packages using search_query for large-scale evaluation. Returns package_tag.

Phase 2: Request Payment Instructions (402 Flow)

Call the purchase tool with the target ID/Tag and network, but LEAVE tx_hash EMPTY.

  • Tools: purchase_single_patent or verify_crypto_payment_and_deliver.

  • Args: {"patent_id": "...", "network": "polygon"} or {"package_tag": "...", "network": "base"}

  • Response: The server returns a 402 Payment Required object containing exact cryptographic payloads bound by HMAC.

Phase 3: Execute & Claim

Execute the payload strictly based on your wallet architecture:

  1. EOA (Standard Wallet): Broadcast transaction_payload.

  2. AA (Smart Contract Wallet): Broadcast aa_transaction_payload (Automatic ERC20 W-Token routing. Critical for Oasis network). After on-chain confirmation, call the exact same purchase tool AGAIN, adding the resulting tx_hash to claim the data.

🧬 Data Schema & Strict Definition

Datasets bypass raw XML/HTML parsing, injecting pre-computed insights directly into the context window. To ensure zero-hallucination ingestion, the following strict schema is enforced:

  • id (UUID): Internal unique identifier.

  • patent_id (String): Official publication number (e.g., "US12519999B2").

  • assignee / inventor (Array[String]): Standardized corporate entities and individuals.

  • primary_cpc (String): Main Cooperative Patent Classification code.

  • secondary_cpcs (Array[String]): Cross-domain classification codes.

  • importance_p (String): Proprietary AI-evaluated scoring based on technological breakthrough and structural claim strength.

  • attr_tech_stack (Array[String]): Explicit core technologies and architectures extracted from the text.

  • biz_target_ind (Array[String]): Applicable target industries and commercial sectors.

  • biz_value_prop (String): Deep strategic analysis detailing specific technical problems solved, ROI, and commercial monetization potential.

  • r2_url (String): Direct CDN link to the full raw JSON file.

  • _metadata (Stringified JSON): Contains source_hash and processed_at for cryptographic data provenance. Must be parsed by the agent.

🗃️ Real-World Evidence (Data Sample)

Use this representative record to pre-map your ingestion logic before purchase.

{
  "id": "1c724ae7-c738-447e-b233-4ae6c2185f37",
  "patent_id": "US12519999B2",
  "country_code": "US",
  "assignee": [
    "Sonos, Inc."
  ],
  "inventor": [
    "Paul Andrew Bates"
  ],
  "filing_date": "2023-08-14",
  "publication_date": "2026-01-06",
  "title": "Location based playback system control",
  "abstract": "Example implementations may involve using a prompt to prevent inadvertent control or playback of audio content...",
  "importance_p": "65",
  "primary_cpc": "H10",
  "secondary_cpcs": [
    "G05",
    "G06",
    "G11"
  ],
  "attr_tech_stack": [
    "Proximity Sensing",
    "User Interface Design",
    "Network Communication",
    "Distributed Systems"
  ],
  "biz_target_ind": [
    "Consumer Electronics",
    "Smart Home",
    "Internet of Things",
    "Audio Systems"
  ],
  "biz_value_prop": "This technology addresses the problem of inadvertent or erroneous remote control of multi-room media playback systems by implementing a proximity-based interface gating mechanism. By dynamically restricting or prompting user control based on the physical proximity of the mobile device to target playback hardware, it reduces user error in multi-room environments, improves operational intent accuracy, and optimizes the user interface for large-scale media deployments.",
  "r2_url": "[https://cdn.mirelia.site/patents/en/uspto/2026/US12519999B2.json](https://cdn.mirelia.site/patents/en/uspto/2026/US12519999B2.json)",
  "_metadata": "{\"source_hash\": \"a95ae76f8d359dbfbd40d2e2ff095e22b65978d20b7804d31cc9dcba452dc0ed\", \"processed_at\": \"2026-05-02T07:02:33.288016Z\", \"source_bundle\": \"USPTO\"}"
}

🧠 Technological Scope (Semantic Routing Index)

This server strictly specializes in the following high-value technological sectors:

  • G (Physics & Computing):

  • G01: Measuring, Testing, Sensors (e.g., LiDAR, Radar, ToF Sensors, Quantum Sensors).

  • G05: Control or Regulating Systems.

  • G06: Computing, Calculating, Counting (e.g., AI/ML, Data Processing, Computer Vision, Quantum Algorithms).

  • G11: Information Storage.

  • G16: Information and Communication Technology (ICT) specially adapted for specific application fields (e.g., Health Informatics, Bioinformatics).

  • H (Electricity & Communication):

  • H01: Basic Electric Elements (e.g., Semiconductors, Solid-State Batteries, Quantum Hardware).

  • H04: Electric Communication Technique (e.g., 5G/6G, Network Security, Wireless Protocols, Cloud Collaboration).

  • H10: Semiconductor Devices, Electric Solid-State Devices (e.g., Advanced Memory, Photovoltaics).

Available Tools

4 tools
purchase_single_patentAInspect
[COST: 0.0001 USDC (API Fee) + 0.50 USDC (Data Price)]
Verifies on-chain payment and delivers the FULL structured JSON dataset for a single patent.

[AGENTIC WORKFLOW (MPP v1.0 402 Payment Flow)]:
This is a mandatory 2-step process. Do NOT hallucinate a tx_hash.
STEP 1: Call this tool with ONLY 'patent_id' and 'network'. Leave 'tx_hash' EMPTY. The server will return a 402 Payment Required response containing a 'transaction_payload'.
STEP 2: You MUST securely execute/broadcast the exact 'transaction_payload' on the blockchain using your wallet. This payload contains the required cryptographic HMAC memo to bind your payment to the product.
STEP 3: Once the transaction is confirmed on-chain, call this exact tool AGAIN, providing the 'patent_id', 'network', and the resulting 66-character 'tx_hash'.

[SUPPORTED NETWORKS]: 'polygon' (USDC), 'base' (USDC), 'oasis' (ROSE natively via EOA, or WROSE via AA wallets). Default is 'polygon'.

[EXAMPLE ARGUMENTS - MINIMAL (Step 1 - Request Payment Info)]:
{"patent_id": "US12449246B2"}

[EXAMPLE ARGUMENTS - MAXIMAL (Step 3 - Claim Data)]:
{"patent_id": "US12449246B2", "network": "polygon", "tx_hash": "0x123abc456def7890123abc456def7890123abc456def7890123abc456def7890"}
ParametersJSON Schema
NameRequiredDescriptionDefault
networkNoBlockchain network. Defaults to 'polygon' (USDC). Supports 'base' or 'oasis'.polygon
tx_hashNoThe transaction hash. LEAVE EMPTY first to retrieve payment instructions.
patent_idYesThe patent_id obtained from search_single_patents.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses costs (0.0001 USDC API fee + 0.50 USDC data price), the 402 payment flow requiring HMAC memo, and the need to broadcast transaction securely. With no annotations, description fully carries behavioral burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured with sections (cost, workflow, networks, examples) but somewhat lengthy. Every sentence is informative; no excessive fluff. Could be slightly more concise but remains clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (payment flow, 3 parameters, output schema exists), the description covers the entire multi-step process, network details, and example calls. Output schema exists, so return values not needed. Fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% but description adds workflow context for each parameter (tx_hash left empty first, then filled; network defaults to polygon). Also provides example arguments. Adds significant value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it verifies on-chain payment and delivers a structured JSON dataset for a single patent. It distinguishes from siblings like search_single_patents (searching vs purchasing).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly outlines the 2-step workflow: first call with empty tx_hash, then after transaction confirmation, call again with tx_hash. Provides supported networks, defaults, and example arguments. No ambiguity about when to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_packagesAInspect
[COST: 0.0001 USDC (API Fee)]
Exploration tool for USPTO bulk patent datasets (10, 100, 1000 items per pack). 
Best for large-scale R&D or commercial analysis.
If 'search_query' is empty, returns the full catalog of available packages.
If 'search_query' contains a CPC or keyword, returns specific domain packs.

[AVAILABLE DOMAINS]: 
G01(Measurement), G02(Optics), G03(Photography), G04(Horology), G05(Control), 
G06(Computing), G07(Checking), G08(Signaling), G09(Displays), G10(Acoustics), 
G11(Storage), G12(Instruments), G16(Healthcare ICT), G21(Nuclear), H01(Electric Elements), 
H02(Power), H03(Circuitry), H04(Communication), H05(Misc), H10(Solid State)

[EXAMPLE ARGUMENTS - MINIMAL (List All Catalogs)]:
{}

[EXAMPLE ARGUMENTS - MAXIMAL (Search Specific Domain & Limit)]:
{"search_query": "G06_100", "limit": 10}
ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of results to return (max 100).
search_queryNoSearch keywords like 'G01', 'H04'. Leave blank for all.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses cost (0.0001 USDC), behavior for empty vs. non-empty query, and available domains. No annotations provided, so description carries burden; covers key aspects well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with sections (cost, description, domains, examples). Slightly verbose due to domain list and examples, but each part adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers behavior, parameters, cost, examples, domain list. Output schema exists but not shown; description is sufficient for agent to use tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, description adds meaning: explains empty query returns catalog, provides example arguments, and lists domains. Adds value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it's an exploration tool for USPTO bulk patent datasets, distinguishing from siblings like purchase_single_patent and search_single_patents. The action and resource are explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides use case ('Best for large-scale R&D or commercial analysis'), examples for minimal and maximal arguments, and domain list. Lacks explicit when-not to use, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_single_patentsAInspect
[COST: 0.0001 USDC (API Fee)]
Searches for high-value individual patents ($0.50 each) from a continuously expanding, daily-updated USPTO database.
Returns lightweight evaluation data: [patent_id, title, importance_p, publication_date, primary_cpc, secondary_cpcs, biz_target_ind].
Supports pagination via the 'offset' parameter.

[AVAILABLE PRIMARY CPCs]: 
G01(Measurement/Testing), G02(Optics), G03(Photography), G04(Horology), G05(Control Systems), 
G06(Computing/Data Processing), G07(Checking Devices), G08(Signaling), G09(Displays/Cryptography), 
G10(Acoustics/Speech), G11(Info Storage), G12(Instrument Details), G16(Specific ICT/Healthcare), 
G21(Nuclear), H01(Basic Electric Elements), H02(Electric Power), H03(Electronic Circuitry), 
H04(Communication), H05(Misc Electric), H10(Solid State Devices)

[EXAMPLE ARGUMENTS - MINIMAL]:
{"primary_cpc": "G06"}

[EXAMPLE ARGUMENTS - MAXIMAL]:
{"primary_cpc": "H02", "cross_domain_cpc": "G06", "keyword": "thermal power generation", "min_score": 80, "limit": 50, "offset": 50}
ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of results to return (max 100).
offsetNoNumber of results to skip for pagination (e.g., 20 for page 2).
keywordNoSearches only in title.
min_scoreNoMinimum importance_p (0-100).
primary_cpcYesMust be one of the exact codes (e.g., G01, G06, H04).
cross_domain_cpcNoOptional secondary CPC for cross-domain searches.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses cost, database freshness, pagination support, and output structure. However, the cost attribution (API fee vs per patent) is ambiguous, and rate limits or authentication needs are absent. Overall, behavior is well-documented but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with cost, purpose, output, pagination, CPC list, and examples. It is informative but the CPC list is lengthy; still, every section adds utility. It is front-loaded with cost and purpose, aiding quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 params, 1 required, output schema exists), the description covers purpose, parameter constraints (via CPC list and examples), output format, pagination, and cost. The output schema handles return types, so the description completes the context adequately for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds significant value beyond schema by listing available primary CPCs (not in schema as enum) and providing minimal and maximal example arguments. This clarifies required parameter constraints and usage patterns.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for high-value individual patents from a USPTO database, distinguishing it from sibling tools like search_packages that likely search patent packages. It specifies the returned fields and includes a cost indicator, making the purpose highly specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly guide when to use this tool vs alternatives (e.g., search_packages). It provides examples and pagination details, but lacks explicit when-to-use or when-not-to-use guidance, relying on implicit understanding from the tool name and sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_crypto_payment_and_deliverAInspect
[COST: 0.0001 USDC (API Fee) + Bulk Package Price]
Verifies on-chain payment and delivers the FULL JSON dataset URL for bulk packages.

[AGENTIC WORKFLOW (MPP v1.0 402 Payment Flow)]:
This is a mandatory 2-step process. Do NOT hallucinate a tx_hash.
STEP 1: Call this tool with ONLY 'package_tag' and 'network'. Leave 'tx_hash' EMPTY. You will receive a 402 response with a 'transaction_payload'.
STEP 2: Execute/broadcast the 'transaction_payload' exactly as provided to apply the HMAC cryptographic memo. Do not modify the payload data.
STEP 3: After confirmation, call this tool AGAIN with the exact 'package_tag', 'network', and the resulting 'tx_hash' to receive the dataset.

[EXAMPLE ARGUMENTS - MINIMAL (Step 1 - Request Payment Info)]:
{"package_tag": "G01_10_001"}

[EXAMPLE ARGUMENTS - MAXIMAL (Step 3 - Claim Data)]:
{"package_tag": "G01_10_001", "network": "base", "tx_hash": "0xabcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890"}
ParametersJSON Schema
NameRequiredDescriptionDefault
networkNoThe network (base, polygon, oasis). Defaults to 'polygon'.polygon
tx_hashNoTransaction hash. LEAVE EMPTY for 402 request.
package_tagYesThe tag of the package to purchase.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses cost, that it returns a 402 response with transaction_payload, and that broadcasting the payload is required. It does not mention authentication or rate limits, but the nature of crypto payment is well explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer but well-structured with sections for cost, workflow steps (numbered), and examples. It front-loads key information and every sentence contributes to understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the tool (payment flow, multiple steps, output schema exists), the description is complete. It covers the workflow, parameters, examples, and cost. The output schema is mentioned in context, so return values do not need explicit description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds significant meaning: explains tx_hash usage (empty for step 1), network default, and provides examples that clarify parameter interactions beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool verifies on-chain payment and delivers a JSON dataset URL for bulk packages. It differentiates from siblings like purchase_single_patent and search_packages by specifying it is for bulk packages and involves a two-step payment flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit mandatory 2-step workflow instructions, including when to leave tx_hash empty and when to call again. It advises not to hallucinate tx_hash. However, it does not explicitly state when not to use this tool versus alternatives beyond the context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv1.0.11
    • Addedpurchase_single_patent
    • Changedsearch_packages2 fields changed
      • addedInput schema / properties / limit
        Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": 20,
+  "description": "Number of results to return (max 100).",
+  "title": "Limit"
+}
      • changedInput schema / properties / search_query / description
        Previous value: -"Search query. Use keywords like 'USPTO', 'G01', 'Physics', or 'Electricity'. Leave blank for all packages."New value: +"Search keywords like 'G01', 'H04'. Leave blank for all."
    • Addedsearch_single_patents
    • Changedverify_crypto_payment_and_deliver9 fields changed
      • addedInput schema / properties / network / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / network / default
        Added value: +"polygon"
      • changedInput schema / properties / network / description
        Previous value: -"The blockchain network used. Must be 'base', 'polygon', or 'oasis'."New value: +"The network (base, polygon, oasis). Defaults to 'polygon'."
      • removedInput schema / properties / network / type
        Removed value: -"string"
      • addedInput schema / properties / tx_hash / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / tx_hash / default
        Added value: +null
      • changedInput schema / properties / tx_hash / description
        Previous value: -"The transaction hash of the completed payment."New value: +"Transaction hash. LEAVE EMPTY for 402 request."
      • removedInput schema / properties / tx_hash / type
        Removed value: -"string"
      • changedInput schema / required
        Previous value: -[
-  "tx_hash",
-  "package_tag",
-  "network"
-]New value: +[
+  "package_tag"
+]
  2. 2 tool updatesv0.1.2
    • Changedsearch_packages1 field changed
      • changedInput schema / properties / search_query / description
        Previous value: -"Search query. Leave blank for all packages."New value: +"Search query. Use keywords like 'USPTO', 'G01', 'Physics', or 'Electricity'. Leave blank for all packages."
    • Changedverify_crypto_payment_and_deliver3 fields changed
      • addedInput schema / properties / network / description
        Added value: +"The blockchain network used. Must be 'base', 'polygon', or 'oasis'."
      • addedInput schema / properties / package_tag / description
        Added value: +"The tag of the package to purchase."
      • addedInput schema / properties / tx_hash / description
        Added value: +"The transaction hash of the completed payment."
  3. 2 tool updatesv0.1.0
    • First observedsearch_packages
    • First observedverify_crypto_payment_and_deliver
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a distinct purpose: searching vs purchasing, individual vs bulk patents. No overlap or confusion.

Naming Consistency5/5

All tool names follow snake_case with verb_noun pattern, e.g., purchase_single_patent, search_packages. Consistent and predictable.

Tool Count5/5

Four tools cover the core functionality (search and purchase for both single and bulk patents) without being excessive or insufficient.

Completeness4/5

The set covers search and purchase lifecycle. Minor gap: no tool to list past purchases or manage account, but core workflows are complete.

Maintenance

ActivityInactive
ResponsivenessResponsive

Resources

Related MCP Connectors

Related MCP Servers

  • Filecoin Data Broker MCP

    fildb
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables AI agents to discover, purchase, and query blockchain-based datasets using Filecoin/IPFS storage with Ethereum NFT access controls and Lit Protocol encryption. Provides a decentralized marketplace for secure dataset trading with automatic purchase workflows and SQL query capabilities.
    0
    -

  • patent-mcp

    goveda
    A
    license
    Not graded
    quality
    D
    maintenance
    AI-powered patent search and analysis across 220M+ global patents. Semantic search, prior art discovery, novelty/patentability reports, and patent content retrieval.
    Apache 2.0
  • Almured by Almured

    Almuredofficial

    Almured
    A
    license
    Not graded
    quality
    D
    maintenance
    Marketplace where AI agents ask AI agents that have live or proprietary data. Anyone needing answers can ask. Anyone with the data can answer.
    2
    MIT

Appeared in Searches