@pipeworx/patents

Connect: https://pipeworx.io/mcp — every tool in the catalog, including @pipeworx/patents’s. Install: one-click buttons

No MCP client? Skip the connection: POST https://gateway.pipeworx.io/v1/tools/search_packs {"query":"..."} to find a tool below, GET /v1/tools/<name> for its schema, POST the same URL with arguments for the data — see For AI agents.

Tools: 7

The US Patent and Trademark Office’s patent database via the USPTO Open Data Portal (ODP, data.uspto.gov) — Pipeworx migrated off the legacy PatentsView API (api.patentsview.org, sunset 2025-05-01) on 2026-05-12. Search and retrieve granted US patents and published applications by keyword, assignee, inventor, or patent number. Free, no auth (platform key configured server-side; bring your own via _apiKey if you need your own quota — get one at https://data.uspto.gov/myodp).

Why this matters for AI agents

Patents are the public record of what’s been invented and who claims to have invented it. For competitive intelligence, IP due diligence, freedom-to-operate research, or technology landscaping, the USPTO is the source. What this pack actually returns: title, inventors/applicants, classification, filing/grant status and dates, the granted patent number once issued, full prosecution/transaction history, parent/child continuity (priority chains), and recorded assignment/conveyance history — both for one application you already have (get_patent_assignments) and by searching assignee/assignor/patent/application number (search_patent_assignments). It does not return claims text or citation data; there is no get_claims or citation tool in this pack (the epo-ops pack’s get_claims does return claims text, but only for EPO-published records).

Three core flows:

1. Keyword search. “What patents exist for CRISPR gene editing?” → search_patents({query: "CRISPR gene editing"}) → matching applications/patents with title, application number, filing date, applicants, inventors, status, classification.

2. Specific patent. “What’s the status of application 16/123,456?” → get_patent({number: "16123456"}) → title, inventors, classification, status, and — once granted — patent_number/grant_date/publication_number/publication_date. If you already have a GRANTED patent number instead, pass it as patent_number (e.g. get_patent({patent_number: "11646472"})) rather than number — see the collision warning below. For the full prosecution timeline, use get_patent_transactions; for where the application came from (continuations, divisionals, provisionals) and what it later spawned, use get_patent_continuity. For who currently holds it, pair with get_patent_assignments({application_number: "16123456"}) or search by name with search_patent_assignments.

3. Transfer history (not a patent list). “What has Amyris been assigned?” / “Who assigned patent 10,000,000?” → search_patent_assignments({assignee: "Amyris"}) / search_patent_assignments({patent_number: "10000000"}) → recorded assignments with reel/frame, conveyance, dates, assignors/assignees, and the covered application/patent numbers. This is the recorded-transfer register, one row per transfer. To list the patents a company owns or holds (“patents assigned to X”), use search_patents({applicant: "<company name with its corporate suffix>", query: "*"}) instead — a company with no recorded transfer returns zero here even when it holds many patents.

For company-level IP due diligence (combining patents with SEC IP risk disclosures and trademarks), see the Patent Due Diligence recipe.

Citable URI

pipeworx://uspto/patent/{number}

Patent numbers are stable forever. Embed in agent output as the canonical citation.

What “patents” includes

There’s no dedicated type input filter — every result carries a type field (application/patent type) you can filter on client-side to isolate design or plant patents from the utility-patent majority.

Update cadence

• Grants: measured, Tuesday. Querying granted_after for the current week (2026-09-08) returns grant dates of only 2026-09-01 and 2026-09-08 — both Tuesdays — confirming USPTO’s long-standing weekly grant-day cadence carried over from the PatentsView era. This is current data, not a stale mirror: the most recent grant date returned is today.
• Applications: unverified — do not repeat the old Thursday claim. ODP’s applicationMetaData exposes filingDate and grantDate but no publication date field, so Pipeworx has no way to check when an application record actually becomes visible in ODP. The PatentsView-era “Thursday” figure was for api.patentsview.org’s pgpub publication feed, which this pack does not use and cannot confirm carried over. Treat application-corpus freshness as unmeasured rather than assuming a fixed weekday.
• The default search looks old by construction, not because data is stale. With no granted_after/granted_before, search_patents returns the application corpus sorted newest-filed-first. USPTO doesn’t publish an application until ~18 months after filing and typically takes 2+ years to grant it, so the newest rows in an unfiltered search are recent filings with grant_date: null — that’s expected. Pass granted_after (e.g. "2024-01-01") to get issued patents with real grant dates instead. See the search_patents tool description for the full explanation.
• Pipeworx caches results with a 24-hour TTL. Given the measured Tuesday grant cadence, set Cache-Control: no-cache if you need same-day fresh-grant results.

Common pitfalls

• Keyword search ≠ freedom-to-operate. search_patents finds patents whose text mentions your terms. It does not tell you whether a patent CLAIMS what you’d be doing, and this pack does not return claims text to check that yourself — FTO requires reading claims (the epo-ops pack’s get_claims returns claims text, but only for EPO-published records) and, ultimately, a patent attorney.
• Assignee normalization. “Vertex Pharmaceuticals Inc.”, “VERTEX PHARMACEUTICALS, INC.”, “Vertex Pharmaceuticals” — all the same company. Group case-insensitive after stripping legal suffixes when aggregating.
• No citation data. This pack does not surface citation counts or citation lists at all — there is no way to rank “most-cited” or “foundational” patents within a result set through this pack.
• This pack is US-only, but Pipeworx isn’t. USPTO covers US filings only. For European patents, the epo-ops pack is live today — epo_ops_search_patents, get_biblio, get_family, get_abstract, get_claims against the EPO’s worldwide register (verified live 2026-09-08: epo_ops_search_patents({query:"lithium battery"}) returned current European filings, including publications dated this week). Japanese (JPO) and Chinese (CNIPA) national filings are not in Pipeworx yet — file via pipeworx_feedback if you need them.
• Application vs. issued. “Patent pending” applications are searchable but the date you care about is grant_date, not filing_date. Applications can be rejected or amended; the issued patent is what matters.
• “Filed” wants filed_after/filed_before, not granted_after/granted_before (fleet #2418). A question that says FILED or APPLIED FOR — even when it also says “recent” or “last N years” — wants the filing-date bound; the default application corpus already includes both pending and granted patents, so filed_after alone answers it. Using granted_after for a filing-activity question silently restricts to already-issued patents, and since grant typically lags filing by 2+ years, a recent granted-only window is usually empty even when real filing activity exists — search_patents returns a date_field_hint explaining this on a granted-only zero result.
• Multi-phrase queries get one zero-result broadening retry (fleet #2418). {query: '"experimental phrase one" "experimental phrase two"'} requires BOTH exact phrases to co-occur (ODP ANDs every clause), which can return 0 even when either phrase alone matches plenty. On a genuine zero with 2+ quoted phrases, search_patents automatically retries the same phrases OR’d together and marks the response broadened: true — treat those results as “mentions at least one phrase”, not all of them. An ordinary bare multi-keyword AND (no quoted phrases) is left alone on zero, since that AND is usually doing real, intentional narrowing.
• Known synonym/abbreviation groups are expanded before the search runs (fleet #2450/#2499). {query: 'cfRNA "residual cancer"'} used to return 0 with no broadening at all — the #2418 retry above only sees a query with 2+ QUOTED phrases, and a bare abbreviation next to one quoted phrase never qualified, even though 23 real matches exist for the same two concepts phrased as '"residual cancer" "cell-free RNA"'. A short, curated list of production-observed synonym pairs (cfRNA / cell-free RNA / cell free RNA / circulating RNA / circulating cell-free RNA / ccfRNA; MRD / minimal residual disease / molecular residual disease / residual cancer / residual disease) is now recognized — quoted or bare, case-insensitive — and expanded to an OR group ANDed against the other concept in the query, on the FIRST attempt, marked synonyms_expanded: true in the response. This is deliberately a fixed, documented list, not general synonym invention: an unrelated OR silently answers a different question (a whole-query OR-broaden once returned 21,937 largely off-topic matches).
• An 8-digit application number and an 8-digit granted patent number can be the SAME digit string for two unrelated inventions (fleet #3301 follow-up). Application numbers are a 2-digit series code plus a 6-digit serial (e.g. “11” + “646472” = application 11/646,472, filed ~2006); granted patent numbers entered that same 10,000,000-12,999,999 range in 2018 and are still in it. get_patent({number: "11646472"}) is genuinely ambiguous between a 2006 application and a 2023 patent grant. Pass patent_number instead of number whenever you specifically mean the patent — it is never ambiguous. If you only have number and it falls in the collision range, the tool checks both interpretations and returns ambiguous: true with both records summarized rather than silently guessing; re-call with the right argument once you know which one you meant.
• get_patent surfaces patent_number/grant_date directly now (fleet #3301). It used to only report status plus a guessed “grant event” scanned out of prosecution-history text — and that guess matched ANY event whose description contained the word “Granted”, including routine extension-of-time approvals, so a patented application could come back with status “Patented Case” and a misattributed extension-of-time date instead of the actual patent number. Read patent_number/grant_date/publication_number/publication_date directly; if status is “Patented Case” but patent_number is null, the response carries a patent_number_warning (an upstream data gap) rather than silently reading as “not yet granted”.
• Two different sources answer assignment questions, and they are not interchangeable. get_patent_assignments and get_patent_transactions/get_patent_continuity read the USPTO Open Data Portal’s per-application file-wrapper data (needs the application number you already have). search_patent_assignments reads USPTO’s separate public Assignment Search system and is the only one of the four that can search BY assignee, assignor, or patent number without already knowing the application. An assignee/assignor search on search_patent_assignments resolves each result’s covered patent/application number via one follow-up lookup per row, so it costs more upstream calls than a direct patent/application-number search — keep limit modest for a name search.
• No patent-family data in this pack. Unlike epo-ops’s get_family (INPADOC family, worldwide), this USPTO pack does not return family-member data — get_patent covers a single US application/grant only. For “does this invention have foreign counterparts,” go through epo-ops instead.

Tools

• search_patents — Search USPTO patent applications and grants — without a granted_after/granted_before bound this returns the APPLICATION corpus sorted newest-FILED-first, not issued patents. USPTO publishes an
• get_patent — Fetch a single USPTO patent application/grant by application number (number, e.g. “16/123,456” or “16123456”) or by an already-granted patent number (patent_number, e.g. “11646472”) — pass whichev
• search_inventors — Search USPTO patent applications by inventor last name. Returns matching applications with title, inventor list, and filing date — sorted newest-filed-first, so this is the APPLICATION corpus (same as
• get_patent_assignments — Retrieve USPTO-recorded assignment/conveyance history for one patent application from the migrated Open Data Portal endpoint. Returns assignors, assignees, execution/recording dates, conveyance text,
• get_patent_transactions — Fetch the full USPTO prosecution/transaction history for one patent application — every dated event the Office recorded against the case (filings, mailings, fee payments, office actions, notices, the
• get_patent_continuity — Fetch the parent/child continuity (priority) chain for one patent application — every earlier application this one claims priority from (continuation, divisional, CIP, provisional, etc.) and every lat
• search_patent_assignments — Search USPTO-recorded patent assignment/conveyance history by assignee, assignor, a granted patent number, or an application number — one of the four is required. Unlike get_patent_assignments (whic