What Your IPMS Vendor Will Not Tell You About MCP

Every major IPMS platform now mentions MCP. The Model Context Protocol appears in keynotes, in sales conversations and in roadmap presentations across the enterprise IP management category. The announcements are similar in structure. The vendor confirms support for the standard, describes the integrations it enables, and presents the commitment as evidence of openness.

What the announcements omit is the economic consequence. MCP, if fully adopted, undermines the bundling logic on which these businesses were built.

The mechanism itself is not contested. Bundling was priced on the cost of integration, and a standardized protocol removes a large part of that cost, so the premium on bundling declines and the switching cost that has protected the incumbent declines with it. That argument is well established and does not need restating. What follows from it does: how a buyer establishes, inside one vendor relationship, whether a particular announcement carries that consequence or none of it.

This does not make vendor statements dishonest. It makes them incomplete in a predictable direction. A vendor that adopts MCP fully accelerates the erosion of its own pricing power. A vendor that adopts MCP partially can claim the position without absorbing the consequence. The buyer therefore needs a method for converting an announcement into a verifiable fact.

The three checks below are that method. Each can be run by a head of IP, an IP operations lead or a firm CTO inside an ordinary renewal cycle, and each produces an answer that can be recorded and compared across vendors.

The Announcement and the Release Are Different Objects

Adoption at the category level is real. The protocol is an open standard and governance now sits with the Linux Foundation. Questel has confirmed adoption. The first MCP-native patent search engine, FluidityIQ, is already in market. The direction of travel is established.

Movement at the category level tells you nothing about the release running in your environment. The distance that matters is the distance between two architectural states that are easily confused. The first is an API-connected hybrid: an IPMS hub with API integrations to specialized platforms, flexible in appearance but dependent on the vendor's API roadmap, and exposed to integrations that an acquisition can break overnight. The second is an MCP-aware modular arrangement: specific workflows deliberately decoupled from the IPMS, with MCP-native components handling discrete functions through direct model-to-component communication.

A roadmap presentation can describe the second state while the deployed product operates in the first. The three checks exist to establish which one you are buying.

Check One: Which Features Are MCP-Connected in the Current Production Release

The question is narrow and the qualifier carries the weight. Not the roadmap. Not the beta. The current production release, in the environment your team uses. If the answer requires a slide deck, the capability does not exist yet.

Five requests make the answer verifiable.

First, the release number of the version currently deployed for your organization, and the date it shipped. Second, the published list of capabilities that release exposes through MCP, with the technical documentation that describes them. Third, a statement of which of those capabilities are read operations and which can write back into the system of record, since a read-only surface constrains what can be automated. Fourth, a sandbox connection running against your own portfolios, prosecution histories and claim language, because demo accuracy and production accuracy are different quantities, and a vendor unable to demonstrate capability on your own data is not ready for production. Fifth, for anything described as forthcoming, a named target release and a date.

Record the answers against a workflow map rather than against the vendor's feature list. Identify each workflow your department operates, decompose it into steps at a granularity where each step is served by a distinct platform, manual process or workaround, and mark which steps the vendor's current MCP surface actually reaches. A prosecution workflow decomposes into invention disclosure intake, prior art search, patentability assessment, claims and specification drafting, filing, office action routing and response, and grant and maintenance. A vendor can support MCP in a technically accurate sense while reaching none of the steps where you need it.

Check Two: Which Parts of the Platform Are Open and Which Remain Proprietary

A vendor that opens prosecution data through MCP but keeps analytics closed is making a strategic choice worth understanding. The exposed surface maps where the vendor believes its defensible margin sits: commodity layers are opened, and the layer that carries the stickiness stays closed.

Build the map module by module. For each component of the platform, record three attributes: exposed or withheld, read or write, metered or unmetered. The instructive case is the module you would most want to replace first, since that is the one the vendor has the strongest reason to keep closed.

The consequence is architectural. MCP introduces a third option alongside building internally and buying a vendor solution: orchestrating multiple platforms, agents and data sources into composite workflows. Orchestration requires that every component in the chain be reachable, so a closed module converts an orchestration decision back into a buy decision, and the vendor keeps the position through architecture rather than merit.

Metering deserves the same scrutiny as access. Pricing in this category is expected to shift from annual licensing toward usage-based models across the second half of 2026, and a module priced so that routine querying becomes uneconomic is open in a narrow sense only. Ask for per-call pricing at the volume your actual workflow generates, and calculate cost per unit of output rather than headline price.

There is a second reason this map matters. Functional overlap across typical multi-vendor stacks runs at 40 to 60 percent, and most organizations cannot see it because no one has the architectural visibility to measure it. An open surface makes overlap measurable. A closed one keeps it invisible, and invisible overlap is renewed every year without examination.

Check Three: What Data Export Looks Like Contractually

MCP enables real-time queries. It does not guarantee bulk data portability. These are different capabilities and they are governed by different documents. A query interface returns what you ask for, at the granularity the vendor chooses, for as long as you remain a customer. Portability is the ability to remove the complete record set and operate elsewhere. The contractual terms around export reveal more about a vendor's actual commitment to interoperability than any protocol announcement.

Six items belong in the review.

Scope: which objects the export includes. Records, document attachments, custom fields, complete prosecution histories, audit trails, configuration and workflow rules. An export that returns records without the documents attached to them is not portability.

Format and schema: whether the output is machine readable and accompanied by documented schema that your team can map without the vendor's assistance.

Frequency and cost: whether bulk export is available on demand, how often it can be requested, and what is charged for it.

Termination: the window after termination during which export remains available, and the service level attached to it. The failure mode to guard against is an export delivered as a professional services engagement priced at the point of exit, when the buyer's leverage is at its lowest.

Continuity: whether the export right survives an acquisition of the vendor.

Verification: the right to run a test export during the contract term, so that the first attempt does not occur under time pressure.

The economics justify the effort. Switching cost for a monolithic IPMS runs at three to five times the annual license fee. A firm paying $300,000 a year faces an effective switching cost of $900,000 to $1,500,000 once configuration, training, data migration and workflow rebuild are counted. Export terms are the largest single lever on that figure. Negotiating them at renewal costs nothing. Negotiating them at exit is not a negotiation.

This is also the check a vendor is least prepared to answer in a product conversation, because the terms sit with legal and commercial teams rather than with product management. Route the question accordingly, and put it in writing.

Reading the Three Answers Together

The answers sit on a scale of architectural maturity that is worth stating in full, because it establishes where a department is and where a given vendor can take it. The first stage is a single-vendor IPMS for all workflows. The second is an IPMS with one to three point solutions and no integration architecture, which is where most departments sit. The third and fourth are the API-connected hybrid and the MCP-aware modular arrangement described above. The fifth is a stack of eight to fifteen specialized systems connected through an orchestration layer with no platform dominance, and no IP practice operates there today.

The consequence is that the evaluation method changes once a department reaches the modular stage. Feature comparison stops working, because a system built on a research agent has no features in the traditional sense, only capabilities that emerge from the interaction between the model and the protocol layer. The question shifts from which product has the best features to which architecture enables the best outcomes.

The three checks are that architectural evaluation in minimum form. A vendor that answers all three precisely is a credible backbone for a modular stack. One that answers the first with a roadmap, the second with a marketing position and the third with silence is an API-era dependency described as a modular partner. The distinction is worth establishing now: the competitive window before the gap between early movers and laggards becomes structural runs to roughly 12 to 18 months.

Running the Checks at Renewal

Four steps make this operational.

Map before you ask. The workflow and step inventory comes first, then what serves each step. Without that baseline, a vendor's answers cannot be scored against anything, and the conversation returns to feature comparison by default.

Ask in writing, before the notice period opens. That window is the point of maximum leverage and the only moment at which export terms are genuinely negotiable.

Decide per step rather than per platform. For each workflow step where a finding emerges, the output is a decision to buy, to build or to keep, with the rationale, the estimated cost of the change and the implementation dependencies attached. Whole-platform decisions obscure the steps where the incumbent remains adequate.

Record the answers as a baseline. Documented findings become the reference point for the next cycle. Without a baseline, every subsequent review restarts from zero, which is why renewals default to automatic.

Two constraints will surface during this exercise and both are worth anticipating. Actual technology spend, once mapped at platform level with implementation and support costs included, typically exceeds the estimated figure by 20 to 40 percent. And the evaluation burden is structural: an audit of the landscape completed in April 2026 mapped 1,973 platforms and services across 24 categories, a landscape no internal team can track through conference attendance and vendor conversations alone.

A protocol announcement is a low-cost signal. The three checks convert the signal into evidence: what shipped, what is reachable and what leaves with you. A vendor that intends interoperability can answer all three from what it has already shipped. Recorded and compared across renewal cycles, those answers are a more reliable guide to a vendor's architecture than any roadmap presentation will be.

One practical observation on the second and third checks. Both are considerably easier to answer where the stack is already instrumented: where the platforms a department runs are connected, the work that passes between them is orchestrated with explicit human checkpoints, and each step carries a record of its time, its cost, its quality and how long a handoff waited. That is the layer Cblindspot builds, and its live connectors include Questel Orbit and FluidityIQ. The point is not the software. It is that a department which measures its own workflow answers the three checks from its own evidence rather than from the vendor's.