How to Draft MCP Usage Terms in AI Product Contracts (PDF Checklist)

Seats versus agents. Recognize that a base seat user license may not translate well to MCPs and agents. Agents work 24/7, they do not get sick, and they do not take holidays. Ask whether there are two pricing models, one that distinguishes human activity from an agent you create that interacts with the same technology, and find out whether the two are treated the same or differently.

Agent instances. Be precise about the connection rights for named Users. Write “unlimited” if that is what the parties mean. If you use a phrase like “agent instances,” define it because in plain English the phrase does not mean anything. Recognize that you may not be able to control the agents if they have sub-agents and if the sub-agents can create their own sub-sub-agents.

Managing agents. Sort out what happens with a prebuilt agent. If you purchase a prebuilt agent from a vendor, does it become your responsibility to manage that agent, or will the vendor charge you some amount of money to work on the agent it wrote for you?

The billing unit. Make the vendor identify the unit for which you’ll be charged. For example, avoid something priced by “units” without details. Figure out how the units relate to actual pricing. For example, if the vendor says it will charge by units, you’d need to drill down. In a real-world example, a vendor kept giving generalized answers about what a unit meant. After several rounds, it finally admitted the units were tokens and that inbound tokens cost more than outbound tokens, with the vendor unable to say by how much. Recognize the tension underneath that. Vendors want the unit to be activity, meaning an API call or token use, while customers want it to be a completed task, meaning proper execution.

Retries and concurrency. Understand what actually drives the volume you get billed for. Look at the nature of the task. When an agent unsuccessfully performs a task the first time, it goes back and reads the entire chat history and does it again, and that adds to costs. Think about peak concurrency as well, meaning the agents doing the most activity and also using multiple and sometimes dozens of tools if not more. Then negotiate a free month so you can understand how many units you consume and create a baseline for future usage. One team did this and learned that some activities slurp up more units than others.

Verifying usage records. Do not just take the vendor’s word for it that you consumed this much. Get some kind of audit right. Vendors may resist the term audit, so ask for a right to review the usage data. A vendor may try to be opaque about your consumption, and any vendor should really be able to be transparent about it. Vendors build a good process for auditing and determining what the customer actually owes through good, clean, clear logs. That, in conjunction with good definitions and a real breakdown of what drives costs, gives a good foundation for a usage model.

The adjustment right. Avoid giving the vendor the right to adjust the Included Volume and the overage rate on thirty days’ notice. What can happen in the real world is that you become dependent on the product and cannot just cancel if it gets too expensive. Ask for a provision to require the vendor to meet and confer instead. Here’s one approach: if the customer repeatedly exceeds the included usage, the parties will meet and confer in good faith to provide for pricing. You can always do that anyway, but words like that still help in contracts for new technology.

Ceilings and warnings. Cap what an adjustment can do to you. Put a ceiling on your cost each month, and maybe renegotiate with the vendor if you have a really bad month. Even better, trigger a warning before it sends you up into the next pricing tier. Treat canceling contracts as a last resort for cost containment, because users get really attached to their AI and your employees are not going to be happy if you start taking stuff away.

Vendor true-ups. Vendors may want to add a realistic true-up period and mechanism on a timeframe that really makes sense for their business, knowing this is unpredictable. They look at factors like trailing average of usage and interdependence of tasks.

Who watches the meter. Pay a lot of attention to whose responsibility it is to monitor and control usage. An agent may start looping and chew up tokens. If you are paying for tokens, understand whose responsibility it is to control that token usage. Ask whether the vendor gives you a way to monitor consumption. A lot of them have a little meter that shows how many tokens you are using. Make sure your users understand what that means from the standpoint of your pre-purchased capacity or your cost tolerance.

Two undefined standards. Be careful using “commercially reasonable” obligation on the user to avoid excessive use. There’s no accepted legal standard for what commercially reasonable efforts to configure an agent are, or what would be considered excessive use. Keep in mind too that the excessive use might not be anything within the user’s or the customer’s control. Evaluate if it makes sense to include “excessive use” as a defined term, separate from “Included Volume.”

Whose infrastructure failed. Work out what happens if an agent is unable to perform the task, and share the responsibility. The failure may result from customer-brought infrastructure, such as a bring-your-own API key or some other endpoint the customer provides. Or the problem could arise from problems with the vendor-provided gateway access.

Defining the error. Ask what an “error” in the AI service is. What is user error? What if the AI service easily goes off on tangents because of how the vendor set it up? This sentence is an argument waiting to happen. Depending on how “AI Service” is defined, this sentence may not really help the customer if it does not include MCP access and is instead something more limited, such as access to the LLM or the platform that is the vendor’s primary product.