10 Things to Know About MCP Commercial and Data Handling Provisions: Practice Points

Understand what you are buying before you agree to the pricing. Hebe told us about a vendor whose pricing ran on units, where a unit equaled a dollar. It took several rounds of questions before the vendor admitted the units were tokens, and the vagueness came from the fact that inbound tokens cost more than outbound ones and nobody knew the ratio yet. They landed on a free month so the team could build a usage baseline before committing. Resist the temptation to sign off just because the business needs the technology.

Define the billing unit with real precision. Matt pointed to the tension sitting inside every usage model, where the vendor wants to bill for activity like an API call or a token and the customer wants to pay for a completed task. That gap is where the arguments live. Sort out what happens when an agent cannot perform, especially where the customer brought its own API key or other infrastructure. Good definitions, a real breakdown of what drove costs, and clean logs gave the billing model a foundation.

Price for agents that never stopped working. Matt described thinking about peak concurrency, agents spawning their own sub-agents, and the nature of the task itself. When an agent failed the first time, it went back and read the entire chat history and tried again, which added cost nobody planned for. Vendors weighed a base seat license, a straight usage model, and hybrids with a base seat plus usage plus overage. Whatever the model, build a true-up period on a timeframe that matches how your business actually gets paid.

Ask for a ceiling on what a bad month can cost. Hebe suggested negotiating a cap on monthly spend with a right to renegotiate after a really bad month. Better still, get a warning that fires BEFORE you cross into the next pricing tier. Agents can lose their minds and loop, and users who do not know what they are doing can burn capacity fast. Give your team the usage meter and make sure they understand what it means for your prepurchased capacity.

Push back on the vendor's right to reprice mid-contract. Vendors want to adjust included volume and overage rates on short notice, and that right gets a lot more dangerous once the business depends on the tool. Hebe preferred language where the parties met and conferred in good faith when the customer repeatedly exceeded the included usage. She also reminded us that users get attached to their AI, so canceling a contract makes for poor cost containment. Your employees will not thank you for taking the tool away.

Get a right to see the usage data behind your invoice. Vendors flinch at the word audit, so call it a review right when that gets it done. Hebe said she was allergic to customer audit rights herself and still let counterparties review anything within reason. Without something like it, you are taking the vendor's word for how much you consumed. Some vendors may try to stay opaque about consumption, and any vendor should be able to be transparent about it.

Don't expect traditional uptime commitments to fit. Hebe told us plainly that Symmetry made no uptime commitments for its own MCP, because it did not yet have enough performance data to apply its normal standards. Matt said vendors would stay on the hook only for what they controlled and would point customers to third-party service level agreements for everything downstream. With real leverage, Hebe would push for return to operation targets measured in hours rather than days. She noted that service level credits were never that appealing even for ordinary SaaS downtime.

Pay attention to how often your users have to reauthenticate. Hebe made the case that in this early phase the reauthentication interval mattered more than a precise uptime number. Daily reauthentication for a tool you use daily buys very little security and creates a real annoyance. Find out whether you can influence the interval in either direction, depending on whether you value security or continuity. It reads as a purely commercial issue, and the contract is the only place you are going to address it.

Know what your query logs collect. Matt walked through what ended up in them, including the agent's history, the entire chat, the tool responses, the full reasoning chain, and potentially personal information, trade secrets, and source code. Ask for specified disposal protocols with permanent and certifiable destruction, and consider whether cryptographic erasure belongs in the terms. Pin down purpose limitation, retention, and who on the vendor side can see the logs. These logs carried a whole different level of importance to the customer than the telemetry logs we were all used to.

Keep log data covered by your confidentiality and data protection terms. The sample provision said log data did not constitute customer data or confidential information, and Hebe pointed out that the same sentence quietly killed the deletion obligation. She wanted a simpler fix where any confidential information or customer data inside the MCP logs got treated under the confidentiality and data protection provisions already in the agreement. Matt disliked routing log data to the vendor's privacy policy instead of the DPA, since privacy policies were written for consumers and ran far less restrictive. Watch for de-identification promises too, because they can be the mechanism that lets a vendor keep everything forever.