Connecting AI to USPTO patent data is now free and read-only. Here's what MCP does, what it doesn't, and the questions to ask before you buy.
A guide for IP operations teams: what MCP does with patent data, what it doesn't, and the questions worth asking before you connect AI to your docket. Current as of July 2026.
Something shifted in the last few months, and the sales calls have caught up to it. Your team can now point an AI tool at United States patent data and get real answers back. Pull the current claim set on a matter. Check status across a portfolio. Summarize a file history. It works. And for public patent data, it's essentially free.
That's worth saying plainly, because a lot of vendor pitches are built on hoping you don't know it. The connection everyone is selling as a breakthrough runs on an open standard, and for public USPTO data it's already a commodity. So the real question for an IP operations team isn't whether you can connect AI to patent data. You can. The question is what happens after the AI hands you an answer, and that's the part the connection leaves to you.
This guide covers what the technology actually is, what it does and doesn't do for a practice, and the short list of questions worth asking anyone who sells it to you.
What is an MCP server, and what does it do for patent data?
MCP stands for Model Context Protocol. Strip the jargon and it's a standard way for an AI tool to reach into an outside source of information and pull what it needs. An MCP server is the connector that sits in front of that source, takes the AI's request, and hands back the data.
For patent work, the source is patent data. A patent MCP server lets a tool like Claude, Copilot, or ChatGPT ask for a status, a claim set, a file wrapper, or a prosecution history and get it back in seconds, without a person copying anything between windows. The AI reads. That's the job, and it does it well.
What it does not do is act. It reads the record. It doesn't route what it found, attach it to the matter, or docket the deadline the record implies. Hold onto that difference, because it's the whole story.
Does the USPTO have an MCP server?
No. The USPTO publishes data, not a connector. Its Open Data Portal is the current hub for patent and trademark data, and it's an API, a feed you pull from, not an AI tool you talk to. (If you built anything against the older feeds, the USPTO's own notices say PatentsView migrated to the Open Data Portal, with its functions pausing starting March 20, 2026, and the Enriched Citation API was decommissioned on January 30, 2026. The Office Action APIs moved to the Open Data Portal too. So the data didn't disappear. It just moved.)
The MCP servers that connect AI to USPTO data are built by other people on top of that public feed. Several are open source and free, and anyone can stand one up. That's the part to internalize. Connecting an AI to public patent data is not a product anyone owns. It's a commodity, it's read-only, and the moment a vendor frames it as their special capability, you're being sold the free part.
Can AI update my docket or file for me?
Not through any of this. Reading data and changing your systems are two different things, and the version being sold to IP teams is the reading half.
Filing with the USPTO is a separate, authenticated path through Patent Center, with its own signatures and rules. It isn't a data feed and it isn't something a patent MCP server does. Updating your docket, your document system, or your client record is a change to your systems, not the patent office's, and an AI reading a status can't push that status into your docket. Someone, or something, still has to carry it the last few feet.
That last few feet is where the day actually gets spent. The answer isn't the work. The work is what the answer sets in motion: the deadline that has to land on the right person's docket, the reference that has to make it into the filing, the update the client is waiting to hear. An AI that reads faster doesn't touch any of that. It produces more answers that still have to be carried by hand.
What about connecting AI to my own matter data?
This is the version that sounds more impressive, and it's the one to look at hardest. Some vendors offer AI access not just to public data but to your firm's own matter data: your dockets, your deadlines, your file histories. Ask a plain question, get an answer grounded in your actual portfolio.
Here's the catch, and it's a big one. For an AI to answer from your matter data, that data has to sit somewhere it can reach. The vendors pitching this hardest are the ones that already hold it, because they run your docketing or your renewals as an outsourced service. For them, AI access to your matters isn't a feat of integration. It's a byproduct of you having handed them your docket.
So ask two things. If the impressive version depends on your data living in the vendor's cloud, you're weighing an outsourcing decision, not a feature, and where your data lives and who controls it is the whole question. And if you keep your docketing in-house, ask whether the tool can even reach your data without you moving it, and whether it only reads or can actually act. So far, the private-data demos on the market run on data the vendor already holds. Connecting AI to the matters you keep in your own systems is a different problem, and it's the one that decides whether the work ever moves.
What should I ask a vendor before connecting AI to my docket?
When someone pitches you on AI plus patent data, the demo always looks good, because reading is the easy part and it demos beautifully. These questions cut past the demo to the part that decides whether it helps your operation.
One. Is this public data, my data, or both, and where does my data have to live for it to work? If the impressive version depends on your matters sitting in the vendor's cloud, you're weighing an outsourcing decision, not a feature.
Two. Is any of this more than read-only? Reading is the baseline and mostly free. Ask what, if anything, the tool actually writes, changes, or triggers. Most of the time the honest answer is nothing, and that's fine, as long as nobody priced it like magic.
Three, and this is the one that matters. After the AI produces an answer, who moves it? Who routes the draft to the attorney, attaches it to the matter, pushes the new date to the docket, bills the time, and tells the client? If the answer is "my team, by hand, same as today," then the AI didn't shrink the work. It got to the same bottleneck faster.
That third question is the whole ballgame. Reading patent data is solved and cheap. Moving the work it kicks off back through the systems and people who run the practice is the part no data connection touches. It's also the part that decides whether a busy week goes smoothly or falls through a gap nobody could see.
Where this leaves an IP operations team
Connect your AI to patent data. Genuinely, do it. It's useful and it's cheap, and there's no reason to pay a premium for the public, read-only part.
Then be clear-eyed about what's left. The answer an AI hands your paralegal on a Tuesday afternoon still has to become a docketed deadline, a filed paper, a billed hour, and a client who's been told. That's not a reading problem. It's an operations problem, and it lives in the space between the tools you already run.
That space is what PracticeLink was built to hold. It connects the systems you already trust, your docketing, your documents, your client reporting, and your AI tools, so that when the AI produces an answer, the work it sets in motion actually moves, to the right person, on the right matter, without anyone rekeying it. You don't hand us your docket. You keep your systems and your control. We make them work together.
The AI can read the patent office. Deciding what happens next is still your practice's job. The firms that handle the next few years well won't be the ones with the most AI. They'll be the ones whose operation carries the work the moment the answer lands.
Frequently asked questions
Does the USPTO have an official MCP server?
No. The USPTO publishes patent and trademark data through APIs, and its Open Data Portal is the current hub. It does not offer its own MCP server. The MCP servers that connect AI tools to USPTO data are built by third parties on top of the public data feed, and several are open source and free.
Can an AI tool update my docket or file a paper through MCP?
No. MCP connections for patent data are read-only. They let an AI retrieve data, not change your systems or file with the USPTO. Filing is a separate authenticated process through Patent Center. Updating your docket, document system, or client record is a change to your systems that a data connection does not perform, so a person or a workflow still has to carry it.
Is connecting AI to USPTO patent data hard or proprietary?
No. Connecting an AI to public USPTO data is a commodity. Open-source MCP servers already do it against the Open Data Portal at no cost. If a vendor presents access to public patent data as a proprietary capability, they are charging for something that is freely available.
Does AI access to my own matter data work if I keep docketing in-house?
It depends on the vendor. The products offering AI access to your own matter data today run on data a vendor already holds through outsourced docketing or renewals, so they do little for a firm that keeps docketing in-house. Connecting AI to matter data you keep in your own systems is a different problem, and it usually needs a tool that integrates with those systems rather than one that hosts your data. Either way, these connections are read-only.
What is the most important question to ask an AI-plus-patent-data vendor?
Ask what happens after the AI produces an answer: who routes it to the attorney, attaches it to the matter, pushes the deadline to the docket, bills the time, and updates the client. Reading patent data is largely free and read-only. Moving that work through your systems and people is the part that determines whether the tool reduces your workload or just reaches the same bottleneck faster.