MCP Development Contract Terms: Ownership, Security and Support

An MCP development contract should answer five questions: who owns the code, how the server must be secured, what data the developer can see, what support you get after launch and who pays to keep up with spec changes. Most disputes on software projects come back to one of these being left vague.

This is a practical checklist, not legal advice. Contract law differs by state and country. Use this guide to prepare for a conversation with your lawyer and your vendor, and have a qualified attorney review the final agreement.

MCP (Model Context Protocol) adds a few twists to a normal software contract. The server gives AI apps the power to act on your systems. The spec also changes on a published schedule. Both should show up in your terms.

1. Ownership of code and work product

In the US, hiring a contractor does not automatically mean you own what they write. The US Copyright Office's circular on works made for hire explains that a work is "made for hire" in two cases: an employee's work within the scope of their job, or certain commissioned works in nine listed categories under a signed written agreement. Custom software built by an outside firm often does not fit those categories neatly.

That is why many software contracts include a separate assignment of rights, not just a "work made for hire" line. Ask your lawyer how to word it where you are.

Terms to discuss:

• What is assigned. Source code, tool definitions, schemas, tests, documentation, deployment scripts and configuration.
• When it transfers. Usually on payment of each milestone or the final invoice.
• Vendor's pre-existing tools. Many agencies reuse their own libraries. You should get a permanent, royalty-free license to use anything they don't assign to you.
• Repository control. The code should live in your GitHub or GitLab account from day one, not theirs.
• No reuse of your business logic. The vendor may keep general know-how, but not your data, schemas or tool designs for another client.

2. Open-source licenses

Almost every MCP server is built on open-source code. Your contract should require the vendor to list each open-source component and its license.

This matters even for official parts of MCP. For example, the official Python SDK is published under the MIT License. The TypeScript SDK's license file says the MCP project is moving from MIT to Apache License 2.0 for new contributions. Both are permissive licenses, but they have different notice requirements.

Terms to discuss:

• A list of dependencies and licenses delivered with the code.
• No "copyleft" licenses (licenses that can require you to share your own source code) without your written approval.
• Third-party MCP servers or paid services the solution depends on, with their costs and terms.

3. Security requirements

"Industry-standard security" is too vague to enforce. Tie security to specific documents and specific checks.

The MCP authorization spec (version 2026-07-28 as of October 2026) applies to HTTP-based servers. It is based on OAuth 2.1. It says servers MUST validate that tokens were issued for them and MUST NOT accept or pass through other tokens. Local stdio servers should get credentials from the environment instead.

The spec's security best practices list attacks to defend against, including confused deputy problems, token passthrough, SSRF and over-broad scopes.

Terms to discuss:

• Compliance with named documents. The MCP authorization spec and security best practices for the agreed version.
• Least privilege. Each tool gets only the permissions it needs. Write actions are listed and approved in the statement of work.
• Human approval for sensitive write or delete actions, if you require it.
• Input validation and output limits on every tool.
• Secrets handling. No secrets in code. Keys stored in your secrets manager.
• Logging. Tool calls logged with user, action, time and result, with sensitive values masked.
• Security testing before launch, with results shared with you.
• Vulnerability notice. The vendor tells you within an agreed time if they find a flaw in code they delivered.

For background on these risks, read MCP security risks and MCP authentication and OAuth 2.1.

4. Data handling and confidentiality

The developer may need access to real systems to build and test. Keep that access as small and short as possible.

Terms to discuss:

• Test data first. Use sandbox accounts or masked data wherever possible.
• Access list. Name who on the vendor's team may access which systems.
• Your credentials, your accounts. Hosting, OAuth client registrations and API keys belong to your company.
• No training on your data. The vendor must not use your data or prompts to train AI models, and must tell you which AI tools they use during development.
• Data location, if you have residency rules.
• Breach notice. A set time to tell you about any incident involving your data.
• Return and deletion. At the end, the vendor deletes copies of your data and you rotate any credentials they used.
• Regulated data. If health, payment or children's data is involved, your lawyer may require extra agreements, such as a business associate agreement under HIPAA.

5. Acceptance and testing

Define "done" before work starts. Without it, you pay for a server that "works on their machine."

Terms to discuss:

• A written test script for every tool, including failure cases.
• Tests with the MCP Inspector, the official testing tool, and with each AI client you named.
• An acceptance window, such as ten business days, to test in your staging environment.
• A fix period for defects found during acceptance, at no extra cost.

6. Support and service levels (SLAs)

A build contract usually ends at launch. Your AI clients, your APIs and the protocol keep changing after that. Put support in writing, even if it is small.

We have not listed typical SLA numbers. They vary a lot by vendor and price. Pick targets that match how critical the server is to your business.

7. MCP spec version and updates

This term is specific to MCP and often missing. MCP versions are named by date. The versioning page lists 2026-07-28 as the current version. Clients and servers may support several versions at once.

The project's feature lifecycle policy says deprecated features stay in the spec for at least twelve months before removal. That can drop to ninety days when there is an active security risk. So plan and budget for updates after launch.

Terms to discuss:

• Target version at delivery, written into the statement of work.
• Who watches for changes. The vendor tells you when a feature you rely on is deprecated.
• Who pays. Updates covered by the support fee, or quoted separately.
• Security-driven changes. Faster response when a deprecation or advisory is security-related.
• Client compatibility. What happens when Claude, ChatGPT or another client changes how it connects.

See what changed in the July 2026 spec for an example of how much one release can change.

8. Other common terms

• Payment schedule tied to milestones you can test.
• Change requests. A written process and pricing for new scope.
• Liability and indemnity. Your lawyer will want to discuss caps and who covers third-party claims.
• Insurance. Some companies require cyber liability insurance from vendors who touch customer data.
• Non-solicitation. Whether either side may hire the other's staff.
• Termination. What you receive if the project ends early, including all code written so far.

Next step

If you are preparing to hire, start with a clear scope using our MCP RFP template. When you're ready to talk about a build, see our MCP development page.

Frequently asked questions