Open-Source MCP Servers: Licenses, Free Options, and Self-Hosting Explained

TL;DR

• Yes, the Model Context Protocol (MCP) is open source, and many MCP servers are too. But every server has its own license, so check each one before you rely on it.
• MIT and Apache 2.0 are the most common licenses for MCP servers and both allow commercial use. GPL requires you to share source when you distribute the software. AGPL goes further and reaches servers you host over a network.
• Free, open source, and managed are three different things: price, license, and who runs the server. The code is often free to self host, but hosting, paid APIs, and engineering time are not.
• Before you deploy, check the license file, dependency licenses, maintainers, and permissions. Self host for control, go managed for speed, or mix both.

Search for an MCP server and you will find hundreds of repositories, each with its own license, its own owner, and its own idea of what "free" means. That is where teams get stuck. A server that looks open source can turn out to have no license at all. One that is free to download can still cost real money to run. And one that works on a laptop can become a liability in production.

This guide answers the questions developers ask most. It covers whether MCP and its servers are open source, what MIT, Apache 2.0, GPL, and AGPL actually allow, how free, open source, and managed servers differ, what self hosting really costs, how to vet a server for security and maintenance, and when to self host or go managed.

Are MCP servers open source and free to use

Many MCP servers are open source and free to download, but not all of them, and free to download is not the same as free to run. The Model Context Protocol itself is open source. Each MCP server is a separate program with its own license, price, and hosting model, so you have to check them one by one.

Is the Model Context Protocol open source? Yes. Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, on December 9, 2025. The specification repository is moving from the MIT License to Apache 2.0. New contributions are Apache 2.0, older contributions stay under MIT where the authors have not agreed to relicense, and documentation is CC BY 4.0. The official SDKs use the same permissive licenses: the Python SDK is MIT licensed today, while the TypeScript SDK is part of the move to Apache 2.0.

MCP servers fall into four groups:

• Reference servers: The modelcontextprotocol/servers repository holds a small set of examples such as filesystem, git, memory, fetch, and time. They are Apache 2.0 for new contributions and MIT for existing code. The README calls them reference implementations and educational examples, not production ready solutions.
• Vendor servers: At the time of writing, the GitHub MCP server is MIT licensed, while the AWS Labs MCP servers, the Kubernetes MCP server, and the Supabase MCP server are Apache 2.0.
• Community servers: Anyone can publish one, under any license, including no license at all.
• Hosted or proprietary servers: A vendor runs the endpoint and you cannot inspect or change the code.

On price, the code of an open source server costs nothing. What you can still pay for is hosting, the paid APIs the server calls, and the engineering time to keep it healthy. We break those costs down below. If you are new to how these servers connect agents to tools like GitHub, Slack, and Notion, our complete guide to MCP servers covers the basics.

What MCP server licenses allow: MIT, Apache 2.0, GPL, and AGPL, how to verify a license and its dependencies

MIT and Apache 2.0 let you use, modify, and ship an MCP server in a commercial product with very few obligations. GPL requires you to share source when you distribute the software. AGPL extends that duty to software people use over a network, which matters for hosted MCP servers. Here is what each one means in practice:

• MIT: Keep the copyright and license notice. You do not have to publish your changes, and you can ship the result under different terms. It has no explicit patent grant.
• Apache 2.0: Keep the notices, mark files you changed, and preserve any NOTICE file. You do not have to publish your changes. It adds an explicit patent grant that ends if you sue over patents, and it grants no trademark rights.
• GPLv3: If you distribute the software, in source or binary form, you must provide the full source under GPLv3. Running a modified copy on your own servers is not distribution. Bundling a GPLv3 MCP server inside a desktop app you ship to customers is.
• AGPLv3: Everything in GPLv3, plus a network clause. If you modify an AGPLv3 MCP server and let people use it over a network, such as a remote server on Streamable HTTP, you must offer them the modified source. Running it unmodified for your own team is usually simpler, but have a lawyer confirm.

Two traps are worth knowing. First, a public repository with no LICENSE file is not open source. Without a license, the author keeps all rights by default and you have no permission to copy or modify the code. Second, source available licenses such as the Business Source License, the Server Side Public License, and the Elastic License 2.0 let you read the code but are not approved by the Open Source Initiative. They can restrict commercial use or hosting. This is general information, not legal advice.

To verify a license and its dependencies, work through these steps:

1. Read the LICENSE file at the repository root: The license badge GitHub shows is detected from that file, so open the file itself. Do not trust the README alone. The MCP specification repository's README still describes the project as MIT licensed, while its LICENSE file explains the move to Apache 2.0.
2. Check the package manifest: Compare the license field in package.json, pyproject.toml, or Cargo.toml with the repository license. The published package should match the repository. The field uses SPDX identifiers such as MIT or Apache-2.0.
3. Scan the dependency tree: Your server inherits the obligations of every library it pulls in, including transitive ones. Tools like license-checker for npm, pip-licenses for Python, or the ScanCode Toolkit list every license in the tree.
4. Flag copyleft dependencies: A GPL or AGPL library inside a permissive server can change what you owe when you ship or host the combined work. Our guide on how to manage open source dependency risk shows how to vet and monitor dependencies over time.
5. Watch for license changes and open core splits: Projects can relicense, as MCP is doing, and some keep enterprise features in a separate folder under a commercial license. Pin versions and read the license again when you upgrade.
6. Keep a record: Store a software bill of materials or a simple license inventory for every server you run.

Free vs. open-source vs. managed MCP servers: What's the difference?

Free, open source, and managed describe three different things. Free is about price. Open source is about the license and your right to inspect, modify, and redistribute the code. Managed is about who runs the server. One server can be any combination of the three, and none of them implies the others.

• Free: It costs nothing to start. It might be open source code you run yourself, or a hosted endpoint on a free tier with usage caps. The underlying service it connects to may still bill you.
• Open source: An approved license lets you read, audit, fork, and change the code. It does not mean someone else hosts it, and running it in production still costs money.
• Managed: A vendor hosts, patches, and scales the server. You get uptime commitments and often built in features like single sign on, role based access, and audit logs, usually on a paid plan. The code behind it may be open or closed.

That gives you four common combinations:

• Free and open source: A server you run locally over stdio. Zero hosting cost, but you own everything.
• Open source but not free to operate: The same server deployed in production, with hosting, monitoring, and on call time attached.
• Free but closed: A hosted endpoint on a free tier. Easy to start, but you cannot inspect the code, quotas apply, and your tool inputs and results travel through the vendor.
• Managed and paid: A hosted service with support and governance, priced by plan or usage.

Corsair sits across these lines on purpose. It is open source under Apache 2.0 and free to self host, with an optional hosted Hub for the parts of an integration that need a public URL.

What does it really cost to self-host an MCP server?

The software costs nothing, but running it does. A server on your laptop over stdio costs nothing to host. A production server adds real line items:

1. Hosting and networking: Remote servers need compute, TLS, log storage, and network egress. The MCP 2026-07-28 specification removes protocol level sessions, so a remote server is easier to scale across instances behind a load balancer. That lowers the effort, but not to zero.
2. Underlying API and service fees: An MCP server only translates requests. Calls to a paid SaaS product, a cloud API, or a database still land on your bill and count against your rate limits.
3. Engineering time: This is usually the biggest cost. Someone has to apply dependency patches, follow specification changes, track upstream API changes, rotate secrets, and answer the pager. Corsair's own view is that the first 80 percent of an integration is quick, and the last 20 percent (token refresh, webhook signature checks, API deprecations, rate limits, and tenant isolation) becomes a permanent maintenance job.
4. Security and governance: You own secret storage, OAuth flows, audit logging, and access control. Many open core projects keep single sign on, role based access, and audit features in paid tiers, so a self hosted setup may need custom work or a commercial license.
5. Model token costs: Every tool you expose adds schema to the model's context. Large tool catalogs raise token spend and can confuse tool selection. Corsair's adapters expose three tools (discover operations, inspect a schema, and run a script) no matter how many integrations are installed, which keeps the context small.

A fair rule of thumb: if you run one or two servers locally, self hosting is close to free. If you run a dozen in production for customers, budget for people, not servers.

How to evaluate an open-source MCP server for security and maintenance

Check four things before you trust any open source MCP server: who published it, whether it is maintained, what it can do on your machine and accounts, and what it pulls in. Use this checklist:

1. Publisher and provenance: Prefer servers from the vendor of the service or from the MCP steering group, and browse the official MCP Registry rather than random search results. Impostors exist. In 2025, a package called postmark-mcp on npm copied a legitimate project and looked normal for 15 versions. Version 1.0.16 then started copying every email sent through it to an outside address. It had about 1,500 weekly downloads, and installs kept leaking after the package was removed. Pin versions and read the diff before every upgrade.
2. Maintenance: Review commit history, release tags, and how fast issues get answered. Check whether the repository is archived. Several early reference servers for GitHub, Slack, Postgres, and Google Drive are now archived, and some were taken over by other maintainers or replaced by official vendor servers. Confirm which specification version the server targets: the current release is 2026-07-28, and servers still on the older SSE transport need to move to Streamable HTTP. Look for a SECURITY.md file that says how to report vulnerabilities.
3. Blast radius: A local server runs with your user's permissions, so it can read the files and call the tools your account can. Run it in a container, limit filesystem access, and use read only modes and tool allow lists where they exist, such as the options in the GitHub MCP server. Never run a command from a README without reading what it launches.
4. Authentication and secrets: Remote servers should use OAuth, validate the token audience, and reject tokens issued for some other service. Keep credentials in environment variables or a secrets manager, never in config files committed to git. Logs should redact tokens, and scopes should be as small as the job allows.
5. Tool design and approvals: The model reads tool descriptions and returned data, so a poisoned description or injected text can steer an agent. Require human approval for destructive actions. In Corsair, for example, each integration has a permission mode, and destructive actions wait for explicit approval before they run.
6. Dependencies and supply chain: Check lockfiles, automated dependency alerts, code scanning, and the license of every transitive dependency. Our guide on how to evaluate an open source project before you build on it goes deeper on governance, documentation, and production readiness.
7. Test before you trust: Run the server in the MCP Inspector, call every tool by hand, and watch exactly what it sends and returns before you connect it to a real agent.

Self-hosted vs. managed MCP servers: Which should you choose for production?

Self host when data control, compliance, or private network access decides the question. Go managed when speed, a small team, and built in governance matter more. Many teams do both: they self host the sensitive servers and use managed endpoints for commodity SaaS tools. Use this as a guide:

Choose self hosted when:

• Tool inputs, results, and credentials must stay inside your network or VPC for compliance or customer contracts.
• The agent needs to reach private systems such as internal databases, on premises tools, or an air gapped environment.
• You need to modify tool behavior, add integrations the vendor does not offer, or avoid a vendor roadmap.
• You want predictable latency, because there is no extra hop to a third party.

Choose managed when:

• You need to be live this week and no one on your team wants to run infrastructure.
• You need uptime commitments, single sign on, role based access, and audit logs without building them.
• Your tools are standard SaaS integrations with no special data residency demands.
• Your team is small and engineering hours are scarcer than budget.

Ask three questions to settle it. Where must the data live? Who is on call when it breaks? How many integrations will you run a year from now?

The hybrid model is often the best fit, and it is how Corsair works. You run the SDK inside your own app, your users' tokens are stored encrypted in your own database under your own key, and Hub is an optional relay for the parts that need a public URL: OAuth callbacks, connect pages, and approval screens. Hub does not keep your tenants' tokens. For a deeper look at the tradeoffs, read our breakdown of self hosted vs managed integration platforms.

Closing thoughts

Open source MCP servers give you the code, the license, and the freedom to run them anywhere, and the real work is choosing the right ones and keeping them healthy. Corsair is an open source (Apache 2.0), YC backed integration layer for AI agents that connects your product to 200+ services with OAuth, permissions, and MCP built in. You can self host the full SDK for free, keep credentials encrypted in your own database, and use Hub only for connect pages, OAuth callbacks, and approvals. The project has passed 13,000 stars on GitHub, and you can start on the free Hobby plan today.

FAQs

Is the Model Context Protocol open source?

Yes. MCP is an open standard governed under the Linux Foundation's Agentic AI Foundation since December 2025. The specification repository is moving from the MIT License to Apache 2.0, with new contributions under Apache 2.0, older contributions under MIT where authors have not agreed to relicense, and documentation under CC BY 4.0.

Are all MCP servers free to use?

No. Many servers are open source and free to download, but running one can still cost money for hosting, paid APIs, and engineering time. Some hosted MCP endpoints are free only up to a quota, and others are paid managed services.

Can I use an open source MCP server in a commercial product?

Usually yes. MIT and Apache 2.0 allow commercial use if you keep the required notices. GPL requires you to share source when you distribute the software, and AGPL also applies when you offer a modified server to users over a network. Check the license and its dependencies, and ask a lawyer when the stakes are high.

Is it safe to run a community MCP server?

Treat it like any third party code that runs with your permissions. Check who published it, whether it is maintained, which scopes it asks for, and what its dependencies are. Pin versions, run it in a container, and require approval for actions that change data.

Can I self host Corsair for free?

Yes. Corsair is open source under Apache 2.0, and you can run the full SDK on your own infrastructure at no cost. Hub is optional, and there is a free Hobby plan with 50 connections and up to 3 team members. Pricing was current at the time of writing, so check the pricing section on corsair.dev for updates.