Help us improve
Share bugs, ideas, or general feedback.
From patent-search-mcp
Guides structured prior art searches using Espacenet: CQL query construction, abstract triage, full-text keyword search, paginated claim reading, family expansion, report generation. For patent novelty and invalidation.
npx claudepluginhub navisbio/ops-patent-search-mcp --plugin patent-search-mcpHow this skill is triggered — by the user, by Claude, or both
Slash command
/patent-search-mcp:prior-art-searchThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are conducting a prior art search using the Espacenet patent tools.
Searches patents, academic papers, products, and open source for prior art to assess novelty/obviousness, challenge validity, support FTO, or document defensive publications.
Conducts 7-step prior art searches and patentability assessments using BigQuery keyword/CPC queries, USPTO API, and timeline analysis for invention evaluation.
Accesses USPTO patent data via PatentsView REST API and Google Patents BigQuery. Searches by inventor, assignee, CPC, keywords; analyzes portfolios and trends for IP landscape, prior art search, competitor monitoring.
Share bugs, ideas, or general feedback.
You are conducting a prior art search using the Espacenet patent tools. Follow this structured workflow to find the most relevant prior art efficiently without flooding context with full patent texts.
Invention description
--> Extract key concepts + classifications
--> Build CQL queries (broad + narrow)
--> Count results (size the landscape)
--> Triage by title/abstract (compact view)
--> Keyword search in top candidates' full text
--> Paginated deep-read of relevant sections
--> Family expansion for key hits
--> Structured prior art report
Before searching, break the user's invention description into:
For example, an invention described as "a bispecific antibody targeting PD-1 and LAG-3 for cancer treatment" decomposes to:
Construct 2-4 CQL queries of decreasing specificity:
Load the CQL syntax reference for detailed field codes, operators, and examples: CQL Syntax Reference
ta= (title + abstract) for concept searches — broader than ti= aloneclaims= or ftxt= for phrase-level filtering — these CQL full-text fields are unreliable for phrases and don't support wildcards. Use ta= for CQL filtering, then search_in_patent_text for full-text keyword search in specific patents.* for right truncation only (antibod* matches antibody, antibodies) — only works on ta=, ti=, ab=, pa=, in= fields, NOT on full-text or classification fieldsta="bispecific antibody")AND, OR, NOT — MUST be uppercasepa="ROCHE*" catches Roche, Roche Holding, etc.)published_after/published_before parameters, not CQL pd=For each query, start with count_only=true:
search_patents(query="ta=\"bispecific antibody\" AND ta=\"PD-1\" AND ta=\"LAG-3\"", count_only=true)
This costs only 1 API call and tells you:
detail_level="compact" to triagedetail_level="summary" first for landscape stats, then narrowRetrieve results with appropriate detail level:
detail_level="full" — read all titles and abstracts inlinedetail_level="compact" with auto_paginate=true — scan titles to pick candidates, then get_patent_details for promising onesdetail_level="summary" with auto_paginate=true — review landscape stats (top applicants, year distribution, classifications), then narrow queryFrom the results, identify 5-15 top candidates based on title/abstract relevance.
For each top candidate, use search_in_patent_text before reading full text:
search_in_patent_text(
document_number="EP3750919",
search_terms=["bispecific", "PD-1", "LAG-3", "binding domain"]
)
This returns:
sectionOffset (the offset to use with the reading tools)Skip full-text reading for patents with 0 matches on your key terms — they're unlikely to be relevant prior art even if the abstract seemed promising.
Check all document types: Don't search only WO publications. Include EP granted patents (B1/B2 kind codes) and US patents — EP granted claims are narrower but legally definitive, and US patents/applications often contain the most detailed experimental data.
For patents with keyword matches, read the specific sections:
sectionOffset from keyword search matches where section="description" as offsetget_patent_claims(document_number="EP3750919", max_characters=15000)
get_patent_description(document_number="EP3750919", offset=42, max_characters=10000)
Extract actual data, don't just identify existence. When search_in_patent_text finds relevant matches, always follow up with get_patent_description at the matched sectionOffset to read the actual passage. Report specific numbers, endpoints, and technical details — not just "this patent discusses [topic]".
Follow cross-references. Patents frequently cite other documents inline (e.g., "as described in US2017/0137537" or "see US Patent Application No. 15/470,647"). When a passage references another document as the primary source of data, fetch that document too — the cross-referenced document often contains the detailed data.
Focus on:
For the most relevant hits, check family coverage:
get_patent_family(document_number="EP3750919")
This reveals:
Priority date matters: A patent published in 2023 may have a priority date in 2020 — that earlier date is what counts for prior art purposes.
Present findings as a structured prior art report:
Search Strategy Summary
Most Relevant Prior Art (ranked by relevance) For each patent:
Landscape Context
Gaps and Recommendations
get_patent_details to verify its title, applicant, and dates. Never rely solely on search result snippets for report-level citations. For batch efficiency, use the document_numbers array parameter to verify up to 100 patents in one call.search_patents with ct="EP1000000" — this is a powerful way to find related newer art.ta= searches (e.g., ta="hepatitis D" returns 0 results; use ta="hepatitis delta" or ta="HDV" instead).