Software companies
MCP and your business data: is connecting AI tools the same as licensing?
By SourceX Editorial · Updated
Short answer
Connecting AI tools to business data through the Model Context Protocol (MCP) is not the same as licensing it. MCP gives your own AI tools live, permissioned access to your systems. Licensing delivers a defined, prepared copy of records to an outside developer under a contract that limits use. The test: who uses the records, and whether a copy leaves.
Key takeaways
- MCP is a connection standard; it grants no rights to your records beyond the permissions you configure.
- A data license is a contract over a defined, prepared copy of historical records used by an outside developer.
- The AI vendor's terms, not MCP itself, decide whether content fetched through a connection can be retained or used for training.
- Running MCP internally and licensing an archive can coexist, but both belong in one register of who has received what.
What is the Model Context Protocol?#
The Model Context Protocol is an open standard that lets AI applications connect to tools and data sources through one common interface instead of a custom integration for each pair. An MCP server sits in front of a system such as Jira, GitHub, a help desk or a database, and an MCP client inside an AI application calls the tools and reads the resources that server exposes.
In practice, an engineer asks a coding assistant to summarize open bugs, the assistant calls a Jira MCP server, and the server returns matching issues into the model's working context for that task. Nothing is assembled into a package or handed to a third party as a dataset; records are fetched on demand, task by task.
The protocol describes how the connection works. It does not decide who may see what. Permissions come from the credentials the server uses, the scopes it requests and the access controls already set in the underlying system.
MCP access versus data licensing, side by side#
MCP access and data licensing answer different questions: MCP lets your own AI tools work with live systems, while licensing grants an outside developer limited rights to a fixed copy of past records. The comparison below sets out where they part ways.
The direction of value is the clearest difference. With MCP, the company is the customer of an AI tool. With a license, the company is a supplier, keeps ownership of its records and grants a limited right to use a copy for a stated purpose.
| Question | MCP connection | Data license |
|---|---|---|
| Who uses the records | Your staff and the AI tools they run | An outside AI developer, under contract |
| What moves | Results fetched per request into a model's working context | A defined, prepared copy delivered as a package |
| Scope | Whatever the server's credentials can reach at that moment | A manifest of approved record families, date ranges and fields |
| Privacy handling | Access controls; records usually arrive unredacted | Personal and confidential details removed before delivery |
| Governing documents | Your AI vendor's terms, server configuration and internal policy | A license agreement setting permitted use, term and deletion |
| Purpose | Getting today's work done | Training or evaluating models |
| Commercial flow | You pay for the AI tools | The developer pays the supplier a license fee |
| How it ends | Revoke the token or remove the server | Termination and deletion terms in the contract |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Can an MCP connection hand over rights you did not intend?#
An MCP connection can expose records to more parties than people assume, because results travel from your system to whichever service runs the model. If that model is hosted by a vendor, the vendor's agreement for your plan governs retention, logging and any use for training, regardless of how the request arrived.
That is not a license you negotiated, but it is a set of rights you accepted. Before connecting a help desk, CRM or code host, read the AI vendor's business terms with the same care you would give a data license, and check whether customer contracts or your data processing agreement require you to list that vendor as a sub-processor when customer data passes through.
- Does the agreement for your plan allow the vendor to train on inputs, outputs or logs?
- How long does the vendor keep request content, and can you ask for deletion?
- Which systems can each MCP server reach, and with whose credentials?
- Does the server need write access, or will read-only scopes do?
- Who published the server code, and has someone on your team reviewed it?
- Do customer contracts limit which processors may handle their data?
MCP security questions for business systems#
MCP security for a business comes down to the controls that govern any integration, applied to a client that acts on instructions it reads. The main new risk is that text inside a record, such as a ticket comment or wiki page, can contain instructions an AI agent may follow when it has tools available.
The risks in the table are not unique to MCP, but the protocol makes connections easy to add, so they multiply quickly. Treat each server as an integration with a named owner, a reviewed configuration and a log.
| Risk | What it looks like | Control |
|---|---|---|
| Over-broad access | A server uses an admin token that can read every project | Dedicated service accounts with least-privilege scopes |
| Instructions hidden in records | A ticket tells the agent to export data or change settings | Read-only tools by default and human approval for actions |
| Unvetted servers | A community server installed from an unknown repository | An approved server list and code review before use |
| Credential sprawl | Personal tokens pasted into many local config files | Central secret storage and regular token rotation |
| No record of use | No log of which tool fetched which records | Server-side logging tied to the requesting user |
When licensing makes more sense than connecting#
Licensing makes more sense than connecting when the goal is revenue from historical records, or when an outside developer needs a fixed, documented package to train or test a model. A live connection serves your own work; it does not create something another company can use under clear terms.
The two also draw on different records. MCP works best on current, well-permissioned systems. A license draws on depth: years of resolved tickets, linked engineering issues, code reviews and decisions with outcomes, much of it sitting in archives that no AI tool queries day to day.
Both can run at once. A company can connect its coding assistant to GitHub through MCP while it licenses a de-identified copy of closed engineering history, as long as one register shows what each party has received and on what terms. A register entry needs only a few fields.
- System and record family, such as the help desk tickets or GitHub pull requests.
- Receiving party: an internal AI tool and its vendor, or an outside licensee.
- Access type: live MCP connection or delivered copy.
- Scope: the credentials and scopes used, or the manifest of fields and date ranges.
- Governing terms: the AI vendor's plan terms or the license agreement, with retention and deletion rules.
- Internal owner and the date access started or the package was delivered.
Illustrative: a field service software company does both#
Illustrative: a fictional field service software company sets up MCP servers so engineers' coding assistants can read GitHub and Jira, and so support leads can query the help desk. The CTO limits each server to read-only scopes under a service account and chooses an AI plan whose terms exclude training on customer inputs.
Separately, the CEO asks whether years of closed tickets, issues and pull requests could be licensed. That question takes a different path: a review of customer contracts and employee notices, privacy preparation, a manifest of record families and dates, and the CEO's approval of the final scope.
The company records the MCP connections and the license proposal side by side in one register. When counsel reviews the license, every party that has touched the records is already listed, and the AI vendor's retention terms are attached.
Where SourceX fits next to your AI tools#
SourceX handles licensing transactions, not live connections to your systems, and its own rights in a deidentified dataset are set out in the signed supplier agreement. Its work takes a defined set of historical records through the SourceX five-step transaction of Supply, Rights, Preparation, Approval and Delivery, and nothing is shared during the initial assessment.
Each approved package carries a SourceX Evidence Packet that records provenance, licensing rights, permitted use, the privacy record and release authorization. That is documentation an MCP connection never produces, and it lets a company show later exactly what it licensed and why.
How does the Model Context Protocol work under the hood?#
MCP is a client-server protocol built on JSON-RPC 2.0 messages: a host application, such as an AI assistant or IDE, runs one client per connection, and each client talks to a server that offers context and capabilities. The specification separates what a server offers by who is in control of it, which is the quickest way to judge how much a given connection can do on its own.
For a business system, the control column matters most: prompts and resources put information in front of a person or the application, while tools are the one feature that lets the model act.
| Feature | Offered by | Who controls it | Business-system example |
|---|---|---|---|
| Prompts | Server | The user, who picks a template | A slash command that drafts a weekly Jira status summary |
| Resources | Server | The host application, which decides what context to attach | A help desk article or a file from a shared drive |
| Tools | Server | The model, which decides when to call a function | Searching CRM accounts or creating a support ticket |
| Elicitation | Client | The user, who answers the server's request for more information | A server asking which Salesforce workspace to query |
Which MCP transport and sign-in method fits a business system?#
Use stdio for a server that runs on one person's machine and Streamable HTTP for a shared server that many people or tools reach over the network. The two standard transports differ in where the server runs, and the specification ties sign-in to that choice: authorization is optional, HTTP-based servers that use it should follow the protocol's OAuth 2.1 based authorization spec, and stdio servers should instead take credentials from their environment.
Under that authorization spec, a protected server must check that each access token was issued specifically for it as the intended audience, and reject invalid or expired tokens with an HTTP 401. When you evaluate a vendor's hosted server, ask whether it does this rather than accepting any token it is handed.
| Question | stdio | Streamable HTTP |
|---|---|---|
| Where the server runs | As a subprocess launched by the client on the same machine | As an independent process that serves many clients |
| How messages travel | Newline-delimited JSON-RPC over standard input and output | Each message is an HTTP POST to one MCP endpoint |
| How credentials are supplied | From the environment, such as a token in local configuration | OAuth 2.1 based authorization defined by the MCP spec |
| Typical business fit | A developer's local access to a repository or test database | A team-wide server in front of a CRM, help desk or data warehouse |
Who created MCP, and which version is current?#
Anthropic open-sourced the Model Context Protocol on November 25, 2024, as a standard for connecting AI assistants to the systems where data lives. The specification is published in dated revisions, and the current revision at the time of writing is 2026-07-28.
Revision dates matter when you approve servers, because behavior changes between them. Streamable HTTP arrived in revision 2025-03-26 as a replacement for the earlier HTTP+SSE transport, and revision 2026-07-28 removed the initialize handshake so that every request carries its own protocol version. Before rolling out a server, confirm these points with whoever built it.
- Which protocol revisions the server supports, and whether your AI clients support the same ones.
- Which transport it uses, and therefore whether credentials sit on laptops or with a central owner.
- For HTTP servers, whether sign-in follows the MCP authorization spec and tokens are checked for audience.
Sources for this section
- MCP uses JSON-RPC 2.0 messages between hosts, clients and servers; servers offer resources, prompts and tools, and clients may offer elicitation. Source
- The MCP specification describes prompts as user-controlled, resources as application-controlled and tools as model-controlled. Source
- The MCP specification defines two standard transports: stdio, using a client-launched subprocess, and Streamable HTTP, using HTTP POST to a single MCP endpoint. Source
- Streamable HTTP was introduced in protocol version 2025-03-26 as a replacement for the HTTP+SSE transport, and the server runs as an independent process handling multiple clients. Source
- MCP authorization is optional, is based on OAuth 2.1 for HTTP transports, stdio implementations should take credentials from the environment, and servers must validate token audience and return HTTP 401 for invalid tokens. Source
- Revision 2026-07-28 removed the initialize handshake so every request carries its protocol version. Source
- Anthropic open-sourced the Model Context Protocol on November 25, 2024. Source
Frequently asked questions
Does connecting an MCP server mean our records train someone else's model?
Not by itself. MCP only moves records into the AI tool that requested them. Whether those records can be retained or used for training depends on the AI vendor's terms for your plan and any settings you control. Read those terms before connecting systems that hold customer or employee data.
Could a buyer access our records through MCP instead of receiving a copy?
Live access by an outside party to production systems raises privacy, security and scope problems that a prepared copy avoids. Licensing deals usually deliver a defined package that has been de-identified and approved. With SourceX, large datasets stay in the supplier's own storage or ship on encrypted drives rather than being hosted by SourceX.
Is MCP itself a security risk?
The protocol is a way of connecting systems, so the risk sits in how each connection is built and governed. Unreviewed servers, broad credentials and agents that can act without approval create most of the exposure. Least privilege, logging and an approved server list address most of it.
Do our MCP connections affect a future data license?
They can. A rights review asks which parties have already received the records and under what terms. If an AI vendor kept rights to content fetched through MCP, counsel will want to know. Keeping a register of connections makes that question quick to answer.
Do agent logs from MCP tools become licensable records?
Logs of tool calls and outcomes can describe real work, but they mix your records with AI-generated text and are governed by vendor terms. Treat them as a separate record family with its own rights review rather than adding them to an existing package by default.
Related resources
- DataSales call transcripts
- QuestionDo AI labs buy legal documents?
- QuestionDo AI labs delete data after training?
- InsightIf AI training is fair use, why do buyers still license data?
- InsightOpt-in vs opt-out for AI training in B2B SaaS contracts
- InsightCan a 3PL license warehouse video to robotics and AI developers?
See if your company qualifies
A short company assessment. No data uploads are needed.