The question behind the question
Anyone wanting to bring AI features into their own software almost automatically ends up at the vendors' API: a key, per-token billing, every request costs money. For a product with many users, that's the right and only clean path. For your own use, though – a tool that runs in-house, serving a handful of people – that math often feels off-putting: ongoing, hard-to-predict costs for something you might use only a few times a day. So the real question is rarely "can I get AI into my software?", but "can I do it without every use ticking a meter?". And here something fundamental changed at the end of 2024.
What MCP actually is – without the hype
The Model Context Protocol (MCP) is an open standard that Anthropic introduced and published at the end of 2024 and that is now broadly supported – including by OpenAI. Simplified, it's a shared "socket standard" between AI programs and external data or tools. On one side sits an MCP server: a small program that exposes your software's capabilities and data to the outside ("you can read the portfolio data here", "you can generate a report here"). On the other side sits an MCP client – such as Claude Desktop or ChatGPT – that can use these offered tools.
The key point: the MCP server can run locally on your own machine. Claude Desktop then connects to that local server, and every action the AI wants to take must be explicitly approved by you. So the AI only reads or acts where you allow it – and you use your normal subscription access for it, not the API.
The decisive difference: workplace, not product backend
Here lies the insight most tutorials miss – and without which you'll answer the licensing question wrong. MCP connects your software to an AI client that a human operates. The AI does not live inside your software. Your tool doesn't become "smart"; it merely provides a clean interface through which a human, using their AI program, can access the tool's data. That's a fundamentally different picture from "I'm building AI into my product".
- What this path IS: a human opens their AI client (Claude Desktop, ChatGPT), to which your software is connected via MCP, asks a question or gives an instruction, receives the relevant slices from their own tool and a result – every action approved by them. They use their own subscription seat.
- What this path is NOT: your software calling the AI in the background, unnoticed and with no human present, for other end users. That would be a product backend – and the API and commercial terms are for that, not a subscription.
The frequently asked "can you only do this as an individual?" therefore misses the core. The relevant line runs not between private and commercial, but between "a human operates their AI seat" and "a product helps itself to the AI on behalf of others".
Individual, company, provider – who may do what
Individual / personal use
For personal use, this path is unproblematic: it's exactly what Claude Desktop and the local MCP connection were designed for. You connect your own tool to your own subscription (Claude Pro/Max or ChatGPT Plus/Pro) and work with it. The only important thing is that it stays personal use – the individual subscriptions are, per the terms, meant for individuals and non-commercial use, and the login credentials must not be shared with others.
Companies
Companies can use this path too – but cleanly, on the plans built for it. Claude Team and Enterprise as well as ChatGPT Business and Enterprise explicitly support custom MCP connectors. With Claude, the organisation owner adds a custom connector to a server connected via MCP, and employees then enable it individually; since mid-2026 access can even be provisioned centrally through identity management (e.g. Okta). On the ChatGPT side, "Developer Mode" provides full MCP support (read and write), enabled via the workspace settings.
What companies should not do: let employees use their personal individual subscriptions for company workflows, or have a single subscription used by several people or a service. That collides twice with the terms – commercial use of a personal subscription, and account sharing. The right framework for companies is the business plan, not stacked-up personal subscriptions.
A detail with governance consequences: company connectors usually run as remote MCP servers that the vendor's cloud accesses from outside – so the server has to be reachable from the internet, and the vendor's IP ranges must be allowlisted. That's different from the purely local Claude Desktop case, and with sensitive data it should be a deliberate decision.
If you're building a product
The moment your software calls the AI for end users who aren't themselves sitting at their own AI seat – i.e. a feature you roll out, distribute or sell – the subscription path is no longer permitted. Then you need the API under the commercial terms. That's not harassment but the logical boundary: a subscription is meant for one human's work, not as the engine behind a product for many.
What the vendors actually say
The often-suspected contradiction – "they only half tolerate it" – doesn't hold. Both major vendors actively built this path. Anthropic invented MCP, open-sourced it, and integrated it into Claude Desktop and the Team/Enterprise connectors. OpenAI introduced Developer Mode with full MCP client support in September 2025. The message is unambiguous: they want humans to connect their own tools and data to their AI seat.
Equally clear is where they draw the line. Anthropic's consumer terms state that the consumer services must not be used for commercial or business purposes, that login credentials must not be shared, and that automation is only allowed where explicitly permitted or via an API key. The API has its own, commercial terms. Translated: connect your tool to your seat, yes – but don't turn the subscription into a product engine or a shared access for many.
The honest limits
So that no rosy picture emerges, the limits of this path belong on the table just as much as its benefits:
- A human has to sit in front of it. The charm is also the limit: it's not background automation. Anyone wanting a task to run fully unattended around the clock is in the wrong place with the subscription path – then there's no way around the API (or genuine automation).
- Subscriptions have usage limits. They're built for one human's daily work, not for high volume. Anyone regularly triggering hundreds of requests a day programmatically will hit limits – and at that scale the API is the cheaper and correct choice anyway.
- A local MCP server does not mean local AI. This is the most frequently overlooked point: the MCP server runs at your end, but the data slices actually needed for a question still go to the language model in the vendor's cloud. MCP controls what is accessed – it is not a data-protection mechanism. Anyone who truly must keep data in-house needs a locally running model, a different setup (see our article on data protection and AI).
- The MCP interface itself is a security question. A server that carelessly exposes everything is a risk. What matters is which tools and data it offers, how tightly the access is scoped, and how carefully write actions are secured. This is exactly where clean implementation separates from tinkering.
A real-world example: the asset management tool
A concrete case from a delivered project (anonymised): a custom-built piece of software for private asset management – portfolios, transactions, income, fees, all in one place. The wish wasn't "turn the tool into an AI product", but something down-to-earth: make the annual preparation of tax documents less tedious.
Instead of building an API-connected AI feature into the software, a lean MCP server was added that makes exactly the slices needed for this readable: realised gains and losses, dividends, fees, cleanly separated per tax year. The owner now opens Claude Desktop and asks the AI to build a structured overview for the tax return from this data – the compilation that used to be painstakingly gathered by hand from several views, and that the tax advisor needs as a starting point. Every data access is confirmed, nothing is sent automatically, and no API fee is incurred.
What's remarkable about this pattern: the "AI feature" was added to the custom software without integrating a single line of vendor API and without ongoing usage costs. The real engineering wasn't in the AI but in the MCP server in front of it – in offering exactly the right, tightly scoped data cleanly and securely. It's the same idea as with a RAG system: the value lies in carefully preparing what the AI is allowed to access, not in the model itself.
What this means for you
If you have your own custom-built software – or are having one built – MCP is an often-overlooked lever to add AI capabilities without walking into an API cost trap. Whether this path fits comes down to a few honest questions:
- Is there a human in front of it during use, giving instructions and accepting results? Then the subscription path via MCP is a serious option. Should it run unattended in the background? Then API or classic automation.
- Are you an individual or a company? Both work – but the company on the appropriate business plan (Team/Enterprise or Business/Enterprise), not via pooled personal subscriptions.
- How sensitive is the data? Remember that the slices used still go to the vendor's cloud. If that's a dealbreaker, the path is a local model, not MCP alone.
- How clean is the interface? A good MCP server exposes only what's needed and secures write actions. That's the part that decides between benefit and risk.
This is exactly where our work comes in: Beyond Prompt builds the custom software – and the cleanly scoped MCP server in front of it right along with it, so you can use your existing subscription instead of running into ongoing API costs, and keep control over what the AI can access at all. That's Custom Applications, extended by an honest, cost-aware AI layer.