F
licenseNot graded
qualityC
maintenanceMCP server for USPTO patent prior-art search, enabling keyword search, ranking, and date filtering via Claude, Cursor, or Windsurf.
-
patent-mcp
This server provides patent information retrieval and analysis tools for AI agents. It includes:
search_patents: Search patents by keywords, assignee, inventor, date ranges, country, and status, with support for pagination, Boolean operators, and output in markdown or JSON.
find_similar_patents: Find patents similar to an existing patent (by publication number) or a free-text idea. Multiple strategies are available (auto, provider_similar, semantic, classification) with filters for date, country, and family exclusion.
get_patent: Retrieve detailed patent information (bibliographic data, abstract, claims, description, classifications, citations, family) by publication number, with section selection and output format options.
list_patent_providers: List available data sources (e.g., Google Patents, EPO OPS) and their capabilities.
Key features include a pluggable data source architecture with per-call provider switching, configurable via environment variables (default provider, language, timeouts), robust handling of HTML-based providers with automatic validation and fallback, and built-in rate limiting and retry mechanisms.
Provides patent search and retrieval from Google Patents, including keyword/assignee/inventor/date searches, similar patent discovery, and fetching patent summaries, claims, descriptions, classifications, citations, and family information.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@patent-mcpSearch for solid-state battery patents by Toyota from 2020 onward"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
patent-mcp
特許情報を取得して Agent にコンテキストとして渡すための、ローカル実行の MCP サーバー。
データソースはインターフェースの背後に隠してあるので、あとから
Google Patents → 特許庁 API → EPO OPS のように差し替え・追加ができる。
ツールも tools/ にファイルを置くだけで増える。
ツール
ツール | 用途 |
| キーワード・出願人・発明者・期間で特許を検索する |
| 既存特許や自由文（アイデア・請求項案）に似た特許を探す |
| 公開番号を指定して要約・請求項・明細書・分類・引用・ファミリーを取得する |
| 利用可能なデータソースと対応機能を確認する |
Related MCP server: patents-mcp
セットアップ
uv sync動作確認:
uv run patent-mcp --helpエディタ / エージェントへの登録
以下、リポジトリの絶対パスを /path/to/patent-mcp と表記する（pwd で確認できる）。
uv のフルパスは which uv で確認する（通常 ~/.local/bin/uv）。
Claude Code
claude mcp add patent -- uv --directory /path/to/patent-mcp run patent-mcpClaude Desktop
claude_desktop_config.json に追加:
{
"mcpServers": {
"patent": {
"command": "uv",
"args": ["--directory", "/path/to/patent-mcp", "run", "patent-mcp"],
"env": { "PATENT_MCP_LANG": "ja" }
}
}
}GitHub Copilot（VS Code）
VS Code の Copilot Chat（Agent モード）は MCP サーバーに対応している。
ワークスペース直下に .vscode/mcp.json を作る（チーム共有したくない場合は
.vscode/mcp.json を .gitignore に入れるか、ユーザー設定側の MCP 設定に書く）。
{
"servers": {
"patent": {
"type": "stdio",
"command": "uv",
"args": ["--directory", "/path/to/patent-mcp", "run", "patent-mcp"],
"env": { "PATENT_MCP_LANG": "ja" }
}
}
}有効化手順:
VS Code でこのリポジトリ（または
.vscode/mcp.jsonを置いたワークスペース）を開くコマンドパレットで
MCP: List Serversを実行し、patentが認識されているか確認（表示されない場合はMCP: Add Serverから同じ内容を登録する）Copilot Chat を Agent モードにする（チャット入力欄のモード切り替え）
ツール一覧（レンチ/ツールアイコン）に
search_patentsなどが並んでいることを確認して使う
ユーザー全体で使い回したい場合は、ワークスペースではなくコマンドパレットの
MCP: Open User Configuration から同じ内容をユーザー設定側に書いてもよい。
VS Code の MCP サポートは変更が速いので、上記でうまくいかない場合は
VS Code 側の最新ドキュメント（Copilot Chat の MCP servers）を確認すること。
設定（環境変数）
変数 | 既定値 | 説明 |
|
| 使用するデータソース |
|
| 本文の言語 |
|
| HTTP タイムアウト（秒） |
|
| 1回の検索で返す上限 |
|
| 1セクションの最大文字数 |
プロバイダ固有の設定は PATENT_MCP_<プロバイダ名>_<キー> で渡す。
例: PATENT_MCP_EPO_OPS_KEY=xxx → settings.options_for("epo_ops") == {"key": "xxx"}
google_patents プロバイダ固有:
変数 | 既定値 | 説明 |
|
| リクエスト間の最小間隔（秒） |
|
| 429/503 を受けたときの再試行回数 |
Google Patents は短時間に連続アクセスすると 503 を返す。
まとめて多数の特許を調べる用途では MIN_INTERVAL を 2〜3 秒に上げるとよい。
使用例（Agent 側の会話）
「全固体電池の界面抵抗低減について、2022年以降の日本の特許を10件調べて」
「JP2020123456A に似た特許を、優先日が2019年より前のものに限って探して」
「この請求項案に近い先行技術がないか調べて: 〈本文〉」
「US9634296B2 の請求項1と、引用されている文献を出して」
HTML構造の変更をどう検知するか
既定のプロバイダは Google Patents の HTML を読むので、Google が構造を変えると壊れる。 やっかいなのは例外を出さずに中身だけ欠ける壊れ方で、放っておくと Agent が 「請求項の無い特許」と誤解して結論を出す。3段構えで検知する。
1. 実行時の自動チェック（常に効く）
毎回の取得でパースの妥当性を自己点検し、怪しければ結果の冒頭に警告を出す。
どの特許にも必ずあるはずのもの（タイトル・要約・請求項・明細書）が空
セクションは存在するのに中身が抽出できない
ページが書いている請求項の件数と、抽出できた件数が食い違う
# JP2020123456A — 蓄電素子、蓄電素子の製造方法
> **取得できていない情報があります**
> - 請求項: ページには16項とあるのに2項しか抽出できていません。内容が欠けています。
>
> この結果だけで「存在しない」と判断せず、元ページを確認してください: ...引用やファミリーは本当に0件のことがあるので対象外。誤検知しない範囲に絞ってある。
2. ライブ契約テスト（触ったときに実行）
uv run python -m pytest -m network実ページに接続し、パーサが依存する11個のセレクタが今も存在するか確認する。
3. オフラインテスト（編集時の回帰防止）
HTML をわざと壊して、上記1の検知が働くことまでテストしている。
テスト
網羅は狙っていない。このプロジェクトのバグは実データで動かしたときにしか 見つからなかったので、テストは「一度やらかした罠の記録」と 「Google の HTML が変わったことの検知」に絞ってある。
uv run python -m pytest # オフライン20件
uv run python -m pytest -m network # ライブ契約テストファイル | 役割 |
| 実際に壊れたパースの再発防止（請求項の潰れ、二重エンコード等） |
| 「特開2020-123456」等の表記ゆれ吸収 |
| データソース差し替えの前提が壊れていないこと |
| 実ページに接続し、依存セレクタが今も存在するか確認 |
tests/fixtures/patent_page.html は実ページのダウンロードではなく、
構造だけを再現した手書きのファイル。実ページを置かないのは、
他社の著作物を取り込むことになるうえ、Google 自身のウィジェット用 API キーが
埋まっていてシークレットスキャナが誤検知するため。
手書きなので「パーサを編集して壊したか」は分かるが、
「そもそも Google の HTML を誤解していたか」は分からない。
そこは -m network のライブ契約テストが実物に当てて確認する。
セレクタを触ったときや、パース結果が変になったときに実行すること。
ライブ契約テストは既定でスキップされる（レート制限を避けるため）。 レート制限中も失敗ではなくスキップになるので、時間をおいて再実行する。
拡張する
データソースを足す
src/patent_mcp/providers/ にファイルを1つ作るだけ。
from . import register
from .base import Capability, PatentProvider, SearchQuery
from ..models import SearchResult
@register
class JpoProvider(PatentProvider):
name = "jpo"
description = "特許庁 特許情報取得API"
capabilities = frozenset({Capability.SEARCH, Capability.BIBLIOGRAPHIC})
requires_credentials = True
async def search(self, query: SearchQuery) -> SearchResult:
token = self.options["token"] # PATENT_MCP_JPO_TOKEN
...未実装のメソッドは基底クラスが NotSupportedError を投げ、ツールが
「このプロバイダは未対応」と Agent に伝える。登録リストの編集は不要
（providers/__init__.py がモジュールを自動検出する）。
PATENT_MCP_PROVIDER=jpo で既定を切り替えられるほか、
各ツールの provider 引数で呼び出しごとに切り替えられる。
ツールを足す
src/patent_mcp/tools/ にファイルを1つ作り、register を定義する。
def register(mcp, ctx):
@mcp.tool()
async def my_tool(...) -> str:
"""Agent 向けの説明。"""
provider = ctx.provider()
...注意
既定の google_patents プロバイダは Google Patents の公開ページを読む非公式実装で、
サイト構造の変更やレート制限の影響を受ける。業務で確実性が必要な場合は、
特許庁の特許情報取得API や EPO OPS のプロバイダを追加して切り替えること。
取得できるのは公開情報であり、権利範囲の解釈や侵害判断は専門家の確認が必要。
Available Tools
4 toolsfind_similar_patentsA
既存特許または自由文に似た特許を探す（先行技術調査・侵害調査向け）。
使い分け:
- 既存の特許を起点にする場合は publication_number を渡す
- 未出願のアイデアや請求項案から探す場合は text を渡す
- 両方渡すと、その特許の周辺をテキストの観点で絞り込む
結果の各件には「どの手法でヒットしたか」が付くので、
提供元の類似判定によるものか、意味検索によるものかを区別できる。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | 発明の説明・請求項の草案・技術課題などの自由文。まだ出願していないアイデアの先行技術を探すときはこちらを使う。文が具体的で長いほど精度が上がる。 | |
| after | No | この日付以降（YYYY-MM-DD） | |
| limit | No | 取得件数 | |
| before | No | この日付以前（YYYY-MM-DD）。先行技術調査では自分の出願日を指定すると効く。 | |
| country | No | 国コードで絞り込む（例: ["JP"]） | |
| provider | No | 使用するデータソース | |
| strategy | No | auto: 提供元の類似文献リストと意味検索を統合（既定）/ provider_similar: 提供元の類似文献リストのみ / semantic: テキストの意味検索のみ / classification: 起点特許と同じ特許分類から探す | auto |
| date_field | No | after/before の基準日 | priority |
| output_format | No | markdown（既定）または json | markdown |
| exclude_family | No | 起点特許と同じパテントファミリーを除外する | |
| publication_number | No | 起点にする特許の公開番号（例: JP2020123456A）。この特許に似た特許を探す。 |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.9/5.0
Behavior3/5
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 discloses that each result includes the matching method (provider similarity vs semantic search), which is helpful behavioral context. However, it does not mention other important traits like whether the operation is read-only, data source behavior, or rate limits, leaving partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded with the main purpose followed by usage guidance. Every sentence contributes value, and the formatting makes the key distinctions easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters and an output schema, the description covers the essential decisions: the starting point, the combination of inputs, and how to interpret results. It does not repeat schema details, and the schema already documents parameters thoroughly. The description is adequately complete for this complexity.
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 description coverage is 100%, giving a baseline of 3. The description adds value beyond the schema by explaining how publication_number and text interact when both are provided ('narrow around that patent from a text perspective'), which is not readily apparent from individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds patents similar to an existing patent or free text, specifically for prior art/infringement searches. This is a specific verb+resource, but it does not explicitly distinguish itself from sibling tools like search_patents, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage patterns: pass publication_number for an existing patent, pass text for unpatented ideas, or both to narrow around a patent. This is clear context for when to use each parameter, but it does not name alternatives or exclusions relative to sibling tools, so it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_patentA
公開番号を指定して特許の中身を取得する。
請求項の文言確認、明細書の読み込み、引用関係やファミリーの把握に使う。 必要なセクションだけを指定すると、コンテキストを無駄に消費しない。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | 本文の言語（ja / en など） | |
| provider | No | 使用するデータソース | |
| sections | No | 取得するセクション: bibliographic, abstract, claims, description, classifications, citations, family。省略時は bibliographic + abstract + claims。description は非常に長いので必要なときだけ指定すること。 | |
| max_chars | No | 1セクションあたりの最大文字数 | |
| output_format | No | markdown（既定）または json | markdown |
| publication_number | Yes | 公開番号。JP2020123456A / US9634296B2 / 特開2020-123456 などの表記ゆれは吸収される。 |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of behavioral disclosure. It adds context about token consumption and section selection, but does not discuss output behavior, error handling, or data freshness. The description is not misleading, but it only partially discloses the tool's behavior beyond the name/schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—two short sentences in the first paragraph and a brief guiding note in the second. It is front-loaded with the primary action, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and a detailed input schema, the description adequately covers purpose and usage. It may not explain return format or provider selection, but those are either in the schema or exposed via sibling tools. Overall, it provides sufficient context for an agent to select and invoke the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has detailed descriptions (e.g., sections list, max_chars bounds, publication_number normalization). The tool description reinforces the context-saving aspect of section selection but does not add much beyond the schema. Baseline 3 is appropriate.
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 '公開番号を指定して特許の中身を取得する' (get patent contents by publication number), which is a specific verb+resource combination. It further lists distinct use cases like checking claims, reading specification, and understanding citations/family, which differentiates it from sibling tools like search_patents and find_similar_patents.
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 specifies when to use the tool ('請求項の文言確認、明細書の読み込み、引用関係やファミリーの把握に使う') and advises to select only needed sections to avoid wasting context. It lacks explicit exclusions or direct comparisons to alternatives, but the provided use cases give clear situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_patent_providersA
利用できる特許データソースと、それぞれが対応している機能を返す。
ツールが「未対応」と答えたときや、別のデータソースに切り替えたいときに使う。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explains the tool's purpose and usage context but does not disclose additional behavioral traits such as whether it is read-only, if authentication is needed, or any limitations. The description is not misleading but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function and followed by practical usage scenarios. Every sentence earns its place with no wasted words.
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 is a simple listing operation with no parameters and an output schema exists, the description sufficiently covers what it does and when to use it. It is complete for this level of complexity.
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?
The tool has zero parameters and the schema coverage is 100% trivially, so the baseline is 4. The description adds no param details, which is acceptable since no parameters exist.
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 returns available patent data sources and the functions each supports, using the specific verb '返す' (returns). This distinguishes it from siblings like get_patent and search_patents, which are about retrieving or searching patents.
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 explicitly tells when to use: 'when the tool answers unsupported or when you want to switch to a different data source.' It lacks an explicit when-not statement, but the context is clear and distinguishes from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_patentsA
特許をキーワードで検索し、書誌情報と該当箇所の抜粋を返す。
技術テーマや出願人から先行技術の当たりをつけるのに使う。
個々の請求項や明細書が必要になったら get_patent を呼ぶこと。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ページ番号（0始まり） | |
| after | No | この日付以降（YYYY-MM-DD） | |
| limit | No | 取得件数 | |
| query | Yes | 検索キーワード。日本語可。AND/OR や "完全一致" が使える。 | |
| before | No | この日付以前（YYYY-MM-DD） | |
| status | No | 登録済みのみ / 出願中のみ | |
| country | No | 国コードで絞り込む（例: ["JP"], ["JP","US"]） | |
| assignee | No | 出願人名で絞り込む | |
| inventor | No | 発明者名で絞り込む | |
| provider | No | 使用するデータソース。省略時は既定プロバイダ。 | |
| date_field | No | after/before の基準日 | priority |
| output_format | No | markdown（既定）または json | markdown |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the full burden. It accurately discloses the main behavior: searching and returning bibliographic info and excerpts. It does not mention potential side effects like rate limits or default provider behavior, but the core behavior is clear and not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs. The first sentence states the function; the subsequent sentences give usage guidance. Every sentence earns its place, and the layout is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich set of 12 parameters (all documented in the schema) and the presence of an output schema, the description is sufficient. It explains the core purpose and directs to the appropriate sibling for full-text needs, though it could briefly mention filtering capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds a usage context note but does not add parameter-specific semantics beyond what the schema already provides for each parameter.
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 patents by keyword and returns bibliographic information and excerpts. It distinguishes from siblings by specifying this is keyword-based search, and explicitly mentions get_patent for full claims/specifications.
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 usage context (finding prior art lead based on technical themes or applicants) and an explicit alternative (get_patent when full claims/specifications are needed). It does not mention find_similar_patents as an alternative, which slightly reduces completeness.
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.
4 tool updates
v0.1.0- First observed
find_similar_patents - First observed
get_patent - First observed
list_patent_providers - First observed
search_patents
TDQS
A4.2/5.0
Scored across 4 tools
Disambiguation5/5
Each tool has a distinct purpose: provider metadata, direct retrieval by number, keyword search, and similarity search. Any potential overlap between search_patents and find_similar_patents is clearly resolved through descriptions of input types and use cases.
Naming Consistency5/5
All tool names follow the consistent verb_noun pattern (list_, get_, search_, find_) with snake_case. The pattern is predictable and makes the tool set easy to navigate.
Tool Count5/5
Four tools is an ideal size for this domain. Each tool is necessary and covers a core aspect of patent search and retrieval without redundancy or bloat.
Completeness4/5
The set covers the full workflow of patent discovery and examination: find providers, search, retrieve specific patents, and find similar ones. Minor gaps like legal status or batch export exist but are not critical for typical patent research tasks.
Maintenance
ActivityMaintained
ResponsivenessSyncing
Related MCP Connectors
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
An MCP memory server. One memory your agents share — across models, devices and apps.
Related MCP Servers
- AlicenseAqualityCmaintenanceMCP server for patent search and prior art discovery powered by Google Patents public dataset on BigQuery. Supports searching patents, fetching full patent details with CPC codes and citations, and retrieving legal claims text.35MIT
- AlicenseNot gradedqualityAmaintenanceAn MCP server that enables patent creation and analysis, including regulation search, prior art discovery, claim compliance checks, and patent diagram generation, all within Claude Code.183MIT
- AlicenseNot gradedqualityAmaintenanceAn MCP server that gives AI agents access to global patent data, including 1.4 billion records and Chinese full-text, with zero-config mode for basic tools.1MIT