DEV Community: Jonathan Blessing

How to Choose an MVP Development Partner – and When to Build or Buy Instead

Jonathan Blessing — Mon, 21 Sep 2026 10:06:23 +0000

In brief: An MVP development partner is hired to ship the smallest product that tests a business hypothesis – typically a 4–8 week engagement at $15K–$75K. Anything above $150K is a product, not an MVP. Skip user accounts, admin dashboards, payment processing beyond Stripe Checkout, and infrastructure that scales past 50 users – you need 10 good users, not 10,000 mediocre ones. Build internally with technical co-founders, buy with no-code for CRUD-heavy flows, partner when you need production-grade code or polish.

An MVP development partner is an outside firm you hire to ship the smallest product that will test a business hypothesis – typically a 4–8 week engagement costing $15,000 to $75,000. Engagements above $150,000 are products, not MVPs. Choose one when you need speed and outside perspective more than you need permanent engineering headcount. The MVP itself has become the most misunderstood concept in product development. Founders use it to mean "version 1 of my product." Development agencies use it to mean "the smallest thing we can sell you." Neither definition is useful.

An MVP is a learning instrument. It exists to test a hypothesis about your market as cheaply and quickly as possible. The output of an MVP is not software – it's validated knowledge about whether your customers will pay for what you're building. If your MVP doesn't produce a clear yes-or-no signal about a specific business hypothesis, it's not an MVP. It's just an underfunded product launch.

This distinction matters enormously when you're deciding how to build it, who to build it with, and how much to spend. The right approach depends on what you need to learn, not what you want to ship.

What an MVP Actually Is

An MVP tests one thing: will customers engage with this product in the way your business model requires? That's it. Everything else is secondary.

For a SaaS product, that means proving target users will sign up, complete onboarding, and use the core feature repeatedly. You're not testing whether the product is beautiful or feature-complete – you're testing activation and retention. I worked with a productivity tool founder who spent eight weeks building a gorgeous dashboard before testing their core hypothesis (that users would actually adopt the tool daily). They learned in user testing that nobody cared about the dashboard. They cared about whether the core feature worked. Six weeks of polished UI was wasted effort.

For a marketplace, the test is entirely different. Both sides of the two-sided market have to show up. I've seen marketplace founders build excellent supply-side experiences and then get zero demand, or vice versa. The MVP needs to prove you can achieve liquidity – that you can get enough sellers and buyers interested in using the same platform at the same time. This usually requires manual work on one side (you personally recruiting early sellers, or you as the first buyer) to jump-start the network.

For an internal tool, the question is adoption. Employees have been using a spreadsheet for five years. Your job isn't to build something technically impressive – it's to build something they'll actually switch to. Many internal tool MVPs fail because they're technically sound but require a behavior change that the organization isn't ready to make. The MVP needs to prove the change is worth it.

Common Failure Mode

Building a "full product" and calling it an MVP because it doesn't have all the features yet. If your MVP takes 6 months and costs $200K, it's not an MVP. It's a product that launched before it was ready – one of the recurring decision errors that lead to re-selection inside the first year. Real MVPs take 4–8 weeks and cost $15K–75K depending on technical complexity.

The specifics depend on what you're testing, but here's what you can almost always skip: user accounts and authentication systems (use magic links or manually onboard people), admin dashboards (manage your MVP users manually via database), payment processing (Stripe Checkout or even manual invoicing), email notifications, mobile apps (responsive web is fine), and infrastructure that scales to thousands of users (you need 10 good ones, not 10,000 mediocre ones).

What you absolutely need: the core value proposition – that one thing that makes someone choose your product over the status quo. You need enough polish that users evaluate the value, not the janky UX. And you need analytics to measure the specific behavior you're testing. Nothing else. Not "nice to have" features, not architectural elegance, not code quality that would impress your team. Just the core, measurable hypothesis.

A fintech founder I worked with planned an MVP with full multi-tenant architecture, audit logging, and compliance features. They were planning to spend $200K over six months. The actual hypothesis was: "Do B2B customers prefer this specific approach to settlement?" We cut it down to a functional prototype that answered that one question in six weeks for $25K. They got their answer, iterated the approach based on feedback, and then built the real thing properly. The first MVP would have proven nothing except their perfectionism.

	Build	Buy	Partner
Best when	Technical co-founders, straightforward tech, speed matters most	Simple CRUD app, no-code tools work, accept rebuild later	Technical complexity, need production code, clear hypotheses
Cost	$0–15K (sweat equity + tools)	$5K–25K (platform + your time)	$15K–150K (development firm)
Timeline	2–6 weeks	Days to 2 weeks	4–16 weeks

Build vs. Buy vs. Partner

This is the fundamental decision. Each path has wildly different cost structures, timelines, and risk profiles – and each produces different problems downstream.

Build internally makes sense when you have technical co-founders or a small engineering team already in place. You get maximum speed (no onboarding, no contracts, no negotiation), maximum control, and the codebase becomes your asset immediately. The technical team knows your product inside and out from day one.

The trap is real though. If your technical team is also your founding team, building the MVP means those same people aren't talking to customers, closing sales, or validating the business model. Your engineers are spending time on deployment pipelines and database migrations instead of being available to react when customer feedback suggests a pivot. The best technical co-founders I've worked with recognize this tension explicitly and ruthlessly push for the simplest possible MVP – not the most technically elegant one.

Choose this when you have technical founders with strong product judgment, your MVP doesn't require specialized technical expertise (ML, real-time infrastructure, etc.), and speed matters more than polish.

Buy (no-code/low-code) has gotten genuinely good. Tools like Bubble, Webflow, Retool, and Airtable can build functional products in days instead of weeks. For many MVP categories – internal tools, simple marketplaces, landing-page-plus-backend, directory sites – no-code is the fastest path to an answer.

But here's the reality: no-code works great until it doesn't. You'll hit platform limitations exactly when your product starts succeeding. I watched a marketplace founder validate their model perfectly on Bubble. Three months later, when they wanted to move to custom code and expand their feature set, the migration was painful and expensive – essentially a full rebuild. This is fine if you know going in that success means rebuilding. It's catastrophic if you assumed the no-code version would just evolve.

Choose this when your MVP is straightforward (CRUD operations, standard workflows), you need to validate fast with zero engineering investment, and you explicitly accept that scaling beyond MVP will require a rewrite.

Partner with a development firm makes sense when you need technical expertise you don't have in-house, when you need a level of polish that no-code can't match, or when you need code that can evolve into your real product without a full rewrite.

The hard truth: most development agencies are not good at MVPs. They're optimized for building fully-scoped products with clear specifications and happy clients. MVP work requires a completely different mindset – the willingness to cut scope ruthlessly, ship imperfect code, and optimize for learning speed over code quality. Agencies that can't make this shift will build you something beautiful and over-engineered that takes three months and costs twice your budget to test one hypothesis.

Choose this when your MVP requires genuine technical complexity (machine learning, real-time infrastructure, hardware integration – for AI specifically, see how to select an AI development partner), when you need production-grade architecture that your team will build on top of, and when you have crystal-clear hypotheses to test.

Key Signal

Ask potential MVP partners this question: "What would you cut from the scope?" If they agree with everything on your feature list, they're not the right partner. Good MVP developers are aggressive scope cutters. They'll push you to define the one thing your MVP needs to prove and strip out everything else. This is one of the evaluation signals that predict delivery better than portfolios do.

What MVP Development Actually Costs

Pricing for MVP development is wildly inconsistent because everyone's using "MVP" to mean something different. Here's what the money actually gets you at each tier.

$5K–15K gets you a proof of concept. This is a clickable prototype, a landing page with a signup flow, or a no-code implementation that demonstrates the core idea. It's enough to show to customers and measure interest. It's not a working product – it won't scale, it won't handle real usage, and it probably won't stay running for six months. But it's enough to prove customers care.

$15K–50K is where most startups actually test product-market fit. You get a working application with one core workflow, a basic UI that doesn't win design awards, and infrastructure that can support a few hundred users. The code is pragmatic, not elegant. It'll live for 4–8 weeks and then you'll decide: does this work or not? This is the sweet spot for learning fast.

$50K–150K is production-grade. This is a polished application with authentication, payment integration, responsive design, and architecture that your team can actually build on top of without a complete rewrite. The code will survive beyond MVP. It takes longer (8–16 weeks) because more care goes into sustainability. Choose this when your market expects quality (enterprise, healthcare, fintech), or when the technical requirements genuinely demand it. A SaaS company serving enterprises will need this tier. A marketplace testing liquidity might not.

$150K+ is not an MVP – it's a product. If a development firm quotes you $150K to "test a hypothesis," they're building a full product. That might be the right decision for your situation. But be clear about what you're actually doing – and pick the pricing model that matches: fixed-fee makes sense when scope is locked, time-and-materials when the discovery is genuinely open.

Questions to Ask Yourself

What is the minimum I need to build to test my riskiest assumption? If the answer involves more than 3 core screens, you're probably building too much. What happens if the MVP succeeds? Do I need to rebuild, or can this codebase evolve? If you need production-grade code, budget accordingly. What happens if the MVP fails? How much am I willing to lose to find out?

Selecting an MVP Development Partner

If you go the partner route, the evaluation criteria are different than selecting a full-scale development firm. Read how to select a technology partner for the comprehensive framework, but here's what actually matters for MVP work.

Look for startup experience, not enterprise experience. Enterprise development firms optimize for predictability, documentation, and protecting themselves from scope creep. MVP development is the opposite: speed, adaptability, and comfort with ambiguity. When you talk to a potential partner, ask them to walk through specific products they've taken from concept to market. Not features they've built for existing platforms. Not bespoke software for fortune 500 companies. Products. They should have examples of three to five MVPs they've shipped in the last year.

Evaluate their product judgment, not just their technical skills. The best MVP partners will make you uncomfortable. They'll challenge your feature list and suggest simpler ways to test your hypothesis. They'll say "you don't need that yet" more often than "sure, we can build it." A partner who just builds everything you specify is a contractor. You need someone with product sense who'll push back.

Check their delivery pace. Ask about their last three MVPs. How long from kick-off to deployed product? If the answer is 4–6 weeks, they know what they're doing. If it's 3–6 months, they're not building MVPs – they're building products slowly. That's a different thing entirely.

Understand the actual team. MVP work succeeds with small, senior teams. Two experienced developers and a designer will ship faster and better than six junior developers every time. Ask specifically who will work on your project. Get their resumes. If they describe the team as "a delivery manager, two senior engineers, and four junior engineers," that's not an MVP team. That's overkill.

Clarify the architecture question. After the MVP succeeds, what happens to the code? Can your internal team take over development? Is it designed to evolve or is it throwaway? The answer should align with your actual post-MVP plan. Some teams build "throw-it-away" MVPs because they know the learning will change everything. Others build MVPs on production-grade code because they plan to iterate continuously. Both are valid – just make sure you agree with your partner.

See reference checks for technology partners for how to validate these claims with real client references.

MVP Development Consultant vs. MVP Development Partner

The two titles get used as if they were the same purchase. They are not. An MVP development partner builds: a firm you pay $15K–$75K to ship a working hypothesis test in 4–8 weeks. An MVP development consultant advises: someone who helps you decide what the hypothesis is, what to cut, and which partner to hire – and who is gone before any code is written. Consulting is sold as hourly time or a short scoped engagement; technologists charge $150–$300 an hour, and a search-and-selection engagement runs two to four weeks. It earns its fee when the build is large enough that a wrong bet is expensive – the same $50K line that applies to any buyer-side technology advisor – or when you cannot evaluate the partners yourself. It does not when no-code will do. And if the person selling "MVP consulting" also wants to build the MVP, you are talking to a partner with a nicer title.

MVP Development Partner Selection Criteria

If the partner route is the right one, the selection is short – six checks, and a good partner clears them in the first call.

They ask about the hypothesis before they quote. An MVP tests one thing. A partner who prices the build without asking what you are trying to learn is pricing a product.
They have shipped MVPs, at MVP prices, and can name them. Four to eight weeks, $15K–$75K, with a founder who will take a call. Enterprise references are not the same evidence.
They push scope out, not in. The right partner's first instinct is to remove the admin dashboard and the user accounts. The wrong partner's instinct is to add a phase two.
The pitch team is the build team. Named people, with the seniority to make product calls in a standup rather than a status meeting.
The codebase is yours and is legible. Ask what the handoff looks like for a second team – documentation, tests, deployment. An MVP that only its builder can run is a hostage, not an asset.
They tell you what they would not build. A partner with no opinion about what to leave out has not built an MVP before.

A quote above $150K fails the test before it starts – whatever it is, it is not an MVP.

Managing the MVP Engagement

MVP engagements fail for different reasons than product builds. Understanding these patterns will save you from the most common disasters.

Scope creep disguised as "learning." You test the MVP with five customers. Customer A wants feature X. Customer B wants feature Y. Customer C wants both plus feature Z. You feel like you're learning, so you build all of it. Now you've spent 12 weeks and $80K to build a product instead of running a focused experiment. The problem: you can't tell if the core hypothesis worked because you added everything else too. Discipline means deciding in advance: what signal will prove or disprove my hypothesis? Only features that directly address that question make it in.

Perfectionism from founders. The MVP ships. The button alignment is slightly off. The loading state looks janky. The colors could be better. You want to fix it before showing users. Resist this instinct with everything you have. Real users don't care if your product is beautiful – they care whether it solves their problem. If you spend two weeks perfecting the UI before validating the core idea, you've burned money for nothing. This kind of premature optimization shows up consistently in our analysis of why technology projects fail.

Building for scale too early. Your MVP needs to handle 10–50 users, not 10,000. If your development partner is discussing caching strategies, microservices, database replication, or performance optimization, they're solving the wrong problem. That work comes later, after you know people want what you're building.

Realistic MVP timeline. This is what should actually happen: Week 1, align on the core hypothesis and define the user flow that proves or disproves it. Kick off development. Weeks 2–3, build the core functionality and test it internally. Week 4, put it in front of 5–10 real customers who match your target profile. Get feedback. Weeks 5–6, iterate based on what you learned and ship the improvements. Week 6–8, decision point. You have evidence now. Either the hypothesis holds (persevere), or it doesn't (pivot or kill). Either way, you have an answer.

Key Signal

At the end of the MVP engagement, you should be able to answer: "Do we have evidence that customers want this product enough to pay for it?" If the answer is yes, invest in building the real thing. If the answer is no, you've spent $15K–75K to avoid spending $500K on something nobody wants. That's a win.

Related Guides

How to Select a Technology Partner – full evaluation framework for development partners
How to Select a Product Development Partner – when you need judgment about what to build, not just build capacity
Product Development Outsourcing – the broader category MVPs sit inside
Outsourcing Software Development – when and how to outsource
Software Development RFP Template – when the MVP scope is stable enough for a formal RFP
Technology Vendor Due Diligence Checklist – comprehensive evaluation checklist
Why Technology Projects Fail – failure patterns that apply to MVPs too
Product Design Process – the design thinking that should precede MVP development
AI for Startups – read this before adding AI to your MVP

Frequently Asked Questions

What is an MVP development partner?

An outside firm you hire to ship the smallest product that will test a business hypothesis – typically a 4–8 week engagement costing $15,000 to $75,000. They're optimized for speed over polish. Engagements above $150,000 are products, not MVPs.

How much should an MVP cost?

$5,000–$15,000 for a clickable prototype. $15,000–$50,000 for a working app that can find product-market fit. $50,000–$150,000 for production-grade code that survives beyond MVP. Anything above $150,000 is a product, not an MVP.

How long should an MVP take to build?

4–8 weeks for a real MVP. A clickable prototype in 2–3 weeks. A production-grade MVP in 8–16 weeks. If a partner quotes 3–6 months to build an MVP, they're building a product – which might be the right call, but don't confuse the two.

Build, buy, or partner for an MVP?

Build internally if you have technical co-founders and speed matters more than polish. Buy (no-code) for CRUD-heavy products where you accept a rewrite at scale. Partner when you need technical expertise, production-grade code, or polish that no-code can't match.

What should I skip when building an MVP?

User accounts (use magic links), admin dashboards (manage users via database), payment processing (Stripe Checkout), email notifications, mobile apps (responsive web is fine), and infrastructure that scales past 50 users. You need 10 good users, not 10,000 mediocre ones.

How do I find a good MVP development partner?

Look for partners with 3–5 recent MVP shipments, not enterprise resumes. Ask what they would cut from your scope – good partners are aggressive scope cutters. Check delivery pace: 4–6 weeks from kickoff to deployed MVP means they know what they're doing.

When should I not hire an MVP development partner?

When your scope is vague and you haven't defined the hypothesis you're testing. When no-code could do the job. When you have technical co-founders who can ship in six weeks. When you want polish more than speed. Agency MVPs fail when you haven't decided what you're learning.

How do I choose an MVP development partner?

Six criteria: they ask what hypothesis the MVP tests before they quote; they have shipped MVPs in 4–8 weeks at $15K–$75K and can name them; they push scope out rather than in; the people in the pitch are the people who build; they hand over a codebase a second team could take on; and they tell you what they would not build. A partner who quotes above $150K is quoting a product, not an MVP.

What is the difference between an MVP development consultant and an MVP development partner?

A partner builds the MVP – $15K–$75K over 4–8 weeks. A consultant advises on the hypothesis, the scope, and which partner to hire – by the hour ($150–$300 for technologists) or as a two-to-four-week selection engagement – and builds nothing. Worth paying for above roughly $50K of build; not when no-code will do.

Originally published at launchdayadvisors.com. Launch Day Advisors is a buyer-side advisory firm: we help companies select AI, software, and design partners, and we are paid only by the buyer.

MCP App vs MCP Server vs Connector: Definitive Terminology Guide for 2026

Jonathan Blessing — Fri, 18 Sep 2026 13:05:16 +0000

In brief: MCP server is the engineering term – a JSON-RPC 2.0 process exposing tools, resources, and prompts. MCP app is the product term – the user-installable artifact built on top. Connector is what Claude calls an installed MCP app inside its product. Plugin, integration, and skill are inherited or vendor-specific terms that mean different things in different rooms. Use MCP app as your umbrella term, MCP server for engineering, and the host client's preferred word (connector, Custom GPT app, etc.) on that client's surface.

An MCP app is the user-installable product built on top of an MCP server. An MCP server is the running process implementing the Model Context Protocol over JSON-RPC 2.0. A connector is what Claude calls an installed MCP app inside its product. These three terms refer to different layers of the same system, and confusing them is the most common cause of stalled MCP roadmaps in 2026. The Model Context Protocol is just over eighteen months old as of this writing – Anthropic introduced it in November 2024 – and the industry has not yet agreed on what to call the things being built on top of it.

Walk into any product meeting on this topic and you will hear, in roughly this order: MCP server, connector, integration, plugin, app, skill, tool, extension, and increasingly agent used loosely for any of the above. None of these are wrong. Several are technically correct in different layers. But the ambiguity is not free. Roadmaps stall on vocabulary disagreements that look like product disagreements. RFPs go in circles because each side means something different by the same word. Partner kickoff meetings spend the first hour establishing what the product is actually called.

Key Signal

The cost of mixed MCP terminology is paid in calendar weeks. We have watched a fifteen-person product team take six weeks to converge on internal vocabulary for an MCP app they had been building for three months. Vocabulary precedes strategy – companies without shared internal language for the artifact they are building produce inconsistent positioning, fragmented marketing, and confused engineering specs.

This guide lays out the three layers of MCP-powered software, surveys the eight terms in circulation, and proposes a working vocabulary product teams can use until the market settles. The rest of our MCP guide series uses this vocabulary throughout.

The Three Layers of MCP-Powered Software

Most of the confusion resolves once you see that MCP-powered software is at least three distinct objects, and the words people use are referring to different ones.

The first layer is the protocol implementation – the running MCP server. A process, a binary, a hosted endpoint. It implements the MCP spec, exposes a set of capabilities, and speaks the wire protocol the AI client expects. Engineers care about this layer.

The second layer is the capability surface – the set of tools, resources, and prompts the server exposes. create_invoice, search_inventory, book_meeting. This is where product design lives: what the agent can do on the user's behalf, with what parameters, returning what shape of data. Designers care about this layer.

The third layer is the user-installable experience – the artifact a buyer adds to their AI client and calls something. Branding, distribution, monetization, the marketplace listing, the support channel. Marketing and product care about this layer.

MCP server is a layer-one word. Tool, resource, and prompt are layer-two words. Connector, plugin, app, and integration are all layer-three words, competing for the same job: name the thing the user installs.

What MCP is technically

Before going deeper into terminology, it helps to anchor on what MCP actually is at layer one. MCP is a JSON-RPC 2.0–based protocol introduced by Anthropic in November 2024 and open-sourced at modelcontextprotocol.io. An MCP session begins with a capabilities negotiation between client and server, proceeds with the server advertising what it can do via three primitive types, and continues for the duration of the session with the client invoking server operations as the agent decides.

The three MCP primitives are:

Tools – operations the agent can invoke. Each tool has a name, a description (read by the agent at runtime to decide whether to invoke it), and an inputSchema (a JSON Schema specifying parameters).
Resources – data the agent can read. Each resource has a URI, a name, a description, and a MIME type.
Prompts – templated user-facing prompts the server can offer. Used much less widely than tools and resources in practice.

MCP supports three transports: stdio (process-to-process, for local servers), SSE (Server-Sent Events over HTTP), and streamable HTTP (the newer remote transport that consolidated SSE's responsibilities). For remote MCP servers, the spec includes an OAuth 2.1 + PKCE authorization flow with Dynamic Client Registration and authorization-server metadata discovery.

Once the layers are visible, vocabulary arguments resolve into a question of which layer the speaker means. The engineer saying MCP server is not wrong; they are referring to layer one. The marketer saying connector is not wrong; they are referring to layer three through Anthropic's chosen vocabulary. Both can be right; both can also be the wrong word for the room. The discipline is knowing which.

The Eight MCP-Related Terms in Circulation

Eight terms are in active use as of mid-2026, and they refer to different things at different layers of the system.

Term	Layer	Meaning	When to use it
MCP server	Engineering	Process implementing the MCP spec (JSON-RPC 2.0)	Architecture diagrams, technical docs, contracts
MCP app	Product (umbrella)	User-installable artifact built on an MCP server	Roadmaps, investor decks, cross-client positioning
Connector	Product (Claude-specific)	Anthropic's term for an installed MCP app in Claude	Inside Claude marketing and docs
Plugin	Product (legacy)	Inherited from ChatGPT Plugins (2023); pre-MCP framework	Avoid in new copy – implies older, more constrained model
Integration	Product (generic)	Generic enterprise term for cross-system connection	Operationally clear in procurement; loses MCP's autonomy signal
App	Product (multi-vendor)	Used in ChatGPT App Store, Custom GPTs, Claude apps	When the host client uses it
Tool	Capability primitive	Individual operation an MCP server exposes (`create_invoice`)	Engineering docs and product specs
Resource	Capability primitive	Data item an MCP server exposes (a document, a record)	Engineering docs
Prompt	Capability primitive	Templated user-facing prompt the server offers	Engineering docs
Skill	Collided	Claude's separate concept ("Skills") that is not MCP servers	Avoid in mixed-vendor rooms
Extension / add-on	Product (legacy)	Browser-era inheritance; underclaims agent autonomy	Avoid – undersells the product

A short tour of the layer-three terms

The marketing decisions live at layer three, so this is where most of the language churn is felt.

Connector is Anthropic's user-facing term inside Claude. It names the relationship – you connect a thing, then Claude can use it – but other clients do not use it, and copy written entirely in connector reads as Claude-specific the moment it is read on another surface.

App is gaining ground. Custom GPTs are sometimes called apps; Claude has begun using Claude apps for installable connector experiences. App carries the right mental model – something installable, that does a job. The cost is overloading an already-overloaded word.

Plugin is inherited from the ChatGPT Plugins era of 2023. Still in casual use, but it implies an older, more constrained model in which a third party hooks into a host. MCP-powered software is often neither.

Integration is the generic enterprise term. Operationally clear inside procurement; flattens the distinction between MCP and the previous generation of webhook-and-Zapier integrations, which is a feature for fast procurement conversations and a bug for accurate strategic positioning.

Skill is collided with Claude's existing concept of Skills, which are not MCP servers. Avoid in mixed-vendor rooms unless you intend to spend ten minutes disambiguating.

Extension and add-on underclaim the autonomy a modern MCP server has when wired into an agent.

MCP App vs MCP Server: The Critical Distinction

An MCP server is a technical component; an MCP app is a product. The MCP server runs the protocol and exposes primitives (tools, resources, prompts). The MCP app is the marketed, distributed, supported, monetized package a customer installs – including the server, the auth experience, the marketplace listing, the documentation, and the support workflow.

	MCP server	MCP app
Layer	Engineering	Product
What it is	Process implementing MCP (JSON-RPC 2.0)	User-installable product
Exposes	Tools, resources, prompts	A complete buyer experience
Who cares	Engineers, devops	Product, marketing, sales
Where it lives	Hosted endpoint or local binary	Marketplace listing in a host AI client
Used in	Architecture diagrams, technical docs	Roadmaps, investor decks, marketing

One MCP app typically contains one MCP server, but an MCP app can package multiple servers when the product spans concerns (a company might ship an MCP app that installs both a "data" server and a "workflow" server under one product brand).

What about resources and prompts?

Most public discussion of MCP focuses on tools – the operations an agent can invoke. The other two primitives, resources and prompts, are underused in 2026 but worth understanding because they affect how you should think about your MCP app's surface.

Resources let an MCP server expose data the agent can read directly, without invoking a tool. Typical use cases: a knowledge base entry, a document, a database row. For some products – knowledge bases, documentation systems, content-rich CRMs – resources are a more natural fit than tools.

Prompts let an MCP server offer templated prompts users can trigger. A "summarize this ticket" prompt, a "draft response in our voice" prompt. Used in roughly 20% of production MCP apps as of mid-2026; tools are used in close to 100%.

Most product teams designing an MCP app should focus on tools first, resources second (where data exposure matters), and prompts third (where templated workflows matter). The terminology, though, should distinguish them – calling a resource a tool produces design discussions where engineering and product talk past each other.

A Working Vocabulary for Product Teams

After eighteen months of vocabulary churn, the stack we use with clients is the following.

MCP app – the umbrella term for the user-installable, distribution-aware product. Used in roadmaps, investor decks, internal naming, and any context where the thing is being discussed across host clients. MCP app is the word your CEO should be able to say in a board meeting and have everyone in the room understand the same thing.

Connector, app, or whatever the host client uses – the surface term in marketing and documentation, matched to where it appears. Inside Claude documentation: connector. Inside the ChatGPT app store: app. Inside Microsoft AppSource: whatever the AppSource template prescribes.

MCP server – the engineering artifact, used in technical documentation, partner contracts, and architecture diagrams. Not used in customer-facing copy.

Tool / Resource / Prompt – individual capabilities an MCP server exposes, used in product specs and developer docs. Never used in marketing.

The reasoning is that MCP app carries the right strategic weight – this is a product, not a script – without locking you to any single vendor's vocabulary. The host-specific term handles the language match on each client's surface. MCP server stays clean as the engineering term, which is what engineering wants.

Recommended Stack

MCP app for the umbrella term. Host-specific terms (connector inside Claude, app inside the ChatGPT store) on each client's surface. MCP server for the engineering artifact. Tool, resource, and prompt for individual capabilities. Pick a stack now; revisit when the market consolidates. The cost of waiting is paid in calendar weeks of vocabulary disagreement.

The objection worth taking seriously

The objection worth taking seriously is that MCP app overloads app, which already does too much work. True. But every alternative is worse: MCP server is the wrong layer; connector is one vendor's word; integration loses the autonomy signal; plugin is dated; skill is collided; extension and add-on undersell. App is overloaded. The alternatives are wrong. We accept the overload in exchange for the mental model.

Why Vocabulary Costs Calendar Weeks

The cost of mixed terminology is not abstract. Three concrete patterns we have seen on engagements show how the bill is presented.

The RFP that took six weeks to qualify. A buyer issues an RFP for AI integration capabilities. Three vendors respond – one describes their MCP server's tool surface, one describes their Custom GPT app, one describes a Zapier-style integration. The buyer's procurement team cannot compare the responses because the vendors are answering different questions under the same heading. Six weeks of clarification cycles before the actual evaluation can begin.

The investor deck that confused two stages. A series-B startup pitches an MCP server as their flagship product. Investors who track the category interpret this as a developer-infrastructure play (server = infrastructure). The actual product is a user-installable connector for Claude – a layer-three product that happens to ship with a server. Six weeks of follow-up conversations to re-position the narrative; one investor passes citing the confusion.

The partner contract that misallocated work. A company hires a development partner for MCP integration work. The partner scopes the engineering layer (server implementation, JSON-RPC handling, transport selection). The buyer expected the product layer (marketplace listing, distribution, support workflow). The first invoice exposes the gap; the contract is renegotiated mid-engagement at higher cost. A shared, scope-by-scope view of what an MCP server costs to build tends to surface that mismatch before the first invoice.

Common Failure Mode

In all three cases, the loss was not from any party acting in bad faith. It was from the absence of a shared vocabulary that could distinguish what was actually being discussed. The cheapest fix is a one-page vocabulary document circulated before the project starts. The expensive fix is renegotiating the contract or rebuilding the deck six weeks in.

The market will eventually settle. One term will win, the way app won over iPhone application. But if you are building an MCP-powered product in 2026, you cannot wait for that to happen. You need a working vocabulary now – one your engineers, your designers, your sales team, and your partners can all use without translation.

Pick a stack. Document it. Use it consistently. The rest of our MCP guide series uses MCP app as the umbrella term, MCP server for the engineering artifact, and host-client-specific terms (connector, Custom GPT app) where the host surface demands them.

Related Guides

How to Embed Your App in AI Clients with MCP – The full strategic framework for product leaders shipping to leading AI clients
MCP Client Comparison: Claude vs ChatGPT vs Cursor vs Copilot vs Gemini – The eight dimensions that matter when choosing where to ship
MCP Embedding Types Explained: Read-Only vs Actions vs Agent-Resident – Choose the right level for your safety story
MCP Build vs Buy – In-house engineering or development partner, with cost ranges and decision rubric

Frequently Asked Questions

Is an MCP server the same as an MCP app?

No. An MCP server is the engineering artifact – a process implementing the MCP spec via JSON-RPC 2.0. An MCP app is the user-installable product built on top of it, including auth experience, marketplace listing, documentation, and support. One MCP app typically contains one MCP server.

What are the three MCP primitives?

The MCP specification defines three primitive types an MCP server can expose: tools (operations the agent invokes), resources (data the agent reads), and prompts (templated user-facing prompts). Tools are used in nearly all production MCP apps; resources are used where data exposure is central; prompts are used least often.

What protocol does MCP use?

MCP uses JSON-RPC 2.0 as its wire protocol, transported over stdio (for local servers), SSE (Server-Sent Events over HTTP), or streamable HTTP (the consolidated remote transport). Capabilities are negotiated between client and server during session initialization.

Should I use the term connector or MCP app?

Use connector when you are inside Anthropic's vocabulary – Claude documentation, Claude marketing, conversations with Anthropic. Use MCP app as your cross-client umbrella term – roadmaps, investor decks, internal naming. Other host clients use other words; match the host client on the host client's surface.

Is an MCP server a plugin?

No. Plugin is inherited from the ChatGPT Plugins era of 2023 and implies an older, more constrained extension model. MCP-powered software is not a plugin; it is a protocol-based product surface with much broader capability – multiple primitives, capability negotiation, agent-driven invocation. Avoid plugin in current copy.

What is the difference between an MCP tool and an MCP server?

An MCP server is the package; a tool is one operation inside that package. A single MCP server typically exposes many tools – create_ticket, get_customer, list_invoices – alongside resources and prompts. The server is the install unit; the tool is the call unit.

Can I just call my MCP app an AI integration?

You can, but you lose information by doing so. Integration is a generic enterprise word that flattens the distinction between MCP and the previous generation of webhook-and-Zapier integrations. MCP is meaningfully different – agents reason about which tools to invoke based on natural-language context. Calling an MCP app an integration is operationally clear in procurement and strategically vague in positioning.

What's the difference between resources and tools in MCP?

A tool is an operation the agent decides to invoke (create_invoice, search_customers). A resource is a data item the server exposes for the agent to read (a specific document, a customer record). Tools have side effects or computed responses; resources are content. Tools are invoked; resources are referenced.

Originally published at launchdayadvisors.com. Launch Day Advisors is a buyer-side advisory firm: we help companies select AI, software, and design partners, and we are paid only by the buyer.

Should Your App Be in AI Clients? MCP Strategy Decision Framework

Jonathan Blessing — Fri, 18 Sep 2026 13:03:44 +0000

In brief: Most product teams should ship an MCP app to at least one AI client by end of 2026, but the right posture varies. Run three diagnostics: (1) where is your buyer doing the work, (2) what role does your product play in their workflow, (3) what is the cost of being absent? The answers point to one of four postures: ship aggressively to multiple clients, ship narrowly to one strategic client, ship a defensive read-only MCP app, or don't ship and defend the destination. Each posture commits you to a different cost structure (Posture 1: $1.5–3M annual investment; Posture 2: $500K–1M; Posture 3: $200–500K; Posture 4: zero direct cost but compounding distribution risk).

Most product teams should ship an MCP app to at least one AI client by end of 2026, but the right posture varies sharply. The strategic question is not whether MCP matters but what posture you take while it does. There are four reasonable postures, and choosing the right one is more important than choosing whether to ship. The temptation is to skip directly to which client should we ship to – the right order is to figure out the posture first and let the client choice fall out of it. Skipping the posture step is how teams end up with three half-built MCP apps on three different clients and nothing in production.

This is the diagnostic we use with product teams making the call. It assumes the working vocabulary in our MCP terminology guide and the landscape view in our MCP client comparison matrix. Three diagnostic questions; the answers, taken together, point toward one of four postures.

The MCP-App Decision Is a Commitment Decision

The MCP-app decision looks like a build decision. It is, more accurately, a commitment decision. Posture 1 is a commitment to staffing a new distribution surface like a product line. Posture 2 is a commitment to depth on one surface and absence on others. Posture 3 is a commitment to a defensive position requiring discipline to hold. Posture 4 is a commitment to a destination strategy you have to keep earning. Half-staffed work that neither side owns produces nothing that compounds.

Three Diagnostics for Whether to Ship

Diagnostic 1: Where is your buyer doing the work?

Not where they were doing it last year. Not where the CEO of an AI client says they will be doing it next year. Where, today and over the past quarter, has your actual buyer been spending their professional working time?

Three answers are common, and they imply very different MCP postures:

Primarily on a destination they choose. They open a browser and go to your website, your competitor's, or a SaaS tool they bought. The AI client is a tab they sometimes use. Distribution is largely intact.
Inside an AI client as a substitute. They open Claude or ChatGPT instead of opening your tool, ask the agent to do the thing your tool does, and accept whatever quality the agent produces. The AI client is a competitor – your product is being disintermediated, with or without an MCP app.
Inside an AI client as a multiplexer. They are working in Claude or ChatGPT or Cursor as a hub, reaching out to many tools, including yours, to get the job done. The AI client is a distribution channel, and your presence inside it is presence at the surface where the work happens.

Most product teams cannot answer this question precisely because they are not instrumenting the right signal. The signal is not whether your buyer has used Claude this week. The signal is whether tasks that were happening in your product or its category are now happening in an AI client instead.

Concrete signals to instrument

Support ticket pattern shifts. Track whether users are asking can your product also work in Claude/ChatGPT/Cursor. A baseline rate above 5% of inbound support volume is a multiplexer-pattern signal.
Churn exit-interview themes. Track how many former customers cite we use ChatGPT/Claude now in exit interviews. Above 15% is, in our experience, a substitute-pattern signal and a strategic emergency (a practitioner heuristic – calibrate the threshold to your own base rate).
Inbound demand shape. Track the share of new sales conversations where the buyer asks about MCP, AI integrations, or agent compatibility. Above 25% is a strong signal that buyer expectations have shifted.
API usage from non-human consumers. If your existing API has a recognizable bot or agent user-agent footprint, track whether that share is growing.
Search trend for your category + AI client. Track Google Trends or your own SEO data for queries like Claude integration with [your category].

If three or more of these signals are flashing, you are in multiplexer or substitute mode and should be running the rest of this framework with urgency.

Diagnostic 2: What is your product's role in your buyer's workflow?

Three rough roles, with very different MCP implications:

Destination product. A design tool, a writing app, a creative environment, a workspace they live in. Examples: Figma, Linear (for the user living in Linear UI), Notion, Photoshop. Destination products struggle to embed in AI clients without cannibalizing themselves. Right MCP posture is usually narrow and defensive.
Capability product. A scheduling tool, a contract-review service, a document-extraction utility, a vertical data lookup. Examples: Calendly, DocuSign, Apollo, Stripe. Capability products are the natural inhabitants of MCP – the AI client is the new destination, and the capability is invoked from inside it.
System-of-record product. A CRM, an issue tracker, a finance system, an HRIS. Examples: Salesforce, Linear (for the user querying Linear data from Claude), Workday, NetSuite. System-of-record products are necessary participants in any MCP-mediated workflow that touches their domain. Cost of being absent is high.

A product can be more than one of these to different buyer segments. Linear is a destination for the user actively triaging issues; it is a system of record for the user asking Claude what's blocked on the 2.0 launch. Run the diagnostic per segment.

Diagnostic 3: What is the cost of being absent from AI clients?

Four cost categories, ordered by severity:

Negligible. Your buyer is not in that client, would not invoke your tool from there even if it existed.
Soft. Your buyer is in that client occasionally; absence costs you small mindshare, small inbound demand. Estimate: 1–3% of growth headwind annually.
Compounding. Your buyer is in that client routinely, alternative tools are present, and every quarter you are absent the agent is learning to solve the user's problem without you. Estimate: 5–15% of growth headwind annually, accelerating as time passes.
Existential. Your category is being absorbed into the AI client itself. The buyer is not even thinking about your tool anymore. Estimate: 20%+ revenue impact within 24 months.

The shape of this cost varies sharply by category. A workflow-collaboration tool with deep entrenchment can absorb a soft cost for a year. A vertical data provider whose data the agent can synthesize from public sources cannot absorb even a compounding cost without permanent damage. Most teams in compounding think they are in soft – the bias is consistently to underweight the urgency.

The Four Strategic Postures

The diagnostics combine into four postures that capture nearly all reasonable answers in 2026:

Posture	When it applies	What it requires	Example product type
Ship aggressively to multiple clients	Capability or system-of-record product, multiplexer-mode buyer, compounding/existential absence cost	Roadmap-level priority, dedicated team, support for at least 2 clients in first ship	Most B2B SaaS with knowledge-worker buyers
Ship narrowly to one strategic client	Capability or system-of-record product, single dominant client in audience, real but client-specific absence cost	Deep ship to one client; first-class connector; deferred others	Vertical-tool company with concentrated audience
Ship a defensive read-only MCP app	Destination product, moat is the experience, full embedding would cannibalize, complete absence lets agents synthesize from elsewhere	Thin read-only MCP app exposing data only; aggressive destination investment	Creative tools, complex dashboards
Don't ship; defend the destination	Destination product, AI clients are small share of buyer's day, MCP cost exceeds return	Invest in destination; revisit diagnostic in two quarters	Some entrenched destination products (rare)

Posture 1: Ship aggressively to multiple clients

Indicated when you are a capability or system-of-record product, your buyer is in multiplexer mode across two or more AI clients, and the cost of absence is compounding or existential. Most B2B SaaS companies whose buyer is a knowledge worker sit here, and most of them are running it as a side project – which is the visible-from-orbit version of getting this wrong.

Posture 2: Ship narrowly to one strategic client

Indicated when one AI client clearly dominates your buyer's working day, you are a capability or system-of-record product, and absence cost is real but client-specific. Vertical-tool companies whose buyer concentrates in a single AI surface fall here. The temptation to start with two clients is the thing to resist: deep on one beats shallow on two, and shallow on two is what teams ship when they fail to make this call.

Posture 3: Ship a defensive read-only MCP app

Indicated when you are a destination product whose moat is the experience itself, where full embedding would cannibalize but complete absence would let agents synthesize your data from elsewhere. Creative tools, complex dashboards, and experience-led products often sit here. The discipline is staying read-only; the temptation, after the read-only ship works, is to expand into actions and start cannibalizing the destination from inside your own MCP app.

Posture 4: Don't ship; defend the destination

Indicated when your product is a destination, AI clients are a small share of your buyer's day, and the cost of an MCP app exceeds its return. The right move is to invest in the destination and revisit the diagnostic in two quarters. This is the right answer less often than teams hope. Not yet on this question converts to too late faster than it converts to now.

What Each Posture Actually Costs

The annual investment commitment for each posture, including build, maintenance, and supporting work (DevRel, marketing, customer education):

Posture	Year-1 build cost	Year-2+ annual run rate	Headcount equivalent
Posture 1: Aggressive multi-client	$1.5–3M (2–3 clients shipped)	$1–2M (maintenance, expansion, support)	6–10 FTE-equivalent
Posture 2: Narrow strategic	$500K–1M (1 client shipped well)	$300K–600K	2–4 FTE-equivalent
Posture 3: Defensive read-only	$200–500K (lightweight read-only)	$100–300K	1–2 FTE-equivalent
Posture 4: Don't ship	$0 direct	$0 direct, but compounding distribution risk	0

These costs assume hybrid in-house + partner staffing and are heavier toward the partner side in year 1, shifting to in-house in year 2+. The per-app build cost underneath these posture budgets is broken down by scope in what an MCP server costs to build; see MCP build vs buy for the in-house vs partner decision.

The honest accounting: Posture 1 is a meaningful capital allocation. Most teams that need it are running it as a side project at Posture-3 budget, which is the visible-from-orbit version of getting this wrong.

MCP strategy decision tree

A simplified decision tree using the diagnostics:

Is your buyer doing meaningful work inside AI clients today?
├── No → Posture 4 (revisit in 2 quarters)
└── Yes
    │
    └── What is your product's primary role?
        │
        ├── Destination product
        │   └── Will full embedding cannibalize the destination?
        │       ├── Yes → Posture 3 (defensive read-only)
        │       └── No → Posture 2 (narrow strategic ship)
        │
        ├── Capability product
        │   └── Buyer concentrated in one AI client or many?
        │       ├── One → Posture 2 (deep ship to that client)
        │       └── Many → Posture 1 (aggressive multi-client)
        │
        └── System-of-record product
            └── What is the cost of being absent?
                ├── Soft → Posture 2 (narrow strategic)
                └── Compounding/existential → Posture 1 (aggressive multi-client)

This is a simplification; the full diagnostic is richer than the tree suggests. But for a quick first read, the tree gets most teams to within one posture of the right answer.

Sequencing if You Ship

For postures 1 and 2 (the ship postures), the order of operations matters more than teams expect. The compressed sequence:

Pick the one client where you will ship first, even if you intend to support multiple. Optimize the entire first ship for that client's distribution model, auth model, and design idioms.
Choose your embedding depth deliberately using MCP embedding types. Read-only is the right starting point unless you have a high-confidence safety story for actions.
Get the auth design right using MCP auth and security before the first tool definition. Scope shape determines tool shape.
Decide build vs buy using MCP build vs buy before staffing.
Ship narrowly. Instrument heavily. Expand by evidence.

The temptation to abstract across clients from day one produces an MCP app that is mediocre on every surface. Better to be excellent on one and port what works.

Worked Example and the Wrong Reasons to Ship

Worked example: a Series-B SaaS company

To make the framework concrete, a representative example based on patterns we see in client engagements (details abstracted).

Company: A Series-B project-management SaaS with $40M ARR, primarily mid-market and enterprise customers, prosumer + knowledge-worker buyer.

Diagnostic 1 (where is the buyer working?):

18% of new support tickets in Q1 2026 mention Claude or ChatGPT
Churn analysis shows 11% of departing customers cite we just use ChatGPT now
Sales conversations: 31% of new opportunities now ask about MCP support
Inbound demand: API usage from agent user-agents grew 4× in past 6 months

→ Pattern: multiplexer with substitute-mode emerging. Urgency is real.

Diagnostic 2 (product role):

For active users in the UI: destination product
For users querying project status from Claude: system-of-record product

→ Mixed: destination + system-of-record. The system-of-record dimension is the more strategically important for MCP purposes.

Diagnostic 3 (cost of absence):

Buyers spend significant time in Claude and ChatGPT
Competitors have shipped MCP apps in the past 6 months
Agent-led project-status queries are happening today, with the agent often unable to answer because no MCP server is exposed

→ Compounding cost. Without MCP presence in the next 2 quarters, alternatives will fill the gap.

Posture: Aggressive multi-client (Posture 1). Ship to Claude and ChatGPT in year 1, expand to Microsoft Copilot in year 2 (matches the enterprise customer base).

Year-1 commitment: ~$2M, 8 FTE-equivalent across product, engineering, design, partnerships.

Sequencing: Claude first (deepest connector experience, prosumer-strong audience), ChatGPT second (largest raw audience), defer Copilot to year 2 (heavier implementation overhead). Level-2 actions on both, with audit log surface as a parallel track.

Questions to Pressure-Test the Posture

Does the engineering leader and the product leader read the diagnostics the same way? If they disagree, the disagreement is about an underlying assumption (how strategic this is, how fast the team can move) that needs to surface before the build starts. Is the company prepared to staff this like a product line, or like a side project? Posture 1 at side-project budget is the most expensive way to get MCP wrong.

The wrong reasons to ship

Three reasons appear repeatedly and should not survive a serious decision review.

Because everyone else is. MCP-app FOMO is real and currently expensive. The cost of shipping a half-built MCP app to the wrong client to look serious is higher than the cost of waiting one quarter and shipping a real one to the right client.

Because a board member or investor told us to. The strategic question is whose buyer is moving where, not whose investor is excited about which protocol. If diagnostics point to Posture 4, the right answer is Posture 4. Investor pressure to ship anyway is investor pressure to make a worse strategic decision.

Because our competitor shipped one. A competitor's MCP app is evidence that they made a decision; it is not evidence that the decision was correct, and it is not evidence that the same decision is correct for you. Run diagnostics on your buyer, not theirs.

Common Failure Mode

Most product teams that get MCP wrong got it wrong by skipping the framework, picking the easiest client to ship to, and producing something that was neither the aggressive ship of Posture 1 nor the deep ship of Posture 2. The work compounds when it is committed work. Half-staffed work neither side owns produces nothing that compounds and a year of calendar time you do not get back.

Pick the posture. Document the reasoning. Then build. If the strategic question is broader than MCP – questions about which AI investments are worth making at all – our AI strategy consultant guide covers the wider decision frame.

Related Guides

What to Call MCP Apps: Terminology Guide – Working vocabulary
How to Embed Your App in AI Clients with MCP – The full strategic playbook
MCP Client Comparison Matrix – Eight dimensions across leading clients
MCP Embedding Types Explained – Read-only, actions, agent-resident
MCP Build vs Buy – Cost ranges and the in-house vs partner decision
Do You Need an AI Strategy Consultant? – When the strategic question is broader than a single protocol

Frequently Asked Questions

Is MCP worth it for my product?

For most products with knowledge-worker, prosumer, developer, or enterprise-software buyers in 2026, yes. The exceptions are pure destination products with limited AI-client overlap among their buyers. Run the three diagnostics in this guide to get a defensible answer.

How do I know if my buyer is using AI clients?

The signal is not whether they have used an AI client; it is whether tasks that previously happened in your product are now happening in an AI client. Concrete signals to instrument: support tickets mentioning AI clients (>5% is multiplexer-pattern), churn exit interviews citing AI clients (>15% is substitute-pattern), sales conversations asking about MCP (>25% is buyer-expectation shift).

How long do I have to decide?

The window for being early is closing through 2026 and 2027. By 2028, the buyer expectation will be that meaningful B2B software is reachable through MCP, much the way the buyer expectation in 2016 was that meaningful software had a mobile app. Companies that decide in 2026 are deciding from a position of choice; companies that decide in 2028 are deciding from a position of catch-up.

What if I'm wrong about the posture?

Postures are revisitable. The decision is binding for the duration of one ship cycle (one to two quarters), not forever. Ship under Posture 2 with one client, learn, and revisit whether to expand to Posture 1. The wrong move is paralysis.

Should I ship to all AI clients at once?

No. Pick one strategic client and ship there first. The temptation to abstract across clients from day one produces an MCP app that is mediocre on every surface. Excellent on one and port what works is the durable strategy.

How much does an MCP strategy cost?

Posture 1 (aggressive multi-client): $1.5–3M year 1, $1–2M run rate annually. Posture 2 (narrow strategic): $500K–1M year 1, $300–600K annually. Posture 3 (defensive read-only): $200–500K year 1, $100–300K annually. See MCP build vs buy for full line-item breakdowns.

Can my MCP app strategy change as MCP evolves?

Yes, and it should. Revisit the strategy quarterly. The auth models will change, monetization paths will mature, agent-led routing will reshape discovery. A strategy that does not revisit is a strategy that decays.

Is shipping a defensive read-only MCP app the same as not shipping?

No. A defensive read-only MCP app is an active position – you are deciding to give agents access to your data without giving them write capability. Not shipping is a passive position. The defensive read-only ship is meaningful work; the no-ship requires no work but bears different long-term costs.

Originally published at launchdayadvisors.com. Launch Day Advisors is a buyer-side advisory firm: we help companies select AI, software, and design partners, and we are paid only by the buyer.

MCP Embedding Types Explained: Read-Only vs Actions vs Agent-Resident

Jonathan Blessing — Fri, 18 Sep 2026 13:00:44 +0000

In brief: MCP apps embed in AI clients at one of three levels. Read-only exposes data the agent can read but cannot change (lowest risk, fastest to ship; ~1 quarter; $100K–$300K). Actions exposes mutations the agent can execute (create, update, delete, send) – requires idempotency keys, reversibility patterns, intent-preview interfaces, and per-action audit logs (~2 quarters; $300K–$700K). Agent-resident treats the agent as a first-class user of the product, with its own identity, accumulated state, and participation in internal mechanisms – almost no products are at this level (multi-quarter program; $1M+). Most teams should ship read-only first, expand to actions when the safety story is real, and consider agent-resident only when the company is rebuilding around it.

MCP apps embed in AI clients at one of three levels – read-only, actions, or agent-resident – distinguished by what the agent can do with the underlying product. Each level has different security models, design demands, costs, and value to the user. The level you ship at is one of the highest-leverage product calls in an MCP roadmap, and it is routinely made by default rather than deliberately – usually by an engineer reading the spec on a Friday and shipping whatever the docs make easiest.

This guide lays out the three levels, what each one entails, and how to decide which one to ship at. It uses the working vocabulary in our MCP terminology guide.

Match Level to What the Product Can Defend

The level you ship at is not a measure of ambition. It is a measure of what the product can defend, and what the company is committed to becoming. A read-only MCP app says "the agent should know what we know." An actions MCP app says "the agent should be able to act on what we hold." An agent-resident MCP app says "the agent is part of how this product operates." Three different commitments, three different costs, three different futures.

The Three Embedding Levels

Level	What the agent can do	Risk	Time to ship	Typical cost (partner-built)	Best for
Read-only	Query and read data; cannot change anything	Low	~1 quarter	$100K–$300K	First MCP ship; defensive presence; data-rich products
Actions	Read + execute mutations (create, update, delete, send)	Medium	~2 quarters	$300K–$700K	Capability products; system-of-record products with mature safety story
Agent-resident	Operates as a first-class user with identity, state, and internal participation	High	Multi-quarter rebuild	$1M+	Companies whose strategic premise is agent-first

The cost gap between levels is driven less by the server than by the safety surface each one requires: the jump from read-only to actions roughly doubles the build because every write tool needs idempotency, reversibility, and a per-action audit trail. The full breakdown by scope – line items, ongoing costs, and worked examples – is in what an MCP server costs to build.

Read-Only MCP Apps

A read-only MCP app is an MCP app whose tools only query data and never modify it. The agent can answer questions and reason against your system – your customers, your tickets, your inventory, your documents – but cannot change anything inside it.

Concretely, the tools exposed at this level are all queries: search_customers, get_ticket, list_invoices, find_in_knowledge_base. There are no create_, update_, or delete_ verbs. Resources may also be exposed for direct data reads.

Read-only is the lowest-risk, fastest-to-ship version of MCP presence. For some products it is the right ceiling, not a stepping stone – particularly destination products that benefit from exposing their data to agents without rebuilding the destination experience inside the AI client.

Sample read-only tool definition

A representative read-only tool exposes a clear query with informative parameters and citation-friendly response shape:

{
  "name": "search_customers",
  "description": "Search the customer database by name, email, or company. Returns up to 50 matching customers with their basic info. Use when the user asks about a specific customer or wants to find customers matching criteria.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "Search query – name, email address, or company name"
      },
      "limit": {
        "type": "integer",
        "description": "Maximum results to return (1-50)",
        "default": 20,
        "minimum": 1,
        "maximum": 50
      },
      "include_inactive": {
        "type": "boolean",
        "description": "Whether to include inactive/archived customers",
        "default": false
      }
    },
    "required": ["query"]
  }
}

The response should include enough metadata for the agent to cite – record IDs, links to the canonical record in your product, last-updated timestamps. This lets the user verify the answer and click through to the source.

Read-only design problems

Three product problems matter at this level:

Retrieval quality. Are tools well-named so the agent picks the right one? Do they return the right shape of data so the agent does not need three calls when one would do?
Reasoning legibility. Does the data include enough metadata for the agent to cite – record IDs, links to canonical records, timestamps – so the user can verify the answer?
Pagination. Are large result sets paginated in a way the agent can iterate over without confusion? Cursor-based pagination tends to work better than offset-based for agents.

Read-only security

The security story is comparatively simple. The user grants read access at install. The agent reads. Mutations cannot happen by accident because the surface does not allow them. Enterprise procurement teams approve faster for read-only MCP apps.

When to ship at level 1

Ship at level 1 (read-only) when:

Your product holds data the agent benefits from reading
Your buyer's primary unmet need is I want the agent to know what we know
Your safety, audit, or auth story is not yet mature enough to defend writes
You want the fastest path to MCP presence with the lowest procurement friction

Actions-Level MCP Apps

An actions MCP app is an MCP app whose tools include mutations – create, update, delete, and send operations the agent can execute on the user's behalf. The agent can draft and send the email, file the ticket, update the record, schedule the meeting, post the invoice, charge the card.

The tool surface at this level includes both queries and verbs: create_ticket, update_customer, send_invoice, book_meeting. The agent reads to understand what the user wants and writes to do it.

The design demands jump sharply from read-only to actions. Four problems become real product surface that did not exist at level 1.

Idempotency

The agent will retry. Sometimes because the network glitched, sometimes because it second-guessed itself, sometimes because the user said do that again. Write tools must tolerate retries without producing duplicates.

The standard pattern is idempotency keys. The client (the AI client or the agent runtime) generates a unique idempotency key for each logical operation. The server stores recent keys with their results, and repeat calls with the same key return the cached result rather than re-executing.

{
  "name": "send_invoice",
  "description": "Send an invoice to a customer via email. Use when the user wants to bill a customer. Returns the sent invoice ID and a confirmation that it was delivered.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customer_id": { "type": "string", "description": "Customer to invoice" },
      "amount_cents": { "type": "integer", "description": "Amount in cents", "minimum": 1 },
      "currency": { "type": "string", "default": "USD" },
      "idempotency_key": {
        "type": "string",
        "description": "Unique key for this invoice operation. If the same key is provided twice within 24 hours, only one invoice is sent and the original result is returned. The agent should generate a new UUID per logical operation."
      }
    },
    "required": ["customer_id", "amount_cents", "idempotency_key"]
  }
}

Stripe's API is the reference implementation for idempotency keys. The cost of getting idempotency wrong: the user discovers they sent the same invoice three times, or charged the customer twice for one purchase.

Reversibility

Some writes are reversible (update_customer, where the previous state is restorable). Some are not (send_email, charge_card, delete_* without soft-delete).

The product should make reversible writes obviously reversible. Three patterns work:

Soft delete with undo window. delete_customer doesn't actually delete; it marks the record as deleted with a 30-day restoration window. Returns an undo_token the agent can pass to restore_customer if the user changes their mind in the same conversation.
Update with revision history. update_customer writes a new revision, preserving the previous state. The agent can describe what changed and offer to revert.
Two-phase commit for high-stakes operations. prepare_charge returns a token; execute_charge actually runs. The agent must show the prepared charge to the user before calling execute.

Irreversible writes deserve heavier confirmation, both from the agent (are you sure you want to send this?) and from the system (rate limits, two-step confirms for high-stakes operations).

Intent preview

Before the agent executes a write, the user should be able to see and approve what is about to happen. This is partly the host client's job – Claude, Copilot, and the more mature clients have intent-preview UI built in – but it is also yours: tool parameters need to be expressive enough that the preview is informative.

Bad: execute_send_email(payload: {...}). The preview can only say the agent wants to call execute_send_email. The user has no idea what the email contains.

Good: send_email(to: "alice@acme.com", subject: "Re: contract review", body: "Hi Alice, ...", attachments: [...]). The preview shows the user exactly what is about to be sent, and the user can edit before approving.

The principle: parameters should be human-meaningful, not opaque blobs. Pass structured data (recipient, subject, body) rather than serialized payloads.

Audit trail

Every write through the MCP app should be attributable. Per-invocation logs that capture: user identity, host AI client, session identifier, tool invoked, parameters passed, result, timestamp.

Enterprise buyers will require this. Consumer buyers will appreciate it the first time something goes wrong. The audit log should be queryable by the customer's admin, not just by your support team. See MCP auth and security for the customer-facing audit log surface bar.

Common Failure Mode

The most common failure mode in MCP work is shipping delete_* and send_* tools without reversibility or audit, then watching the first incident erode trust faster than the feature earned it. The second-most-common failure is shipping level 2 with the audit log built but not exposed to customer admins – the audit exists technically and not procedurally, which is the worst of both worlds. If you cannot expose the audit log to customer admins on day one, you are not ready for level 2.

When to ship at level 2

Ship at level 2 (actions) when:

The user's job-to-be-done in the AI client requires changing your system, not just reading it
You have built (or are committed to building) idempotency keys, soft-delete or revision-history reversibility, intent-preview-friendly parameter shapes, and per-invocation audit logs
The business value of writes clearly exceeds the cost of doing them properly

Agent-Resident MCP Apps

The deepest level is the one almost no product team is at today, and the few who are have rebuilt themselves around it.

An agent-resident MCP app does not just let the agent invoke tools. It treats the agent as a first-class user of the product, with its own identity, its own audit trail, its own relationships with other entities, and its operation across time. Your product is not being read or written by the agent; it is being inhabited by the agent.

Concretely, the difference between level 2 and level 3 is the difference between exposing create_ticket (a single operation) and exposing a tool surface rich enough that the agent can run an entire support triage workflow – read the ticket, draft a response, escalate to a specialist if needed, mark resolved if it can, follow up tomorrow if it can't, and accumulate context across all of that as a coherent participant in the support queue.

Three structural changes

The agent has its own identity in your system, separate from any human user. There is a row in your users or service_accounts table for the agent.

service_accounts
  id: srv_acct_42
  type: "agent"
  human_principal_user_id: usr_178      // user the agent acts on behalf of
  host_client: "claude.ai"
  permissions_envelope: { ... }
  created_at: 2026-01-15

The agent participates in your product's internal mechanisms – assignments, notifications, escalations, status changes – alongside human users. A ticket can be assigned to an agent. A workflow can be triggered by an agent's action.

tickets
  id: tkt_91
  assigned_to: srv_acct_42       // assigned to an agent
  status: "in_progress"
  agent_metadata: {
    confidence_score: 0.84,
    escalation_threshold: 0.6
  }

The agent accumulates state across sessions. It is not amnesiac between calls. It remembers what it tried last week, who it has been working with, which approaches have worked. This requires a persistent memory store the agent can read and write across sessions, scoped to the agent's identity.

Architectural commitment

Level 3 requires rethinking the product's permission model, identity model, audit model, notification model, and often the underlying data model. It requires designing for an actor that does not have a coffee cup, does not get tired, and is operating in parallel sessions on behalf of multiple users.

When to ship at level 3

Ship at level 3 (agent-resident) when the strategic premise of the company is that agents are a primary user class, not a guest, and the product is being built or rebuilt around that premise. Do not ship at level 3 when the company has not made that strategic commitment – level 3 attempted as a product extension fails, because it requires changes to identity, permissions, audit, notification, and often data models that retrofits cannot supply.

Choosing and Sequencing Levels

Most product teams should ship level 1 first, expand to level 2 when the safety story is mature, and consider level 3 only if the company is rebuilding around an agent-first thesis.

Your situation	Recommended level
First MCP ship, no prior MCP experience	Level 1 (read-only)
Have shipped read-only, ready for writes, have safety infrastructure	Level 2 (actions)
Agent-first startup; product designed for agents from inception	Level 2 or 3 (depending on architectural readiness)
Established product wanting to extend into MCP	Level 1 first; level 2 by quarter three
Destination product with cannibalization risk	Level 1 only; do not expand
System of record with deep agent-mediated workflows in your audience	Level 2 within first year; level 3 only with explicit strategic commitment

Progression versus leap

Most teams should progress: level 1 first, learn, level 2 when ready, level 3 only with strategic commitment. A small minority – usually agent-first startups – should leap directly to level 2 or 3 because the product is being designed for that level from inception.

The progression model is both a defensive strategy and a learning strategy. Read-only MCP apps generate the data – what users actually ask for, where the agent gets stuck, what tools get invoked – that informs actions design. Level 2 generates the safety and audit infrastructure that informs agent-resident design. Skip levels and the next level is built on instinct rather than evidence.

Questions Before Picking a Level

What is the user's job-to-be-done that requires more than reading? If you cannot answer in one sentence, level 1 is correct. What is the worst write the agent can do, and what is the recovery path? If the answer is "we'd lose data" or "we'd send something we cannot take back," level 2 safety infrastructure is non-negotiable. What is your audit story for agent-mediated actions? If you cannot produce a per-action audit log on day one, level 2 is premature. What changes about our product if the agent is a first-class user? If the answer is "very little," you are not at level 3.

The level you ship at is not a measure of ambition. It is a measure of what the product can defend. Most teams' honest answer is level 1 first, level 2 by quarter three, level 3 only if the company is rebuilding around it.

Related Guides

What to Call MCP Apps: Terminology Guide
How to Embed Your App in AI Clients with MCP
MCP Strategy Decision Framework
MCP Auth and Security – Auth design that supports the level you ship at
MCP Build vs Buy – Cost ranges per embedding level

Frequently Asked Questions

What is the difference between read-only and actions in MCP?

Read-only MCP apps expose only query tools (the agent can read data but cannot change it). Actions MCP apps expose query and mutation tools (the agent can create, update, delete, send). Actions require idempotency keys, reversibility patterns (soft delete, revision history, two-phase commit), intent-preview-friendly parameter shapes, and per-action audit logs that read-only does not.

Is read-only MCP enough for most products?

For first ships, almost always yes. Read-only is the right starting point unless the product team has prior MCP experience and a defensible safety story for writes. For some destination products, read-only is the permanent right level, not a stepping stone.

What is agent-resident MCP?

An agent-resident MCP app treats the agent as a first-class user of the product, with its own identity in your data model, accumulated state across sessions, and participation in the product's internal mechanisms (assignments, notifications, escalations). Almost no products are at this level in 2026; those that are have rebuilt around the agent-first thesis.

Can I ship MCP write tools without idempotency?

You can ship them, but you should not. Agents will retry, and write tools without idempotency produce duplicate records, duplicate emails, or duplicate charges – incidents that erode trust faster than the feature earned it. Idempotency keys (UUID-based, with server-side caching of recent results) are non-negotiable for level 2.

What is an idempotency key in an MCP tool?

An idempotency key is a unique identifier the agent passes with each write operation. The server stores recent keys with their results; if the same key is sent twice within a window (typically 24 hours), the server returns the original result rather than re-executing the operation. This makes retries safe and prevents duplicate writes. Stripe's API is the reference implementation.

How do you implement reversibility in MCP write tools?

Three patterns: soft delete with undo window (operations don't immediately destroy data; they mark records and offer restoration tokens), update with revision history (writes preserve previous state and expose a revert path), and two-phase commit (prepare-and-execute for high-stakes operations). Pick the pattern per operation based on blast radius.

How long does it take to ship at each MCP embedding level?

Level 1 (read-only), single client: one quarter ($100K–$300K partner-built). Level 2 (actions), single client: two quarters ($300K–$700K partner-built). Level 3 (agent-resident): multi-quarter, often a multi-year program ($1M+).

Should I skip read-only and go straight to actions?

Most teams should not. Read-only generates the usage data and infrastructure that informs the actions design. Skipping read-only is appropriate only for agent-first startups whose product is designed for level 2+ from inception.

What happens if I ship the wrong embedding level?

Shipping too low leaves user value on the table; shipping too high produces incidents the safety infrastructure cannot defend. The first failure mode (too low) is recoverable in a quarter. The second (too high) can produce trust damage that takes a year to recover from.

Can I have different MCP embedding levels per host client?

Yes, and this is sometimes the right move. Ship level 2 actions on Claude (where per-tool consent and intent-preview UI are mature) and level 1 read-only on Cursor (where per-tool consent is weaker). Match the embedding level to what the host client's safety surface can support.

Originally published at launchdayadvisors.com. Launch Day Advisors is a buyer-side advisory firm: we help companies select AI, software, and design partners, and we are paid only by the buyer.

MCP Build vs Buy: Should You Hire a Development Partner or Build In-House?

Jonathan Blessing — Fri, 18 Sep 2026 12:59:13 +0000

In brief: Build your MCP server in-house if MCP is strategically central, your roadmap coupling is tight, your team has agentic-system experience, or your product is a system of record requiring deep data-model integration. Hire a partner if time-to-ship matters more than ownership depth, your engineering capacity is fully committed, your team has not built for non-human consumers, or your first ship is a learning ship. Partner-built level-1 read-only MCP apps cost ~$100K–$300K; level-2 actions apps cost ~$300K–$700K. In-house equivalents cost 60–80% in raw spend but add headcount and calendar time. The hybrid that consistently works: partner-led first ship with structured knowledge transfer, then in-house for level-2 expansion.

Every product team that takes MCP seriously eventually arrives at the same fork: build it with internal engineering or hire a development partner. The strategic case is settled (the company is shipping an MCP app); the question is how. Build in-house if MCP is strategically central, your roadmap coupling is tight, your team has agentic-system experience, or your product is a system of record. Hire a partner if time-to-ship matters more than ownership depth, your engineering capacity is committed, your team has not built for non-human consumers, or your first ship is a learning ship. The hybrid that consistently works: partner-led first ship with structured knowledge transfer, then in-house for level-2 expansion.

The shape of this decision is not new; companies have made it about mobile apps, integrations, marketing sites, and every other strategic surface where in-house and external delivery both compete. The MCP-specific texture is what changes the answer. The category is young, the work is adjacent to but not the same as previous specialties, and the failure mode of getting the build wrong is delayed by six to nine months – long enough that the team that picked the wrong path is rarely the team that pays for the choice.

This guide is for the product or engineering leader who has crossed the strategic threshold (see the MCP strategy decision framework if you have not) and is now making the build-vs-buy call. For broader AI implementation cost context, see our AI implementation cost guide. For pricing-model selection, see fixed fee vs time and materials.

The Optimistic Estimate Is What Kills In-House Programs

The build-vs-buy conversation is usually distorted by an undersized estimate of the work. A serious MCP app shipped to one client at level-2 (actions) depth is not a two-week sprint and not a single-engineer project. Teams that estimate MCP as a side project routinely discover by month three that they are short two engineers and a designer, and by month six that the first ship will not clear the safety bar that procurement is going to ask about.

What Building an MCP App Actually Involves

A serious MCP app – single client, level-2 (actions) depth – is one to two quarters of work for a properly staffed team. The full scope:

Server implementation – process, hosting, observability, deployment pipeline, built to the MCP spec (JSON-RPC 2.0 over stdio, SSE, or streamable HTTP)
Tool surface design – create_, update_, search_, get_ operations named with the precision of a public API
Auth implementation – OAuth 2.1 + PKCE typically, with Dynamic Client Registration (RFC 7591) and authorization server metadata (RFC 8414); plus alternate paths per target client; scope taxonomy; token lifetime and refresh; revocation flows. See MCP auth and security.
Audit and logging surface – per-invocation logs, parameter capture, session reconstruction, customer-admin-facing log views
Safety story – idempotency keys, reversibility patterns (soft delete, revision history), intent-preview-friendly parameter shapes. See MCP embedding types.
Distribution package – submission to host client's marketplace, store metadata, screenshots, documentation, support workflow
Maintenance commitment – keeping up with host client's spec changes, auth changes, distribution-policy changes, your own evolving tool surface, indefinitely

That list is the work for one client. Each additional client adds variance – different auth, different distribution, different terminology, different review process – typically at 30–60% of the original cost of the first ship, depending on overlap.

When In-House Is Right

In-house wins when one or more of the following is true:

MCP is strategically central to your product over the next three years. A category-defining product treating MCP as a major distribution surface needs the muscle in-house, eventually, regardless of how the first ship goes.
Your roadmap coupling is tight. The MCP app's tool surface evolves week by week with the underlying product, and the cost of cross-team coordination with an external partner exceeds the cost of having the team in your building.
Your engineering team has agentic-system experience. Senior engineers who have built API products for non-human consumers – agents, integrations, automation systems – are the right people for this work. Teams without that experience can develop it, but the first MCP app is an expensive place to learn.
Your product is a system of record (CRM, issue tracker, finance system) where the depth of integration into your own data model is the work, and an external partner's lack of access to that model would be the bottleneck.

The honest cost of in-house: slower in months one through six, expensive in headcount, and a first version that bears the marks of the team's first contact with the category. Real ownership in exchange for a longer, more uneven path.

What an in-house MCP team looks like

A properly staffed in-house team for a level-2 single-client MCP app:

Role	Allocation	What they own
Product manager	50–100%	Posture decision, embedding-level call, tool surface scoping, marketplace submission
Tech lead / architect	50–100%	MCP spec implementation, auth design, audit infrastructure, hosting
Backend engineer (senior)	100% × 2	Tool implementation, server code, OAuth integration
Backend engineer (mid)	100% × 1	Audit log, supporting infrastructure
Designer	25–50%	Tool description quality, intent-preview UX, customer admin UI for audit logs
Security engineer	25–50%	Threat model review, scope taxonomy review, penetration testing coordination
DevOps / SRE	25–50%	Hosting, observability, deployment, on-call rotation
Technical writer	25–50%	Tool descriptions, marketplace listing copy, customer documentation

Roughly 4.5–6 FTE-equivalent for two quarters, plus partial allocations for security and devops. Smaller teams can ship – but most ships from sub-scale teams require rework within twelve months.

The in-house calendar timeline

A representative two-quarter calendar:

Phase	Calendar weeks	Key deliverables
Strategy & scope	Weeks 1–3	Posture documented, target client picked, embedding level set, tool surface scoped
Auth & scope design	Weeks 3–5	OAuth integration designed; scope taxonomy locked; audit log spec written
Server foundation	Weeks 5–9	MCP spec implemented; transport selected; hosting; observability live
Tool implementation, batch 1	Weeks 7–12	First 5–10 read tools shipped to staging; agent invocation tested
Tool implementation, batch 2	Weeks 10–18	Write tools shipped with idempotency, reversibility; intent preview tested
Audit log + customer admin UI	Weeks 14–20	Customer-facing audit log live; tamper-evident storage configured
Marketplace submission & polish	Weeks 18–22	Listing submitted; review iteration; first user installs
Beta + iteration	Weeks 22–26	Closed beta; feedback incorporated; general availability

This is a clean two-quarter run with no major surprises. Real-world timelines slip on auth complexity, host-client review iterations, and audit log requirements; build a 2–3 week buffer.

When a Partner Is Right

A partner wins when one or more of the following is true:

Time-to-ship matters more than ownership depth in the next two quarters. The MCP-app distribution surface is a window; being twelve months later costs you compounding presence in host clients.
Your engineering capacity is fully committed to existing roadmap. Pulling four engineers off existing commitments is more expensive than the partner cost.
Your team has not built for non-human consumers before. The patterns that produce a good MCP app – tool naming, idempotency, intent legibility, audit hygiene – are unfamiliar to teams whose API design has only ever served human-driven clients.
The category is moving fast enough that staying current is meaningful work. A partner whose business is MCP absorbs auth model changes, distribution policy changes, spec additions across many clients; an internal team treats each change as an unplanned project.
Your first ship is a learning ship, and you would rather rent the learning than buy it.

The honest cost of a partner: less ownership of design choices, more coordination overhead at the seams, and transition risk if you eventually want to bring it in-house. The right partner mitigates the first and second; the third is a real cost the contract structure should address up front.

If you go this route, see how to evaluate an MCP build partner for the buyer's checklist that separates real MCP-shipping teams from generalist agencies.

Cost Ranges and Line Items

The rough cost envelopes for partner-built MCP apps in 2026:

Scope	Calendar time	Partner cost (USD)	In-house cost (raw spend)
Level-1 read-only, single client	~1 quarter	$100K–$300K	$80K–$240K
Level-2 actions, single client	~2 quarters	$300K–$700K	$200K–$520K
Level-2 actions, two clients	~2.5–3 quarters	$420K–$1.2M	$300K–$900K
Level-3 agent-resident	Multi-quarter program	$1M+	$700K+

In-house numbers above reflect raw spend (salaries × allocation × calendar time) and exclude opportunity cost of pulled-from-roadmap engineering. Total in-house cost including opportunity cost typically lands close to partner cost. For a dedicated cost breakdown – per-scope ranges, line items, ongoing costs, and three worked examples – see what an MCP server costs to build.

Detailed line items: level-2 partner build

A representative line-item breakdown for a level-2 single-client partner build at the middle of the range ($500K total):

Component	Typical cost (USD)	What it covers
Discovery, design, scope taxonomy	$40K–$80K	Posture review, embedding-level call, scope design, tool surface specification
Server implementation, hosting, observability	$50K–$100K	MCP spec implementation, transport, hosting infra, monitoring
Tool surface (10–25 tools)	$80K–$180K	Implementation, validation, testing, documentation per tool
OAuth implementation, scope design	$60K–$120K	OAuth 2.1 + PKCE + DCR; scope taxonomy; token lifecycle; revocation
Audit log infrastructure + customer-admin surface	$40K–$80K	Per-invocation logging; tamper-evident storage; admin UI
Safety story (idempotency, reversibility, intent preview)	$60K–$120K	Idempotency keys; soft-delete + restore; revision history; two-phase commit
Marketplace submission, distribution polish	$20K–$50K	Listing copy; screenshots; review iteration; documentation
Project management, knowledge transfer, contingency	$40K–$80K	PM overhead; runbooks; pairing engagements; buffer
Total	$390K–$810K

Detailed line items: in-house equivalent

For an in-house build at the same scope:

Component	Typical cost (USD)	Calendar weeks
1 PM @ 75% × 26 weeks	$50K	26
1 Tech lead @ 75% × 26 weeks	$60K	26
2 Senior backend engineers × 26 weeks	$130K	26
1 Mid backend engineer × 20 weeks	$50K	20
Designer @ 30% × 16 weeks	$20K	16
Security engineer @ 30% × 12 weeks	$15K	12
DevOps @ 25% × 16 weeks	$15K	16
Technical writer @ 30% × 8 weeks	$10K	8
Hosting + tooling	$20K	26
Penetration test (third party)	$30K	one-time
Total	~$400K

These payroll numbers assume burdened-cost rates roughly representative of US-based product engineering. Actual numbers shift with team location, seniority mix, and accounting conventions. The point is that the gap between partner and in-house in raw dollars is real but smaller than teams typically assume – the bigger gap is calendar time and opportunity cost.

Hybrid Models and Contract Structure

Three hybrid patterns are common in 2026, and one is worth avoiding.

Pattern 1: Partner-led first ship, in-house second ship

The partner builds the level-1 read-only MCP app (or level-2 actions for the strategic client) and hands off to the internal team for expansion. Works when knowledge transfer is baked into the partner contract and the internal team is shadow-staffed during the first build. Fails when the internal team tries to take ownership of code and decisions they were not part of making.

Required contract elements:

Pairing requirement. Internal engineers paired with partner engineers from week 4 onwards (not just for handoff at the end).
Runbook deliverable. A specific contract line item for runbooks covering deployment, on-call, common incidents, scope updates, host-client review iteration.
Architecture review milestones. Internal architecture review at end of each phase (auth, server, tools, audit), with documented sign-off.
Source code ownership. Code written by partner is owned by client from day one. License terms unambiguous.
Transition support. 60–90 days of post-handoff support included.

Pattern 2: Partner for client breadth, in-house for client depth

Internal team owns the deepest MCP app – usually for the client where buyer concentration is highest – and a partner ports to secondary clients. Right pattern for products with one strategic client and three or four secondary ones; the cost is coordination of design choices across the in-house/partner boundary.

Required contract elements:

Architecture-as-spec deliverable. Internal team writes the architecture spec before partner engagement begins. Partner ports.
Per-client SOWs with consistent scope structure.
Cross-client compatibility requirement. Partner-built clients must follow internal team's tool surface conventions.

Pattern 3: Partner indefinitely

Some companies are honest with themselves that MCP, while strategic, is not the surface where they want to develop deep internal expertise. Defensible when the partner relationship is durable; fragile when partner staffing rotates or the partner exits the category.

Required contract elements:

Long-term retainer ($5K–$25K/month) covering maintenance, host-client spec changes, minor feature work
Key-person clauses – specific named engineers committed; 90+ day rotation notice
Source code ownership – same as Pattern 1
Disengagement protocol – what happens if the partner exits or is acquired; source escrow; transition assistance

The Hybrid That Doesn't Work

Partner for some things, in-house for others, with no documented split and no agreed-on transition trigger. That is not a hybrid; it is two half-staffed teams working around each other, and it consistently produces a first ship that is neither partner-quality nor internally-owned. By month three the team has built half an MCP app, the auth is an MVP, the audit log is a TODO, and the distribution package is a slide. The fix is to make the structure explicit before staffing, not after.

What an MCP partner contract should include

The minimum bar:

Statement of Work with embedded line items matching the cost breakdown above
Acceptance criteria per phase – what does auth design complete mean? What does tool surface implemented mean?
IP ownership. Code is yours. License explicit.
Source code escrow for partners who hold ongoing operational responsibility.
Audit log deliverable – partner is responsible for not only building the audit log but also for surfacing it to customer admins.
Penetration test deliverable – third-party pentest before launch, with remediation included in scope.
Knowledge transfer deliverables – documented runbooks; pairing engagement schedule; architecture review milestones with internal sign-off.
Maintenance terms – what's included; what counts as scope change; rate card.
Disengagement clauses – termination notice; transition assistance; source escrow.
Key-person commitments – named engineers; rotation notice.
Confidentiality – including AI training. Whether the partner can use any artifacts from your engagement to train models or improve their own tools.

The most common contract gaps are knowledge transfer (often soft-pedaled) and audit log surfacing (often left as engineering detail). Both deserve explicit line items.

How Do You Decide Between MCP In-House and Partner?

A short framework that captures most of the answer.

The decision rubric

Score each from 1 (strongly in-house) to 5 (strongly partner):

Roadmap pressure to ship within two quarters. 1 = no pressure, can take six months. 5 = need to ship in ten weeks.
Lack of internal agentic-system experience. 1 = team has shipped multiple agent or integration products. 5 = team has never built for non-human consumers.
Strategic centrality of MCP to the company in three years. 1 = MCP is strategic core. 5 = MCP is a checkbox.
Available internal engineering capacity. 1 = full team can be allocated. 5 = no engineers available.
Number of clients you intend to ship to in year one. 1 = one client only. 5 = four or more.

Score	Recommended path
≤ 2.5	In-house – strategic centrality and team capability favor ownership
2.5 – 3.5	Hybrid – partner-led first ship with structured handoff
≥ 3.5	Partner – speed and capacity constraints favor external delivery

Break-even analysis

A simplified break-even calculation for partner vs in-house at a level-2 single-client engagement:

Partner cost: $500K, 6 months calendar → ship in 6 months
In-house cost: $400K raw spend + opportunity cost (4 engineers × 6 months pulled from existing roadmap) → ship in 7–8 months

If the opportunity cost of those 4 engineers (delayed feature work, missed customer commitments, slowed pipeline) exceeds $100K, partner wins on total cost. For most growth-stage SaaS companies, it does. For more mature companies with slack engineering capacity, in-house wins.

The score is a starting point, not an answer. The real test: do your engineering leader and product leader read the score the same way? If they disagree, the disagreement is about an underlying assumption (how strategic this is, how fast the team can move) that needs to surface before the build starts.

Questions Before You Commit

Have you spoken with three partners and gotten written scopes? Or only seen pitch decks? If you are leaning in-house, do you have the headcount available without pulling from existing roadmap commitments? If you are leaning partner, do you have a defensible answer for what happens at month nine when the partner's team rotates? If any of these answers is "we'll figure it out," the decision is not yet ready to be made.

Where the Wrong Call Shows Up

The wrong move is the one we see most often: deferring the decision, staffing thinly with whoever is available, and producing a first ship that is neither a partner-quality launch nor an internally-owned program. By month three, the team has built half an MCP app. By month six, the company is hiring, or hiring a partner, or both, and the first ship has missed the window the strategy was built around.

The cost of picking the wrong path is real. The cost of failing to pick is larger.

If you are leaning toward in-house, staff for it like a product, not a side project. Designate a product owner. Block a dedicated team for at least two quarters. Build the auth design before the tools.

If you are leaning toward a partner, the next question is which partner. The criteria that separate partners who have shipped real MCP apps from generalist agencies with a fresh interest in the category are concrete. They are the subject of How to evaluate an MCP build partner.

The work compounds either way. Half-staffed work that neither side owns does not.

Related Guides

What to Call MCP Apps: Terminology Guide
How to Embed Your App in AI Clients with MCP
MCP Strategy Decision Framework
MCP Embedding Types: Read-Only vs Actions vs Agent-Resident
MCP Auth and Security
How to Evaluate an MCP Build Partner – Buyer's checklist for partner selection
AI Implementation Cost – Broader AI implementation budget framework
Fixed Fee vs Time and Materials – Pricing-model risk allocation

Frequently Asked Questions

How much does it cost to build an MCP server?

In 2026, partner-built MCP apps typically cost $100K–$300K for a level-1 read-only single-client ship, $300K–$700K for a level-2 actions single-client ship, and roughly 1.4–1.7× the single-client cost for two-client expansion. In-house equivalents run 60–80% of the partner cost in raw spend, with longer calendar time and opportunity cost typically closing the gap.

How long does it take to build an MCP server in-house?

A properly staffed in-house team can ship a level-1 read-only MCP app in one quarter and a level-2 actions MCP app in two quarters (calendar weeks 1–26). Add 1–2 months for teams without prior agentic-system experience. Sub-scale staffing (one engineer, part-time) consistently produces longer timelines and worse first ships.

What roles do I need on an in-house MCP team?

A level-2 single-client MCP build typically needs ~4.5–6 FTE-equivalent: PM (50–100%), tech lead (50–100%), 2 senior backend engineers (100%), 1 mid backend engineer (100% × 5 months), designer (25–50%), security engineer (25–50%), DevOps (25–50%), technical writer (25–50%).

Should I hire an MCP agency or freelancer?

For most product teams, an established MCP agency or development partner is the right choice over individual freelancers. The work spans server implementation, auth design, audit infrastructure, safety story, and distribution – broader than a single freelancer typically covers.

Can I build an MCP server with one engineer?

You can build a prototype, not a production MCP app. A single engineer can produce a working MCP server in a sprint, but the auth, safety, audit, and distribution work that separates a prototype from a shippable product is not single-engineer work.

What's the cheapest way to ship an MCP app?

Level-1 read-only, single client (most often Claude or ChatGPT), 5–10 carefully chosen tools, OAuth 2.1 + PKCE + DCR, basic audit logging. Partner-built, this is the bottom of the cost range ($100K–$150K). In-house with experienced staff, less still – but with longer calendar time.

Should I build for one client first or multiple at once?

One client first. Optimize the entire first ship for that client's distribution model, auth model, and design idioms. The temptation to abstract across clients from day one produces an MCP app that is mediocre on every surface. Better to be excellent on one and port what works.

What if I start in-house and need to switch to a partner?

Workable, but expensive. The cost of mid-build vendor changes is roughly 30–50% rework on the in-progress code, plus a quarter of calendar time to onboard the partner. The fix is to make the build-vs-buy decision before staffing, not after.

What's a fair maintenance commitment for an MCP partner?

Ongoing retainer typically $5K–$25K per month, depending on app complexity and client count. The retainer should cover host-client spec changes, auth model changes, distribution-policy changes, security patches, and minor feature work. Major expansions are scoped separately. Watch for partners whose maintenance retainer covers nothing actionable – that's a red flag.

Is there a break-even point where in-house becomes cheaper than a partner?

Yes, but it depends on opportunity cost. Partner $500K vs in-house $400K raw spend: partner is more expensive in dollars. But if the in-house engineers being pulled have $100K+ of opportunity cost (delayed roadmap, slowed pipeline, customer commitment risk), partner wins on total. For most growth-stage SaaS companies, partner wins on total cost.

Originally published at launchdayadvisors.com. Launch Day Advisors is a buyer-side advisory firm: we help companies select AI, software, and design partners, and we are paid only by the buyer.

How to Embed Your App in AI Clients with MCP: Complete Guide for Product Leaders

Jonathan Blessing — Fri, 18 Sep 2026 12:13:57 +0000

In brief: A growing share of professional software use is happening inside AI clients (Claude, ChatGPT, Cursor, Microsoft Copilot, Gemini) rather than on traditional destinations. MCP is how those clients reach external software – a JSON-RPC 2.0 protocol exposing tools, resources, and prompts. To embed your app: (1) decide which clients matter, (2) choose an embedding depth (read-only, actions, or agent-resident), (3) implement an MCP server with OAuth 2.1 + PKCE auth and audit infrastructure, (4) submit to the host marketplace, (5) optimize for agent-led discovery. Partner-built level-1 read-only MCP apps cost ~$100K–$300K; level-2 actions apps cost ~$300K–$700K.

Embedding your app in an AI client means making your software reachable through the Model Context Protocol so agents inside Claude, ChatGPT, Cursor, Microsoft Copilot, or Gemini can invoke your tools on behalf of users. This is not an integrations ticket – it is a distribution strategy. By mid-2026, a meaningful share of professional software use happens inside AI clients rather than on the destinations the AI is mediating, and the unit of competition has shifted from will the user pick us to will the agent pick us, and will the user trust the result.

For twenty-five years, the unit of distribution for software has been a destination. You built a website, an app, a workspace – somewhere the user could go. Marketing, growth, and product roadmaps were organized around getting the user to that destination and keeping them there. That model is being challenged: a growing share of professional and consumer software use is now happening inside an AI client, with the AI client mediating between the user and the destinations behind it. The user does not go to Linear; the user asks Claude to look at Linear. The user does not open Notion; the user asks ChatGPT to draft against the Notion doc.

This guide is for product leaders deciding whether and how to be present inside leading AI clients via MCP. It assumes the working vocabulary in our MCP terminology guide: an MCP app is the user-installable artifact, an MCP server is the engineering artifact underneath, a tool is an individual capability the server exposes.

Strategic Reframe

Previous-generation integrations connected your software to a destination the user already chose. The user logged into Zapier, picked your app from a list, and your integration ran. MCP-mediated use is structurally different: the user is in the AI client because that is where they are working, and the agent decides mid-task whether to invoke your software. Your competition is not the integrations directory; it is whichever competing MCP app the agent chooses for a given task.

What MCP Is and Why Distribution Is Moving

The Model Context Protocol is an open standard introduced by Anthropic in November 2024. MCP uses JSON-RPC 2.0 as its wire protocol over three transport options (stdio for local servers, SSE and streamable HTTP for remote servers). The protocol defines three primitive types an MCP server can expose: tools (operations the agent invokes), resources (data the agent reads), and prompts (templated user-facing prompts).

By mid-2026, every major AI client supports MCP – Claude, ChatGPT, Cursor, Microsoft Copilot, Gemini, Perplexity. Major model providers have published first-party MCP servers (Anthropic shipped reference servers for Filesystem, GitHub, Slack, Postgres, Brave Search, and Google Maps with the initial launch). Third-party MCP servers exist in production from Linear, Notion, Stripe, Sentry, Cloudflare, Block, and a long tail of B2B SaaS vendors.

This is a structural shift in how software is consumed, comparable in scope to the move from desktop to web (1995–2005) or web to mobile (2008–2015). The companies that treat MCP presence as a mid-priority integrations ticket will, in eighteen months, be looking at competitors whose customers reach for them by default inside Claude or ChatGPT and wondering when that happened.

Three structural consequences

MCP presence is distribution strategy, not an integrations ticket. Every percent of professional task volume that moves into AI clients is a percent of demand that bypasses your website, your funnel, and your existing growth motions. Companies that staff MCP as a side project are staffing one of their emerging distribution channels as a side project.

The design of your MCP app is the design of your product as the agent sees it. The names of your tools, the shape of their parameters, the legibility of your error messages, and the latency of your endpoints all become product surface, because the agent is reading and reasoning over them in real time. Treating MCP as plumbing produces an MCP app that an agent will technically work with and routinely avoid.

The buyer-side decision compounds. Which AI clients to target, in which order, with what depth – these decisions have the same weight as which countries do we sell into or which cloud platform do we deploy on. Pick deliberately, and your distribution compounds. Default to whichever is easiest to ship to, and you spend the next two years rebuilding.

How MCP Embedding Actually Works

When a user installs an MCP app inside an AI client, four things happen technically.

Capability negotiation. The AI client opens an MCP session with your server. Client and server exchange supported protocol versions and capabilities (which features each side supports – tools, resources, prompts, sampling, roots).
Primitive discovery. Your server advertises its tools (with names, descriptions, and JSON Schema input definitions), resources (with URIs, names, MIME types), and prompts. The AI client caches this catalog.
Authorization. The user grants OAuth scopes (or another auth credential) covering the operations the agent can perform on the user's behalf. For remote servers, the MCP spec uses OAuth 2.1 with PKCE, Dynamic Client Registration (RFC 7591), and authorization-server metadata discovery (RFC 8414).
Runtime invocation. During normal use, the client's agent decides – based on the user's request and the tool descriptions – whether and which tools to invoke. The client calls them over JSON-RPC and uses the results in its response.

A representative tool definition

Tools are defined as structured objects with three components: name, description, and inputSchema. The agent reads the description at runtime to decide whether to invoke the tool.

{
  "name": "create_invoice",
  "description": "Create a new invoice for a customer. Use this when the user wants to bill a customer for services rendered. Returns the invoice ID and a URL where the customer can view it.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customer_id": {
        "type": "string",
        "description": "The unique identifier of the customer to invoice"
      },
      "amount_cents": {
        "type": "integer",
        "description": "The invoice total in cents (e.g., 5000 for $50.00)",
        "minimum": 1
      },
      "currency": {
        "type": "string",
        "description": "ISO 4217 currency code",
        "default": "USD"
      },
      "due_date": {
        "type": "string",
        "format": "date",
        "description": "Invoice due date in ISO 8601 format (YYYY-MM-DD)"
      }
    },
    "required": ["customer_id", "amount_cents"]
  }
}

Tool quality compounds. The description above is what an agent reads when deciding whether create_invoice is the right tool for a given user request. Description quality directly affects whether the agent picks your tool over an alternative, how often it invokes it correctly, and how often it asks for confirmation versus proceeding silently.

Choosing Which AI Clients to Ship To

All major AI clients support MCP as of mid-2026, but with significant differences in distribution model, auth, audience, and discovery.

AI client	User-facing term	Distribution	Best for
Claude (Anthropic)	Connector	In-product marketplace	Prosumer + enterprise; first-class buyer experience
ChatGPT (OpenAI)	App	App store	Largest raw audience; consumer + prosumer + Teams
Cursor + AI-first IDEs	MCP server	Manual install, community catalogs	Developer-tools companies
Microsoft Copilot	Agent / Copilot extension	IT-admin distribution	Enterprise with Microsoft 365 footprint
Gemini (Google)	Connector / extension	Workspace marketplace	Workspace-heavy audiences
Perplexity	Connector	In-product, lightweight	Research and retrieval-flow tools

For the deep comparison – including auth models, permissions granularity, and monetization paths – see our MCP client comparison matrix.

Most product teams should not ship to all of them

The temptation is to abstract across clients from day one. The result is an MCP app that is mediocre on every surface. Better to be excellent on one client and port what works.

Quick decision guide:

Prosumer or knowledge-worker buyers → ship to Claude first
Mass-market or consumer buyers → ship to ChatGPT first
Developer-tools or AI-engineering buyers → ship to Cursor first
Enterprise software buyers, especially Microsoft 365 customers → ship to Copilot first
Workspace-heavy or Google-account-centric buyers → ship to Gemini first
Research, retrieval, or vertical-data products → ship to Perplexity first

The four common postures – ship aggressively to multiple clients, ship narrowly to one, ship a defensive read-only app, or don't ship – are walked in detail in our MCP strategy decision framework.

Building an MCP App: Steps, Timeline, Cost

Building a production-quality MCP app for one client at level-2 (actions) depth typically takes one to two quarters with the right team.

The ten-step build sequence

Define your terminology using the MCP terminology guide.
Pick the strategic posture and target client using the MCP strategy decision framework.
Choose the embedding depth – read-only, actions, or agent-resident. Most teams start with read-only. See MCP embedding types.
Design the auth model. OAuth 2.1 with PKCE is the right default for spec-compliant clients. Build the scope taxonomy before defining tools. See MCP auth and security.
Design the tool surface. Tool names, descriptions, parameters, error responses. Treat tool definitions with the same discipline as a public API.
Implement the MCP server to the spec (JSON-RPC 2.0 over your chosen transport). Deploy with proper observability and audit logging from day one.
Build the safety infrastructure. For level-2: idempotency keys, reversibility, intent preview, audit trail.
Submit to the host client's marketplace.
Optimize for discovery through tool naming and description quality, early reviews, verified-publisher status, featured-slot positioning.
Plan ongoing maintenance. Spec changes, auth model changes, distribution-policy changes, and your evolving tool surface require continuous attention.

Where the calendar time actually goes

A representative two-quarter calendar for a level-2 single-client MCP app:

Phase	Calendar weeks	Key deliverables
Strategy & scope	Weeks 1–3	Posture documented, target client picked, embedding level set, tool surface scoped
Auth & scope design	Weeks 3–5	OAuth integration designed; scope taxonomy locked; audit log spec written
Server foundation	Weeks 5–9	MCP spec implemented; transport selected; hosting; observability live
Tool implementation, batch 1 (read tools)	Weeks 7–12	First 5–10 read tools shipped to staging; agent invocation tested
Tool implementation, batch 2 (write tools)	Weeks 10–18	Write tools shipped with idempotency, reversibility; intent preview tested
Audit log + customer admin UI	Weeks 14–20	Customer-facing audit log live; tamper-evident storage configured
Marketplace submission & polish	Weeks 18–22	Listing submitted; review iteration; first user installs
Beta + iteration	Weeks 22–26	Closed beta; feedback incorporated; general availability

Cost ranges in 2026

In 2026, partner-built MCP apps typically cost as follows:

Scope	Calendar time	Partner cost (USD)
Level-1 read-only, single client	~1 quarter	$100K–$300K
Level-2 actions, single client	~2 quarters	$300K–$700K
Level-2 actions, two clients	~2.5–3 quarters	~1.4–1.7× single-client cost
Level-3 agent-resident	Multi-quarter program	$1M+

In-house equivalents are typically 60–80% of the partner cost in raw spend, but with longer calendar time and the headcount cost of pulling engineers off other work. For a dedicated cost breakdown by scope – line items, ongoing costs, and worked examples – see what it costs to build an MCP server. For the full build-vs-buy decision rubric, see MCP build vs buy. For broader context on AI implementation budgets, see our AI implementation cost guide.

Auth, Discovery, and the Three Risks That Ambush Teams

Auth is product strategy

Nothing erodes adoption of an MCP app faster than a sloppy auth story. Enterprise buyers will not install an MCP app whose permissions model they cannot explain to their security team. Each leading AI client implements auth differently: Claude leans on OAuth 2.1 + PKCE with per-tool consent, ChatGPT mixes OAuth and API key flows, Microsoft Copilot delegates to Entra ID, Gemini to Google's OAuth surface.

The full breakdown is in MCP auth and security. The point worth keeping here is strategic: auth and scopes are not a developer problem – they are a product problem. The scope a user grants on day one shapes what the agent will do on day thirty.

Discovery has four levers

Submitting an MCP app to a marketplace is the floor; getting agents to actually pick yours when there are five competing options is the ceiling.

Marketplace search. Conventional store-listing optimization applies.
Featured slots. Editorial placements curated by the host client. Reserved for high-quality apps with established usage and reviews.
Agent-led routing. The agent itself recommending an MCP app mid-conversation. Tool naming and description quality are the primary inputs.
External catalogs and review sites. Third-party "Yelp for MCP apps" directories are emerging but too immature to recommend specific vendors as of mid-2026.

The most leveraged discovery work in 2026 is tool description quality – it directly affects agent-led routing, which is the discovery channel growing fastest.

The three risks that ambush teams

Risks That Show Up Repeatedly

Brand-on-agent risk: users experience your product through the agent's voice, pacing, and mistakes. When the agent invokes your tools incorrectly, users blame the host product. Support-surface risk: users in an AI client experiencing problems with your MCP app rarely come to your support channel – they ask the agent. Versioning and breakage risk: your tool definitions are now an API consumed by external agents, with the added complication that agents cannot file bug reports. Plan for all three before launch, not after the first incident.

Where to Start in 2026

The compressed sequence for product teams new to MCP:

Define your vocabulary using the MCP terminology guide. Pick a term – MCP app is our recommendation – and use it consistently.
Decide which clients matter using the strategy decision framework. Resist the urge to ship to all of them.
Choose your embedding depth using the embedding types breakdown. Read-only is the right starting point unless you have a high-confidence safety story for actions.
Get the auth story right before the first tool definition. See MCP auth and security.
Decide build vs buy using MCP build vs buy. If with a partner, use the partner evaluation checklist.
Ship narrowly. Instrument heavily. Expand by evidence.

Questions to Ask Yourself

Where is your buyer doing the work today – your destination, an AI client as substitute, or an AI client as multiplexer? What is your product's role in their workflow – destination, capability, or system of record? What is the cost of being absent from AI clients – negligible, soft, compounding, or existential? Honest answers to these three diagnostics determine the right posture and the right pace.

Most product teams that get MCP wrong got it wrong by skipping the framework, picking the easiest client to ship to, and producing something that was neither the aggressive ship of a strategic commitment nor the deep ship of a focused one.

Embedding via MCP is not a feature. It is a recognition that the surface where your software is consumed is moving – toward agents, toward AI clients, toward a distribution layer most product teams' growth playbooks were not built for. The companies that decide MCP is distribution, and staff it that way, will be the ones distributed through. The companies that decide it is plumbing will be the ones routed around.

Related Guides

What to Call MCP Apps: Terminology Guide – The working vocabulary stack for product teams
MCP Client Comparison Matrix – Eight dimensions of difference across Claude, ChatGPT, Cursor, Copilot, Gemini, Perplexity
MCP Strategy Decision Framework – Three diagnostics, four postures, and how to commit
MCP Embedding Types Explained – Read-only, actions, agent-resident
MCP Auth and Security – OAuth 2.1, scopes, audit logs, enterprise readiness
MCP Build vs Buy – In-house engineering or development partner
How to Evaluate an MCP Build Partner – Buyer's checklist for a young category
How to Choose an AI Development Partner – The broader AI partner-evaluation framework

Frequently Asked Questions

What is MCP in simple terms?

MCP (Model Context Protocol) is an open standard that lets AI clients (Claude, ChatGPT, Cursor, etc.) connect to external software and use its capabilities on behalf of users. It uses JSON-RPC 2.0 as its wire protocol, defines three primitive types (tools, resources, prompts), and was introduced by Anthropic in November 2024.

Do I need to build an MCP app to be present in AI clients?

For most product teams whose audience uses AI clients regularly, yes. Without an MCP app, your software is invisible to agents inside those clients, and tasks that previously brought users to your product increasingly happen without it. Some destination products with low AI-client overlap among their buyers can defer this; most cannot.

Can I have one MCP app that works across all AI clients?

The MCP protocol itself is standardized, so the underlying server can be largely reused across clients. But each client has its own auth model, distribution mechanism, terminology, and metadata standards. A serious cross-client MCP app implements one MCP server and ports the auth, distribution, and marketing layer per client. Expect 30–60% additional work per added client.

How is MCP different from a Zapier integration or webhook?

Zapier and webhooks are user-configured connections – the user explicitly sets up a trigger or action in advance. MCP is agent-mediated – the agent decides at runtime, based on the user's stated goal, whether and how to invoke your software's capabilities. Schema descriptions are read by the model in real time; the user is not configuring a workflow ahead of time.

What's the smallest viable MCP app I can ship?

A level-1 read-only MCP app exposing 3–5 well-named query tools to a single host client. This can be built in 6–8 weeks with the right team and is the right starting point for most product teams without prior MCP experience. Server, OAuth, basic logging, marketplace submission – that's the floor.

Is it too late to ship an MCP app in 2026?

No. The category is past the earliest-adopter phase, but the maturity of host-client distribution, agent-led routing, and buyer awareness is still developing. Shipping a quality MCP app in 2026 puts you ahead of the broad market and well-positioned for compounding distribution as agent-mediated software use grows.

What happens if I don't ship an MCP app?

Four patterns: negligible impact (your buyers do not use AI clients), soft impact (occasional missed mindshare), compounding impact (alternatives fill the gap and agents learn to route around you), or existential impact (your category gets absorbed into AI clients themselves). The right diagnosis depends on your specific buyer and category.

Which AI client should I ship to first?

Whichever client your buyer uses most. For prosumer and knowledge-worker audiences, Claude is the strongest first ship. For consumer-facing products, ChatGPT. For developer tools, Cursor and the AI-first IDEs. For enterprise software with Microsoft 365 footprint, Copilot.

What MCP servers are already in production?

As of mid-2026, public production MCP servers include first-party offerings from Anthropic (Filesystem, GitHub, Slack, Postgres, Brave Search, Google Maps, Memory, Puppeteer) and third-party servers from Linear, Notion, Stripe, Sentry, Cloudflare, Block, Apollo, and a long tail of B2B SaaS vendors.

What transport should my MCP server use?

For local servers (running on the user's machine alongside the AI client), use stdio. For remote/hosted servers (the typical SaaS pattern), use streamable HTTP – the consolidated remote transport that has largely replaced SSE for new builds since 2025. SSE is still supported but should not be chosen for new servers.

Originally published at launchdayadvisors.com. Launch Day Advisors is a buyer-side advisory firm: we help companies select AI, software, and design partners, and we are paid only by the buyer.

How to Evaluate an MCP Development Partner: Buyer's Checklist for 2026

Jonathan Blessing — Fri, 18 Sep 2026 12:12:26 +0000

In brief: The usual partner-evaluation signals (portfolio depth, named-client logos, polished case studies) are unreliable in MCP because the category is too young for any partner to have a deep portfolio. Replace them with four signal categories: production references (not case studies), specific embedding-level experience (not generic AI experience), actual artifacts from previous engagements (auth designs, tool definitions, audit logs), and a partner with a defended view rather than just execution capacity. Run a structured evaluation: written brief → screening calls → technical deep-dive → reference calls → written proposals → decision review. Disqualify any partner who cannot produce a current production reference, has no documented auth/audit artifacts, or offers execution without an opinion.

The signals product teams normally use to evaluate a build partner – portfolio depth, named-client logos, polished case studies, years of category experience – are unreliable in MCP because the category is too young for any partner to have a deep portfolio. Replace them with four signal categories: production references (not case studies), specific embedding-level experience (not generic AI experience), actual artifacts from previous engagements (auth designs, tool definitions, audit logs), and a partner with a defended view rather than just execution capacity. Run a structured evaluation: written brief, screening calls, technical deep-dive, reference calls, written proposals, decision review. Disqualify any partner who cannot produce a current production reference, has no documented auth/audit artifacts, or offers execution without an opinion.

This is the structural problem of evaluating in a young category: the marketing surface and the actual capability are unusually decoupled. Two partners can have similar websites, similar logos, and similar pitch decks, and one of them has shipped three production MCP apps to enterprise customers and the other has built an internal demo. Distinguishing them takes a different kind of evaluation than the one most procurement processes are built for.

This guide is for product leaders running that evaluation. It assumes you have already made the build-vs-buy decision in favor of a partner (MCP build vs buy) and uses the working vocabulary in our MCP terminology guide. For broader context on technology partner evaluation methodology, see how to evaluate a technology partner and our framework for reference checks for technology partners. The patterns for AI partner evaluation specifically are in our guide to selecting an AI development partner.

The Cost of the Wrong Choice

The cost of the wrong partner choice is not a contract write-off; it is a year of compounded delay during the window when MCP presence matters most. A poorly-built MCP app passes initial review and breaks in production over the following quarter – auth tokens silently expire, mutations are not idempotent, the audit story falls apart the first time a customer asks for a log. Six months in, the buyer is rebuilding while still paying for the original.

Why MCP Partner Evaluation Is Different

Three things make MCP partner evaluation different from evaluating, say, a generalist agency for a marketing site or a typical mobile-app build:

Experience is concentrated in a small number of teams, hidden by a much larger number of agencies who have updated their websites to claim MCP capability. In our assessment, fewer than fifty teams globally have shipped multiple production MCP apps to paying customers as of mid-2026 – a practitioner estimate, not a published statistic. The count of agencies whose website mentions MCP is in the thousands. The signal-to-noise ratio of the marketing surface is unusually bad.
The work is adjacent to but not the same as previous specialties. Teams with strong API-design backgrounds can ship adequate MCP apps without prior MCP experience; teams with strong full-stack agency backgrounds, no API experience, and a couple of weeks of MCP demo work can produce something that looks shippable in a pitch and breaks in production.
The failure mode is delayed. A poorly-built MCP app passes initial review and breaks in production over the following quarter. Six months in, the buyer is rebuilding while still paying for the original.

A more rigorous evaluation up front pays for itself many times over. The rigor takes a different shape than mature-category evaluation. You are not looking for the partner with the most MCP-shaped marketing. You are looking for the partner with the most MCP-shaped artifacts – production references, real auth designs from previous engagements, actual tool definitions, working audit-log examples – and you are looking past the partners who can talk about MCP and toward the partners who can show you what they have shipped.

The Four Signals That Actually Work

In place of the usual portfolio-and-logos checklist, four signal categories matter when the category is young.

Signal 1: Production references, not case studies

A case study is a document the partner controls. A production reference is a customer the partner introduces you to, who is currently using an MCP app the partner shipped, and who will talk to you for thirty minutes about what worked and what did not.

Ask for the latter. The single most valuable thirty minutes of an MCP partner evaluation is a reference call with a current customer. The single most predictive failure signal is a partner who hedges on whether such a call can happen.

Signal 2: Specific embedding-level experience

A partner who has shipped three level-1 read-only MCP apps and never shipped a level-2 actions app is not the right partner for your level-2 build. The discontinuity between read-only and actions is large – idempotency, reversibility, audit, intent preview – and previous experience at the higher level matters more than total count of apps.

Ask specifically: How many MCP apps have you shipped to production, on which clients, at what embedding level? The honest answer for most partners in 2026 is one to three. A partner who answers many without a list, or we have AI experience without naming MCP-specific projects, has not shipped what they are claiming.

If you are shipping at level 2, the partner should have shipped at level 2. If you are shipping to multiple clients, cross-client experience matters – Claude experience does not transfer to Microsoft Copilot's enterprise model without real cost.

Signal 3: Artifacts, not pitches

The most diagnostic step in a partner evaluation is asking to see actual artifacts from a previous engagement. Three artifacts are particularly informative:

The auth design from a previous engagement. Not the marketing pitch – the actual design. Scope taxonomy, token lifetime decisions, refresh behavior, revocation flow, the SOC 2 considerations baked in. A partner who can talk fluently about why they chose per-resource per-verb scopes for a previous client has done the work. (See MCP auth and security for the bar.)
The tool surface from a previous build – actual tool definitions, names, descriptions, parameter shapes, error responses for a real production MCP app. Read them. Look at description quality, parameter naming, error legibility.
The audit and observability defaults. What does the partner instrument out of the box? Per-invocation logs? Customer-admin-facing log surface? Session reconstruction?

These three artifacts are diagnostic because they cannot be faked in a pitch deck.

Signal 4: A view, not just execution capacity

The strongest partners have an opinionated view on the work; the weakest have execution capacity but no point of view.

A partner with a view will tell you which embedding level you should ship at, based on the diagnostics in our strategy decision framework, and will defend the recommendation. A partner without a view will offer to build whatever you specify and will charge you to discover during the build that what you specified was not the right thing.

Ask: What would you do differently from the brief we sent? A partner who answers nothing, that brief is great is offering execution. A partner who pushes back on something specific – embedding level, client choice, auth approach – is offering partnership. The latter is rarer and worth more.

Sample Brief and Screening Questions

Sample MCP partner evaluation brief

A working template for the written brief shared with three to five partners at the start of the evaluation. Keep it under 4 pages; partners who cannot scope from this should disqualify themselves.

SUBJECT: MCP Partner Evaluation – [Your Company Name]

ABOUT US
- Company: [name, ARR, customer base, one-paragraph product description]
- Audience: [primary buyer persona; segments]
- Existing tech stack: [key infrastructure relevant to MCP work]

THE OPPORTUNITY
- Strategic posture: [Posture 1/2/3 from MCP strategy framework]
- Why we're shipping: [the specific buyer signal driving urgency]
- What success looks like: [first-year goals in measurable terms]

SCOPE
- Target client(s): [Claude / ChatGPT / Cursor / Copilot / Gemini / Perplexity, in priority order]
- Embedding level: [read-only / actions / agent-resident]
- Tool surface (rough): [estimated tool count; key resources/operations]
- Auth model: [OAuth 2.1 + PKCE expected; SSO required for enterprise]
- Audit / observability requirements: [SOC 2, HIPAA, customer-facing audit log, etc.]

TIMELINE
- Strategy & scope: [target weeks]
- Build: [target weeks]
- Beta + GA: [target weeks]
- Hard constraints: [any non-negotiable dates]

ENGAGEMENT MODEL
- Build-only / build + maintenance / build + transition to in-house
- Knowledge transfer expectations: [pairing? runbooks? architecture review?]
- Maintenance retainer expected: [yes/no; range]

EVALUATION CRITERIA
- We will evaluate proposals against the criteria in the attached scorecard
- We expect a written proposal with scope, sequencing, knowledge transfer model,
  maintenance commitment, and pricing structure
- We will conduct reference calls with one production customer per finalist
- Final decision: [target date]

QUESTIONS
- Please direct questions to [contact, email]
- Proposal due: [date]

This brief is a screening tool by itself. Partners who respond with a generic deck rather than a scoped proposal disqualify themselves. Partners who respond with thoughtful clarifying questions move forward.

Screening call questions

A complete first-round screening call works through these in roughly 60 minutes.

Track record (10 minutes):

How many MCP apps have you shipped to production, on which clients, at what embedding level? Look for: a list with names, dates, and URLs. Vague answers disqualify.
Of those, which is the most recent? When did it ship? When was its last meaningful update? Look for: shipped within last 12 months; ongoing maintenance.
Can I talk to a current customer using an MCP app you shipped, ideally at the embedding level we need? Look for: yes, with a name and timeframe.
What's the longest-running MCP app you've shipped, and what does maintenance look like for it? Look for: a real story with concrete details about spec changes, auth changes, scope reviews.

Technical depth (20 minutes):

Can you walk me through the auth design from a previous engagement, in detail? Look for: per-resource per-verb per-sensitivity scope structure; OAuth 2.1 + PKCE + DCR; thoughtful token lifetime decisions.
Can I see actual tool definitions from a previous build? Look for: well-named tools, clear descriptions, well-shaped parameter schemas.
What does your audit and observability default look like? Look for: built-in, not afterthought.
How do you handle host-client spec changes mid-engagement? Look for: built into retainer, not surprise scope changes.
What's your idempotency pattern for write tools? Look for: idempotency keys, server-side caching, Stripe-style discipline.
What's your reversibility pattern for high-stakes operations? Look for: soft-delete with restore tokens, two-phase commit for irreversibles, revision history.

Process and engagement (15 minutes):

What does discovery and design look like before any code is written? Look for: 2–3 weeks of strategy + scope work; documented deliverables before build phase.
How do you structure knowledge transfer for in-house takeover? Look for: pairing engagements, runbook deliverables, architecture review milestones.
What's your maintenance commitment after launch? Look for: written terms, clear coverage.
What's your typical timeline for level-1 / level-2 / multi-client engagements? Look for: realistic numbers (1 quarter / 2 quarters / 2.5–3 quarters).

Commercial (10 minutes):

What's your pricing structure (fixed-fee, T&M, retainer, milestone-based)?
What's typically out of scope in your fixed-fee engagements? Look for: clear answer; "very little" is a flag.
How do you handle scope changes? Look for: written change-order process.
What's your IP and source-code ownership stance? Look for: client owns code; explicit license; source escrow if applicable.

Strategic (5 minutes):

What would you do differently from the brief we sent? Look for: specific pushback, not "great brief".
Which embedding level would you recommend for our situation, and why? Look for: defended recommendation, not deference.
What's the most common reason engagements like ours go wrong? Look for: lessons from real engagements.

Reference call question script

When you reach reference calls, conduct them yourself, not via the partner. Thirty minutes per reference.

1. How did you find [partner]?
2. What was the scope of the engagement?
3. How did the partner handle the strategy/scope phase?
   Did they push back on your initial brief? Where?
4. What changed between the proposal and the actual delivery?
5. What was the first incident in production? How did the partner handle it?
6. How was the auth design? Has it held up?
7. How was the audit story? Has it been sufficient when issues came up?
8. What's maintenance been like since launch?
9. If you were doing it again, would you hire [partner]?
   What would you do differently in the engagement?
10. What's something the partner did well that you didn't expect?
11. What's something the partner did poorly that surprised you?
12. Anything we should know that we wouldn't think to ask?

The signals to listen for: specifics (vs generalities), proactive disclosure of issues (vs glossing), comfort answering question 11 honestly (vs deflection).

The 100-Point Scorecard

A scorecard you can apply to candidate proposals. Score each finalist; the highest score is not necessarily the best partner (judgment matters), but a finalist scoring below 65 should not be selected.

Category	Weight	Sub-criteria	Max
Track record	25	Production MCP apps shipped (10), specific embedding-level match (10), production reference call available (5)	25
Technical depth	30	Auth design artifact reviewed (10), tool definition artifact reviewed (10), audit/observability default (5), idempotency/reversibility patterns demonstrated (5)	30
Process & engagement	20	Discovery/design phase before build (5), knowledge transfer model (5), maintenance terms clear (5), realistic timeline (5)	20
Commercial	10	Clear pricing structure (3), explicit IP ownership (3), change-order process (2), maintenance retainer terms (2)	10
Strategic view	15	Pushed back on the brief substantively (5), defended an embedding-level recommendation (5), articulated common failure modes from experience (5)	15
Total			100

Score interpretation:

85–100: strong partner; proceed with confidence
70–84: acceptable partner; document specific concerns and address in contract
65–69: marginal; pursue only if no stronger alternatives and you can mitigate weak areas
<65: do not select

If multiple partners score 80+, the tiebreakers worth weighing are: reference customer signal (a great reference adds weight), strategic-view depth (the partner who pushed back hardest on your brief usually delivers the best engagement), and commercial alignment (the partner whose pricing structure matches your cost-management preferences).

Red Flags, Process, and Contract Terms

Five disqualifiers

Five signals strong enough to drop a partner regardless of the rest of the evaluation:

No production reference call available. If the partner cannot put you in front of a paying customer, the experience claim is unsupported.
No documented auth or audit artifacts. Partners who treat auth and audit as engineering details to be figured out during the build are starting too late.
No view on which embedding level you should ship at. A partner who says we'll build whatever you specify is offering execution, not partnership.
Single-client experience masquerading as MCP expertise. A team that has built three Claude connectors and never touched another client's MCP surface is a Claude partner, not an MCP partner. Fine if Claude is the only client you care about, ever. Not fine if you intend to expand.
Aggressive on timeline, vague on safety. Partners who promise four-week ships at level 2 without articulating idempotency, reversibility, and audit work are either underestimating or planning to skip. Both disqualifying.

How to run the process

A defensible evaluation takes four to six weeks and follows six steps:

Written brief (Week 1) – shared with three to five partners
First-round screening calls (Weeks 1–2) – 60 minutes each, anchored on the question list above
Technical deep-dive (Weeks 2–3) – with the surviving two or three; review actual artifacts; engineering lead in the room
Reference calls (Weeks 3–4) – conducted directly, not via the partner; one production customer per partner; thirty minutes each
Written proposals (Weeks 4–5) – from each finalist, with scope, sequencing, knowledge transfer, maintenance, and pricing all explicit
Decision review (Weeks 5–6) – with internal stakeholders including engineering, security, and the eventual product owner

Questions That Reveal True Capability

Beyond the screening list, three questions consistently surface real capability gaps. "What's the most recent MCP-spec change you absorbed mid-engagement, and how did you handle it?" "What's a scope decision you made on a previous project that you'd reverse with hindsight?" "Walk me through how you'd handle a customer's security team asking for proof of revocation latency in production." Partners with real experience answer these with specifics. Partners with thin experience deflect or generalize.

Required contract terms

The minimum bar for a defensible MCP partner contract:

Statement of Work with line-itemed scope matching the MCP server cost breakdown and the build-vs-buy framing in MCP build vs buy
Acceptance criteria per phase – what does auth design complete mean? What does tool surface implemented mean?
IP ownership – code is yours, license explicit
Source code escrow for partners who hold ongoing operational responsibility
Audit log deliverable – partner builds and surfaces it to customer admins
Penetration test deliverable – third-party pentest before launch, with remediation in scope
Knowledge transfer deliverables – runbooks, pairing schedule, architecture review milestones with internal sign-off
Maintenance terms – what's included; what counts as scope change; rate card
Disengagement clauses – termination notice, transition assistance, source escrow
Key-person commitments – named engineers, rotation notice
Confidentiality – including AI training. Whether the partner can use any artifacts from your engagement to train models or improve their own tools

The most common contract gaps are knowledge transfer (often soft-pedaled) and audit log surfacing (often left as engineering detail). Both deserve explicit line items.

When to bring in an outside advisor

For most product teams, this evaluation is doable internally with the framework above. Bring in an outside advisor if:

Your company has not run a build-partner evaluation in this category before
The strategic stakes are high enough that an additional set of experienced eyes is worth the cost
The internal team is too close to existing partner relationships to evaluate them on their merits
The buyer wants the diligence documented for procurement, board, or audit purposes

We do this work regularly, both as the primary evaluator and as a second-opinion review on a partner the team has already chosen. Typical engagement: 4–6 weeks, $40K–$100K depending on scope and number of finalists.

Why This Evaluation Matters More Now Than Later

The MCP build-partner market will mature. In two years, evaluating partners will look more like evaluating mobile-app shops in 2014 – a settled craft, a known set of credible firms, an unambiguous portfolio standard. The asymmetry between marketing surface and actual capability will close. Production reference checks will be a formality rather than a diagnostic.

We are not there yet. The next eighteen months are the period in which signal-to-noise ratio of partner marketing is at its worst, the cost of getting the choice wrong is at its highest, and the rigor of a serious evaluation has the most leverage. The teams that get this right are the ones that treat partner evaluation as a real procurement exercise rather than a vendor-shopping exercise.

The MCP app you ship is the product surface your customers will see for the next five years. It is shaped, more than anyone wants to admit, by the partner you picked at the beginning. Pick deliberately. Document the reasoning. Hold the partner to the artifacts they showed you in the proposal.

Related Guides

What to Call MCP Apps: Terminology Guide
How to Embed Your App in AI Clients with MCP
MCP Build vs Buy – The decision before partner selection
How to Choose an AI Development Partner – The broader AI partner-evaluation framework
How to Evaluate a Technology Partner – Cross-category partner evaluation methodology
Reference Checks for Technology Partners: A Structured Methodology – Deeper reference-check framework

Frequently Asked Questions

How long does an MCP partner evaluation take?

A defensible evaluation takes four to six weeks: one week for the written brief, one to two weeks for screening calls, one to two weeks for technical deep-dive and reference calls, and one week for proposals and decision review.

How many MCP partners should I evaluate?

Three to five for the written brief; two or three through the technical deep-dive; finalists submit written proposals. Fewer than three risks no real comparison; more than five becomes process overhead without proportional decision-quality benefit.

What's the most important question to ask an MCP development partner?

Can I talk to a paying customer currently using an MCP app you shipped? The answer (and how the partner handles the answer) tells you more than any other single question. Production reference availability is the strongest single signal in the evaluation.

How do I know if an MCP partner has real experience?

Three tests: production reference calls, specific embedding-level experience (not generic AI experience), and actual artifacts from previous engagements (auth designs, tool definitions, audit logs). Marketing claims, case studies, and pitch decks are unreliable in this category.

What should be in an MCP partner proposal?

Six elements: scope (specific tools, embedding level, target client), sequencing (week-by-week or sprint-by-sprint plan), knowledge transfer model (if you intend in-house takeover), maintenance commitment (post-launch), pricing structure (fixed-fee vs T&M vs retainer), and an articulated point of view on what you should do differently from the brief.

How much should I pay an MCP development partner?

Partner-built level-1 read-only MCP apps typically run $100K–$300K for a single client; level-2 actions apps run $300K–$700K. The cost varies with auth complexity, tool surface size, and underlying product complexity.

Should I hire an MCP agency or a freelancer?

For most production-quality MCP apps, an established MCP agency or development partner is the right choice. Freelancers can work for narrow scopes (one tool surface, no auth complexity) but rarely have the breadth across server, auth, audit, safety, and distribution that a production MCP app requires.

What if all my partner candidates fail the disqualifiers?

Two paths: extend the search to less obvious candidates (boutique product engineering firms with strong API-design backgrounds, sometimes labeled differently than 'MCP partner'), or reconsider the build-vs-buy decision. Failing the disqualifier list across multiple candidates is a signal that the category is not yet mature enough for your specific need; in-house may be the better answer.

How do I score MCP partner proposals?

Use the 100-point scorecard: track record (25), technical depth (30), process (20), commercial (10), strategic view (15). Finalists below 65 should not be selected; above 85 is strong; 70–84 is workable with documented mitigations.

What contract terms most often cause regret post-engagement?

Two: vague knowledge-transfer deliverables (the partner did the work, your team can't take it over) and audit-log-not-surfaced (the partner built the log internally, your customers' admins can't query it). Both should be explicit, scoped, and acceptance-criteria'd in the contract.

Originally published at launchdayadvisors.com. Launch Day Advisors is a buyer-side advisory firm: we help companies select AI, software, and design partners, and we are paid only by the buyer.

MCP Auth and Security: OAuth, Scopes, and Enterprise Permissions Guide

Jonathan Blessing — Fri, 18 Sep 2026 12:09:09 +0000

In brief: MCP apps use one of three auth patterns: OAuth 2.1 with PKCE (mandated by the MCP spec for remote servers, used by Claude, Gemini, modern ChatGPT), API key handoff (common in Cursor and AI-first IDEs, weak on revocation and scoping), and enterprise SSO via the host's identity provider (Microsoft Copilot delegates to Entra ID; Gemini to Google OAuth). The MCP spec mandates Dynamic Client Registration (RFC 7591) and authorization server metadata discovery (RFC 8414). For enterprise readiness: OAuth 2.1 + PKCE, scopes structured per-resource and per-verb and per-sensitivity, bounded token lifetimes (≤1 hour) with transparent refresh and immediate revocation, customer-facing audit logs, and SSO support for Entra ID, Okta, and Google Workspace.

The fastest way to lose an enterprise procurement conversation about an MCP app is to lose the auth conversation. Security teams have spent a decade getting good at evaluating OAuth implementations, scope design, and audit posture in third-party SaaS, and they apply the same lens to MCP – with the added question of how a non-human agent's behavior is bounded inside the granted permissions. A sloppy auth story is read, correctly, as a sloppy product. A clean one is the floor that lets the rest of the conversation happen.

The MCP specification mandates OAuth 2.1 with PKCE for remote servers, plus Dynamic Client Registration (RFC 7591) and Authorization Server Metadata (RFC 8414). The spec recommends Resource Indicators (RFC 8707) to prevent token-confusion attacks. For enterprise readiness, scopes should be structured per-resource, per-verb, per-sensitivity, with bounded token lifetimes, immediate revocation, customer-facing audit logs, and SSO support for the major identity providers. This guide walks each piece of that bar in detail.

This guide assumes the working vocabulary in our MCP terminology guide and the level distinctions in MCP embedding types.

Auth Design Is Product Strategy

Auth design is not engineering plumbing. It determines who can install you (which clients accept your auth model), what an agent can do at runtime (coarse vs fine scopes), and how procurement reacts (whether the design maps onto reviewers' existing OAuth review checklists). Treat it as a product decision; let engineering execute the design rather than choose it.

The Three MCP Auth Patterns

Three auth patterns dominate in 2026:

Pattern	Where it's used	Strengths	Weaknesses
OAuth 2.1 with PKCE + DCR	Claude, Gemini, modern ChatGPT install paths	Cleanest model; per-tool consent possible; bounded token lifetimes; clean revocation; spec-compliant	Heavier to implement than API key
API key handoff	Cursor and AI-first IDEs; lightweight integrations	Cheap to implement; fast first-ship	Weak revocation; weak per-tool scoping; insufficient for enterprise; not spec-compliant for remote servers
Enterprise SSO via host IdP	Microsoft Copilot (Entra ID); Gemini (Google OAuth); Claude enterprise (SAML/SCIM)	Strongest procurement story; admin-controlled distribution; existing enterprise IT mental model	Heaviest implementation; per-client identity provider integration

A serious MCP app shipping to multiple AI clients implements at least two of these, and probably all three. There is no shortcut. The cost of pretending one auth model fits all clients is shipping to fewer of them than your strategy intended.

OAuth 2.1 + PKCE + DCR Flow

OAuth 2.1 with PKCE (Proof Key for Code Exchange) is the auth pattern mandated by the MCP spec for remote servers. The user is taken through a standard OAuth flow inside the AI client, grants scopes, and the client receives an access token plus a refresh token bound to the user. PKCE protects the public-client flow against authorization code interception attacks.

The full flow

Discovery. AI client fetches your /.well-known/oauth-authorization-server metadata document (RFC 8414) to discover the authorization endpoint, token endpoint, supported scopes, supported grant types, and registration endpoint.
Dynamic Client Registration. AI client POSTs to your registration endpoint (RFC 7591) to register itself, providing redirect URIs and other metadata. Your authorization server returns a client_id and (for confidential clients) a client_secret.
Authorization request. AI client generates a PKCE code verifier and challenge, then redirects the user to your authorization endpoint with response_type=code, code_challenge, code_challenge_method=S256, and the requested scopes.
User consent. User authenticates with your service and grants the requested scopes. Your service redirects back to the AI client's redirect URI with an authorization code.
Token exchange. AI client POSTs the authorization code (plus the PKCE code verifier) to your token endpoint. You verify the PKCE challenge and return an access token, refresh token, and (optionally) an ID token.
Resource indicator binding. The access token is bound to your MCP server's resource indicator (RFC 8707), preventing replay against other MCP servers.
Tool invocation. AI client uses the access token in the Authorization: Bearer ... header on JSON-RPC requests to your MCP server.
Refresh. When the access token expires, AI client uses the refresh token to obtain a new one.

OAuth 2.1 + PKCE + DCR is the right default for any MCP app shipping to spec-compliant clients (Claude, Gemini, modern ChatGPT). For enterprise tier on Claude or for Microsoft Copilot, you additionally need to support SAML and SCIM.

Per-client variation

Each AI client implements auth differently, with the standing caveat that any specific claim should be verified against current documentation:

Client	Primary auth	DCR	RFC 8414	Scope granularity	Notable
Claude	OAuth 2.1 + PKCE	Yes (mandatory)	Yes	Per-tool consent at install; per-action confirmation	Strongest spec compliance; enterprise tier adds SAML/SCIM
ChatGPT	OAuth or API key	Partial	Partial	App-level; per-tool on newer builds	Verify install path before designing scopes
Cursor + IDEs	API key dominant; OAuth on remote	Limited	Limited	Permissive; per-server consent	Mature OAuth here is a differentiator
Microsoft Copilot	Entra ID	N/A (Entra)	N/A	Admin-granted org-level	Heaviest implementation; strongest procurement story
Gemini	Google OAuth	N/A (Google)	N/A	Google's standard scope model	Familiar to enterprise IT

The practical implication: an MCP app shipping to Claude needs full DCR + RFC 8414 metadata support from day one. A multi-client MCP app needs all three patterns from day one. Greenfielding for a single auth model is fast and is also the most common reason teams cannot ship to client number two without a substantial rebuild six months later.

Scope Design: Per-Resource, Per-Verb, Per-Sensitivity

The most common scope mistake is the binary scope: access your data. This is what API-key-era integrations defaulted to, and it is what enterprise procurement now reflexively pushes back on. The fault lines that produce a defensible scope taxonomy:

Per-resource, not per-app. A scope for read tickets is different from a scope for read customers. Granting both should be a deliberate choice, not a side effect of installing the connector.
Per-verb within resource. Within a resource, separate read from write. tickets:read and tickets:write should be distinct scopes; the user should be able to grant one without the other.
Per-sensitivity within verb. Some writes are higher-stakes than others. tickets:write (create and update) should be distinct from tickets:delete. customers:write should be distinct from customers:export. Anything that exfiltrates data or causes irreversible state change deserves its own scope.

Sample scope taxonomy: a CRM MCP app

A representative scope structure for a mid-complexity B2B SaaS MCP app:

# Customer scopes
crm:customers:read
crm:customers:write
crm:customers:delete
crm:customers:export
crm:customers:merge          // irreversible

# Deal scopes
crm:deals:read
crm:deals:write
crm:deals:delete
crm:deals:export
crm:deals:close              // mark won/lost; high-stakes

# Contact scopes
crm:contacts:read
crm:contacts:write
crm:contacts:delete
crm:contacts:export
crm:contacts:bulk_email      // rate-limited; high-stakes

# Note scopes (low-sensitivity attached records)
crm:notes:read
crm:notes:write

# Configuration scopes (admin-level)
crm:settings:read
crm:settings:write           // org-level; admin-only

# Billing scopes (highest sensitivity)
crm:billing:read
crm:billing:write

The taxonomy reflects that delete, export, merge, close, bulk_email, and settings:write are higher-blast-radius than the routine read/write scopes. Procurement teams reviewing this scope list can immediately see what is at stake and which scopes need additional admin approval.

The cost of fine-grained scopes is install-time UX (longer consent screens, more questions). The benefit is two-fold: enterprise procurement moves faster because the scopes map onto reviewers' existing mental models, and the blast radius of any individual mistake is smaller. Most products should err toward fine.

Tokens, Audit, and Revocation

Token lifetimes

Short-lived access tokens (1 hour or less) with refresh tokens are the right default. Permanent tokens are a procurement red flag.

Token type	Recommended lifetime
Access token (routine scopes)	30–60 minutes
Access token (high-sensitivity scopes)	15 minutes
Refresh token	30–90 days
Re-consent prompt cadence	90 days for high-stakes scopes

Refresh should be transparent to the agent and visible to the user. Silent refresh that never surfaces to the user is acceptable for short windows; refresh that extends access indefinitely without re-prompting is not.

JWT vs opaque tokens

Opaque access tokens are the safer default for most MCP apps. Opaque tokens require a database lookup on every request, which gives you immediate revocation – the moment you delete the token from your store, requests using it fail. JWTs are stateless (operationally appealing) but cannot be revoked before they expire without a separate revocation list, which negates most of the JWT advantage.

If you use JWTs, recommended claims include sub (user ID), aud (your MCP server resource indicator), iss (your authorization server), exp (expiration), iat (issued at), client_id (the AI client), scope (granted scopes), and session_id (for cross-call session reconstruction).

Revocation

Three actors must be able to revoke MCP app access at any time:

The user can revoke through the AI client's connector or app management UI
The admin (for enterprise installs) can revoke through their identity provider or admin console
Your service can revoke through your own admin tools

Revocation must be effective immediately, not at next token rotation. Many MCP apps have a stated revocation path that, when exercised, leaves stale tokens working for hours. Test this. The gap between policy and practice is the gap that matters when an incident is live.

Audit log requirements

Every action the agent takes through your MCP app should be auditable. The minimum bar:

User identity (which user the agent is acting on behalf of)
Service account / agent identity (if applicable, especially at level 3)
Host AI client (which client's agent invoked the tool)
Session identifier (so a sequence of calls can be reconstructed)
Tool invoked (which capability was called)
Parameters passed (with what arguments – possibly sanitized for sensitive data)
Result (success, failure, error message)
Timestamp (with sub-second precision)
Source IP and user agent (for forensics)
Scope used (which OAuth scope authorized this call)

The reason this matters is procedural rather than technical. When something goes wrong – and at least once a year, for any MCP app touching real data, it will – the question what did the agent do is a customer-facing, sometimes legally meaningful question. A team that can answer it in five minutes from a query against the audit log keeps the customer. A team that says we'd have to reconstruct from individual logs, give us a few days loses them.

Common Failure Mode

Audit logs have become the highest-leverage feature for enterprise close rates we have observed in MCP apps shipped over the past year. The most common failure pattern at level 2 is a team that built the log internally and never exposed it to customer admins – the audit exists technically and not procedurally, which is worse than not having it because it produces false confidence. Build the log on day one. Surface it to the customer's admin console, even minimally, by month three.

For SOC 2 Type II–compliant environments, the audit log additionally needs tamper-evident storage (append-only log; cryptographic hashing or chained hashing across entries), retention aligned with customer's data retention requirements (typically 1–7 years), and access controls on the log itself.

SOC 2 mapping

MCP apps shipping into enterprise commonly need SOC 2 Type II attestation. The mapping of MCP-specific security work to SOC 2 trust services criteria:

SOC 2 Criterion	What it requires	MCP-specific evidence
CC6.1 Logical access controls	Restrict access to information and IT systems	OAuth scopes; per-tool consent; revocation procedures
CC6.2 New users, periodic review	Onboard/offboard with appropriate access	Token lifecycle; consent re-prompts; revocation logs
CC6.3 Access provisioning	Grant access based on role	Scope taxonomy; admin-vs-user scope distinctions
CC6.6 Encrypted transmission	Encrypt data in transit	TLS for all MCP transport; bearer tokens in HTTPS only
CC6.7 Restrict transmission of information	Restrict data movement to authorized parties	Resource indicators; scope-based data access
CC7.2 System monitoring	Monitor for security events	Audit log; anomaly detection on tool invocation patterns
CC7.3 Incident response	Detect and respond to incidents	Revocation procedures; audit forensics; communication plan

For most MCP apps the auth and audit work above maps cleanly onto SOC 2 controls. The work to add for SOC 2 compliance specifically is the documentation, evidence collection, and audit by a third-party assessor – typically 6–9 months and $50K–$150K for first-time SOC 2 Type II attestation. That attestation is part of the true cost of shipping to enterprise clients; auth complexity is one of the five drivers in what an MCP server costs to build.

Threat Model and Enterprise Readiness

Threat model

A working threat model for MCP apps shipping in 2026:

Threat	Likelihood	Mitigation
Token theft via AI client compromise	Low–medium	Short-lived access tokens; immediate revocation; bind tokens to client_id and resource indicator
Scope sprawl (user grants too much at install)	High	Fine-grained scopes; clear consent UI; per-tool consent where supported
Confused-deputy attack	Medium	Treat agent inputs as untrusted; validate parameters server-side; never trust the agent's framing of user intent
Prompt injection causing unintended tool invocation	Medium–high	Intent-preview UI; high-stakes scopes require user confirmation per-action; rate limits
Replay attack (token replayed against different MCP server)	Low–medium	RFC 8707 Resource Indicators; bind tokens to specific MCP server identity
OAuth client impersonation	Low	Strict redirect URI validation; PKCE; verify client_id matches registered client
Audit log gap	High	Per-invocation logging from day one; expose to customer admins; tamper-evident storage
Stale revocation (revoked tokens still working)	High	Test revocation latency; use opaque tokens; if JWTs, maintain revocation list
Privilege escalation via scope inheritance	Medium	No scope inheritance; explicit grants per scope; admin scopes require step-up auth

The two threats most often missed in initial designs are the confused-deputy attack and prompt injection. Both arise from the agent acting on parameters or framing it received from an untrusted source. Server-side validation of every parameter – not trusting the agent's interpretation of intent – is the primary defense.

Enterprise readiness checklist

If you are selling into enterprise, the auth and security shape of your MCP app needs to clear this bar before procurement begins, not during it:

OAuth 2.1 with PKCE as a primary auth path
Dynamic Client Registration (RFC 7591) supported
Authorization Server Metadata (RFC 8414) discovery document published
Resource Indicators (RFC 8707) used to bind tokens to MCP server identity
Scope taxonomy is per-resource, per-verb, per-sensitivity
Sensitivity axis genuinely separates high-blast-radius operations from routine ones
Token lifetimes are bounded (access tokens ≤1 hour)
Refresh is transparent to the user; silent windows are short
Re-consent prompts run on a defined cadence for high-stakes scopes
Revocation is effective immediately (and tested)
Audit logging captures user, client, session, tool, parameters, result, scope, IP, user-agent
Customer-admin-facing audit log surface exists in your product
Audit log uses tamper-evident storage (append-only, cryptographic chaining)
SSO via Entra ID, Okta, and Google Workspace is supported (at minimum)
SAML 2.0 supported
SCIM provisioning supported
SOC 2 Type II or equivalent third-party attestation is current
Documented incident response process for compromise scenarios
Penetration test report from the past 12 months available under NDA

The two items teams routinely think they have and don't are the customer-facing audit log surface and the SCIM provisioning. Both are pre-procurement work, not post-. Both consistently get pushed past the first ship and consistently delay the first enterprise close by a quarter.

Pre-Procurement Diligence Questions

If a customer's security team asks you these questions and you cannot answer with documented evidence, you have work to do before procurement. Walk through your auth design. Show the scope taxonomy. Demonstrate revocation latency end-to-end. Pull a sample audit log entry. Demonstrate the customer-admin audit surface. Walk through your SOC 2 control mapping. Each of these is a question security teams know how to ask in their sleep – and treating any of them as "we'll figure that out after we close the deal" is how the deal stops closing.

Common MCP Auth Mistakes

Three patterns recur in MCP auth implementations that teams later regret:

Auth retrofit. Shipping on API keys to move fast, then retrofitting OAuth when enterprise demand materializes. The retrofit is painful, breaks existing installs, and consumes a quarter of feature work. Fix: design for OAuth from day one even if the first ship uses API keys.
Scope sprawl. Shipping with one or two scopes, adding tools quickly, never re-examining the scope structure. Eighteen months in, the MCP app has fifty tools and three scopes. Fix: scope review every quarter, with new tools mapped to the right scope deliberately.
Auth-as-blocker. Treating auth as a blocker to ship, deferring to engineering, ending up with a design that constrains future choices. Fix: treat auth as a first-class design problem owned by product.

Two additional mistakes worth naming:

Skipping Resource Indicators. RFC 8707 Resource Indicators bind tokens to a specific MCP server identity, preventing replay against other servers. Many early MCP implementations skipped this. The cost is a class of token-confusion attacks that are easy to mitigate but hard to recover from after a compromise.
Audit log without admin UI. Building the audit log internally but not exposing it to customer admins. The log exists technically; procedurally it is invisible to the buyer's security team.

Auth and security choices interact tightly with embedding depth (MCP embedding types) and the build-vs-buy decision (MCP build vs buy). Get the auth right and the rest of the work has somewhere to land.

Related Guides

Frequently Asked Questions

Does MCP use OAuth?

Yes – the MCP specification mandates OAuth 2.1 with PKCE for remote MCP servers, plus Dynamic Client Registration (RFC 7591) and Authorization Server Metadata (RFC 8414). API keys are still common in local-server contexts (Cursor, AI-first IDEs) but are not spec-compliant for remote MCP servers in 2026.

What scopes should my MCP app request?

Request scopes per-resource, per-verb, per-sensitivity. A CRM MCP app should have separate scopes for customers:read, customers:write, customers:delete, customers:export, and customers:merge rather than a single crm:access scope. Fine-grained scopes are slower at install but faster through procurement.

Is MCP HIPAA / SOC 2 compliant?

The MCP protocol itself is not certified for any compliance regime; certification applies to your MCP app's implementation. To meet HIPAA, SOC 2, GDPR, or other regimes, your MCP app's auth, audit, encryption, and data handling must meet the regime's requirements. Most enterprise-grade MCP apps in 2026 hold SOC 2 Type II.

Can I use API keys for my MCP app?

You can, but only for clients that support API key install (primarily Cursor and AI-first IDEs running local servers). API keys are not spec-compliant for remote MCP servers and are insufficient for enterprise procurement. For OAuth-supporting clients with remote-server requirements, OAuth 2.1 + PKCE + DCR is the right choice.

What is Dynamic Client Registration in MCP?

Dynamic Client Registration (RFC 7591) is the OAuth feature that lets an AI client register itself with your authorization server programmatically, rather than requiring you to manually provision a client_id for each AI client. The MCP spec mandates DCR for spec-compliant remote servers. Without DCR, you cannot ship a generally-installable MCP app to clients like Claude that expect spec compliance.

How do I revoke access to my MCP app?

Three revocation paths must work: user-initiated (through the AI client's connector management), admin-initiated (through the customer's identity provider for enterprise installs), and service-initiated (through your own admin tools). All three should be effective immediately; verify this works in practice.

What is per-tool consent in MCP?

Per-tool consent is a UX pattern where, at install, the user sees a list of the specific tools the MCP app exposes (create_ticket, delete_customer, etc.) and can grant or deny access to individual tools. Claude has the strongest per-tool consent UX in 2026; other clients are less granular.

How often should MCP tokens be refreshed?

Access tokens should expire within 30–60 minutes (15 minutes for high-sensitivity scopes); refresh tokens within 30–90 days. Re-consent prompts every 90 days are appropriate for high-stakes scopes; lower-stakes scopes can run longer between re-consents.

Does MCP work with SSO?

Yes, for clients that support enterprise SSO. Microsoft Copilot delegates to Entra ID; Gemini to Google OAuth; Claude's enterprise tier supports SAML and SCIM. Enterprise MCP app sales typically require SSO support for the major IdPs.

Should I use JWTs or opaque tokens?

Opaque tokens are the safer default for most MCP apps because they support immediate revocation. Use JWTs only when token lifetimes are very short (≤5 minutes) or when you have a specific high-throughput need and have built a JWT revocation list.

What is RFC 8707 (Resource Indicators) in MCP?

Resource Indicators is an OAuth extension that binds a token to a specific resource – in MCP's case, your MCP server's identity. Without resource indicators, a token issued for one MCP server could be replayed against another, causing a token-confusion attack. The MCP spec recommends RFC 8707; spec-compliant clients enforce it.

Originally published at launchdayadvisors.com. Launch Day Advisors is a buyer-side advisory firm: we help companies select AI, software, and design partners, and we are paid only by the buyer.

MCP Client Comparison: Claude vs ChatGPT vs Cursor vs Copilot vs Gemini

Jonathan Blessing — Fri, 18 Sep 2026 12:07:29 +0000

In brief: All major AI clients support MCP as of mid-2026, but they differ sharply in distribution model, auth, audience, and discovery. Claude is the strongest first ship for prosumer and knowledge-worker audiences. ChatGPT has the largest raw audience and the most mature app store. Cursor is the right surface for developer-tools companies. Microsoft Copilot wins for enterprise software with a Microsoft 365 footprint. Gemini matters for Workspace-heavy audiences. Perplexity is narrow and research-focused. The full matrix below covers eight dimensions per client and includes per-client gotchas, transport support, and realistic time-to-first-install.

All major AI clients support MCP as of mid-2026 – Claude, ChatGPT, Cursor, Microsoft Copilot, Gemini, Perplexity – but they differ sharply in distribution model, auth pattern, audience, and discovery. The protocol itself is standardized (JSON-RPC 2.0, three primitives, three transports), but two clients that both support MCP can still be radically different distribution channels. Choosing where to ship first is one of the highest-leverage product decisions in an MCP roadmap, and the matrices most product teams build for themselves stop at "which clients support MCP." That is not the question that moves the decision.

This guide compares the six clients that account for the bulk of professional MCP-mediated use across the eight dimensions that consistently matter. It uses the working vocabulary in our MCP terminology guide: an MCP app is the user-installable artifact, an MCP server is the engineering artifact underneath, a tool is a single capability the server exposes.

Snapshot, Not Forecast

Last verified: May 2026. The MCP client landscape moves faster than this page can be updated; we re-verify quarterly. If you are about to make a meaningful product investment based on what is below, confirm specifics with each vendor. The dimensions most likely to shift between updates are monetization (no client has a mature paid-app pathway yet) and agent-led routing (the discovery channel growing fastest).

Which AI Clients Support MCP in 2026

All major AI clients support MCP as of mid-2026. Long-tail vertical AI clients (legal, medical, sales-specific) are adopting at varying rates. The protocol itself is standardized; the differences across clients are in distribution, auth, audience, and discovery, not in whether the protocol works.

The clients in scope for this comparison:

Claude (Anthropic) – first-class MCP support since 2024 launch
ChatGPT (OpenAI) – first-class as of 2025, consolidated from earlier Plugin/GPT framework
Cursor + AI-first IDEs (Windsurf, Cline, Continue) – first-class, treats MCP as primary extension model
Microsoft Copilot – supported via Copilot agent framework
Gemini (Google) – first-party servers from late 2025; third-party support firming through 2026
Perplexity – supported, retrieval-focused

The Eight Dimensions That Matter

If you are deciding which AI clients to ship to and in what order, the questions that actually move the decision are: how does each client distribute MCP apps, what is its auth model, who is its audience, and how does discovery work inside it.

The eight dimensions:

MCP support. Whether the client supports MCP, what version of the spec it implements, whether support is first-class or retrofitted.
User-facing term. What the client calls an installable MCP app inside its own product. Determines marketing language.
Distribution mechanism. How a user gets your MCP app installed: curated marketplace, manual install via configuration, or admin-controlled enterprise distribution.
Discovery. How a user finds your MCP app among alternatives: marketplace search, featured slots, agent-led routing, external catalogs.
Auth model. OAuth 2.1 with PKCE, API-key handoff, or enterprise SSO via the host's identity provider.
Permissions granularity. Whether access is granted at the MCP app level, the tool level, or per-action at runtime.
Audience. Who actually uses this client – consumer, prosumer, developer, enterprise knowledge worker, vertical specialist.
Monetization pathway. Whether and how an MCP app developer can charge for use.

The matrix

Client	MCP support	User-facing term	Distribution	Discovery	Auth model	Permissions	Audience	Monetization
Claude (Anthropic)	First-class, since 2024 launch; tracks current spec	Connector	In-product connector marketplace + manual config (claude.json)	Marketplace search, editorial featured, agent-led suggestion	OAuth 2.1 + PKCE; Dynamic Client Registration; SAML/SCIM on enterprise tier	Per-tool consent at install; per-action confirmation for mutations	Prosumer + enterprise; strong dev adoption	No first-class paid-app billing yet; vendor-side billing common
ChatGPT (OpenAI)	First-class as of 2025; consolidated from Plugin/GPT framework	App	Consolidated GPT/MCP app store + manual install paths	Store search, featured slots, prompt-led routing	OAuth or API key depending on install path	App-level scopes; per-tool consent on newer builds	Broad consumer + prosumer; growing enterprise via Teams/Enterprise	App store with revenue share emerging; details still firming
Cursor + AI-first IDEs	First-class; treats MCP as primary extension model	MCP server	Manual install via config file (`mcp.json`); community catalogs; one-click install URLs	Community catalogs, GitHub, word-of-mouth, Cursor's directory	API key dominant; OAuth supported on remote servers	Largely permissive; per-server install consent	Developers, AI-first engineering teams	No first-party billing; open-source norms dominate
Microsoft Copilot	Supported via Copilot agent framework	Agent / Copilot extension	IT admin-controlled deployment via Microsoft 365 admin center	Internal corporate catalogs; Microsoft AppSource	Entra ID; SAML; SCIM	Admin-granted org-level scopes; per-user consent for sensitive scopes	Enterprise knowledge workers, Microsoft 365 customers	AppSource billing; co-sell programs
Gemini (Google)	First-party servers from late 2025; third-party support expanding through 2026	Connector / extension (terminology in flux)	Workspace admin distribution; account-level installs for individuals	Workspace marketplace; Google search-led discovery	Google OAuth	Scope-based (Google's standard model)	Workspace customers, Google account holders	Workspace marketplace billing pathways
Perplexity	Supported, focused on retrieval and research-flow tools	Connector	In-product, lightweight install	Curated; small surface	OAuth	App-level	Research-heavy professionals, prosumer	Limited; product-led growth focus

Transport and Auth Support Per Client

The MCP spec defines three transports (stdio for local servers, SSE for early remote servers, streamable HTTP for current remote servers). Client support varies, and this affects which hosting model you can use.

Transports

Client	stdio (local)	SSE (legacy remote)	Streamable HTTP (current remote)
Claude desktop	Yes	Yes	Yes
Claude.ai (web)	No	Yes	Yes
ChatGPT	Limited (developer mode)	Yes	Yes
Cursor	Yes	Yes	Yes
Microsoft Copilot	No	Yes	Yes
Gemini	Limited	Yes	Yes
Perplexity	No	Yes	Yes

For a remote MCP server in 2026, streamable HTTP is the right default. SSE is supported across all clients but is the older transport and is slowly being deprecated. Stdio matters only for desktop clients and developer-mode integrations.

Auth and security capabilities

Client	OAuth 2.1	PKCE	Dynamic Client Registration	Authorization server metadata	Enterprise SSO	Per-tool consent
Claude	Yes	Required	Yes	Yes (RFC 8414)	SAML, SCIM (enterprise tier)	Yes, at install
ChatGPT	Yes (modern install paths)	Yes	Partial	Partial	OIDC	App-level + emerging per-tool
Cursor	Yes (remote servers)	Yes	Limited	Limited	Limited	No native UI
Microsoft Copilot	Via Entra ID	Yes	N/A (Entra-managed)	N/A (Entra-managed)	Native (Entra)	Admin-granted org-level
Gemini	Via Google OAuth	Yes	N/A (Google-managed)	N/A	Native (Google Workspace)	Scope-level
Perplexity	Yes	Yes	Limited	Limited	No	App-level

The practical implication: an MCP app shipping to Claude needs full DCR + RFC 8414 metadata support from day one. A multi-client MCP app needs all three auth patterns. For deep auth design guidance, see MCP auth and security.

Per-Client Decisions and Gotchas

Should I ship my MCP app to Claude?

Ship to Claude first if your buyer is prosumer or knowledge-worker. Claude has the most coherent buyer experience for connectors, the strongest baseline for if you ship to one client, ship here, and editorial featured slots that meaningfully drive distribution.

Distinguishing characteristics: in-product connector marketplace, OAuth 2.1 + PKCE with mandatory Dynamic Client Registration (the spec compliance bar is the highest in the table), per-tool consent at install, agent-led suggestion (Claude itself surfacing your connector mid-conversation when relevant), strong adoption among developers and knowledge workers.

Claude Gotchas

Connector marketplace review takes 2–3 weeks for new submissions; rejections most often cite scope-design issues or unclear tool descriptions. Per-tool consent screens get long with many tools – connectors with 30+ tools have noticeably higher abandonment at install. Group tools by capability or split into multiple connectors. Enterprise tier has additional review requirements (SAML SSO support, admin install support, audit log surface).

Should I ship my MCP app to ChatGPT?

Ship to ChatGPT first if your audience is broadly consumer or prosumer and raw audience size matters more than depth of feature support. ChatGPT has the largest user base in the table by a wide margin, and the consolidated GPT/MCP app store is the most mature MCP marketplace as of 2026.

Distinguishing characteristics: consolidated app store, OAuth or API key depending on install path, store search + featured slots + prompt-led routing, broadest audience.

Gotchas: legacy Custom GPT documentation still leaks into developer docs (verify which install path your app actually uses); revenue share program details for the app store have been firming through 2026; featured-slot positioning is the dominant distribution lever and the long tail is hard.

Should I ship my MCP app to Cursor and the AI-first IDEs?

Ship to Cursor (and Windsurf, Cline, Continue) first only if your product is a developer tool. The AI-first IDEs are the right surface for developer-tooling companies and almost no one else; the audience does not match most B2B SaaS buyer profiles.

Distinguishing characteristics: manual install via mcp.json config file, community catalogs, no marketplace gatekeeper, API-key-dominant auth.

Gotchas: the configuration file is the install vector – users manually edit mcp.json (error-prone, higher install-fail rate than marketplace clients); one-click install URLs (cursor://...) reduce this and should be provided where possible; Cline, Continue, and Windsurf have similar install patterns but slightly different config schemas; DevRel matters here more than in any other client.

Should I ship my MCP app to Microsoft Copilot?

Ship to Copilot first if your product sells into enterprise and your buyers already have a Microsoft 365 footprint. Copilot is the strongest enterprise distribution surface in the table, with the heaviest implementation requirements and the most mature procurement story.

Distinguishing characteristics: IT admin-controlled deployment via Microsoft 365 admin center, Entra ID identity, AppSource marketplace, enterprise knowledge worker audience, AppSource billing + co-sell programs.

Copilot Gotchas

Entra ID setup is the longest pole – plan for 2–4 weeks of identity-integration work even with experienced engineering. AppSource review can take 6–12 weeks for new MCP-app submissions; the review is more rigorous than other clients (security, accessibility, compliance). Copilot's MCP support sits inside the larger Copilot Studio + agents framework, which has its own concepts (knowledge sources, topics, actions) that overlap MCP terminology – expect a translation layer in conversations with Microsoft.

Should I ship my MCP app to Gemini?

Ship to Gemini first if your audience is Workspace-heavy. Gemini supports MCP across Google Workspace properties, with first-party MCP servers shipped by Google for Drive, Gmail, Calendar, Chat, and Chrome DevTools through late 2025 and 2026.

Distinguishing characteristics: Workspace admin distribution, Google OAuth, Workspace marketplace + Google search-led discovery, Workspace customer audience.

Gotchas: third-party MCP support is real but firming through 2026 (Google's first-party servers shipped first, third-party path lags – verify current state before committing roadmap); Workspace admin distribution requires a Workspace customer account on the buyer side; feature parity with Anthropic is uneven.

Should I ship my MCP app to Perplexity?

Ship to Perplexity first only if your product augments research, retrieval, or a vertical-data workflow. Narrower surface than the other clients, focused on research-heavy professional use.

Time to First Install and What Will Change First

Realistic deployment timelines

Time from a working MCP server to first user install per client, assuming an experienced team with the server already built:

Client	Time to first install
Cursor + AI-first IDEs	1–2 days (no marketplace review; just publish install URL or community catalog entry)
Claude (consumer connectors)	2–4 weeks (marketplace review, scope review)
Claude (enterprise tier)	4–8 weeks (additional review for SAML/SCIM, admin distribution)
ChatGPT	3–6 weeks (app store review; revenue share enrollment if applicable)
Gemini	2–6 weeks (Workspace marketplace review)
Perplexity	1–3 weeks (lightweight curation)
Microsoft Copilot + AppSource	6–12 weeks (rigorous AppSource review)

These ranges assume the server is built and OAuth is working. Full timeline from project kickoff to first user install runs 8–24 weeks depending on the client and build complexity. Each additional client also adds 30–60% to the build, which is why client count is one of the larger line items in what an MCP server costs to build.

Monetization landscape

Monetization is currently weak across all clients in 2026:

Microsoft AppSource and Workspace marketplace (Gemini): mature billing infrastructure inherited from existing Microsoft / Google channels
ChatGPT app store: revenue share programs emerging, details still firming
Claude, Cursor, Perplexity: no first-class paid-app billing

For most B2B products in 2026, the right monetization path is your existing subscription. The MCP app is a distribution surface, not a billing channel. Revisit in twelve to eighteen months.

What will change first

Two dimensions are most likely to shift between quarterly updates of this matrix:

Monetization. Every client knows it needs a story; none has fully shipped one. Expect meaningful changes in 2026 and 2027. The first client to ship a credible developer-revenue model will reshape distribution math.
Agent-led routing. The degree to which the AI client itself recommends MCP apps to users mid-conversation. Tool description quality compounds disproportionately on agent-led routing in ways it does not yet on marketplace search.

Reading the matrix when you choose where to ship

A few patterns recur across the engagements we work on, and they are the patterns most absent from the matrices product teams build for themselves.

Audience first, mechanics second. The single most common mistake is choosing a client because the developer experience is good rather than because the buyer is there. Cursor has the most permissive distribution model in the table, and for most B2B SaaS products it is the wrong place to start, because the buyer of a CRM or a contracts platform is not an AI-first engineer using Cursor.

Distribution model determines distribution work. A marketplace-distributed client (Claude, ChatGPT, AppSource) means submitting, getting reviewed, optimizing for store search, and competing for featured slots – work that looks more like App Store optimization than like API integration. A manual-install client means a different motion entirely.

Auth model is a procurement signal. Enterprise buyers have radically different reactions to "OAuth with per-tool consent" versus "API key in a config file" versus "Entra-ID-mediated admin install." If you intend to sell into enterprise, the clients with mature auth and admin-controlled distribution are higher-leverage even when the developer experience is heavier.

For the strategic question of which clients to ship to, this matrix is most useful read alongside the MCP strategy decision framework. For the technical question of what auth model to design for, see MCP auth and security. For build-vs-buy, see MCP build vs buy.

A matrix is a snapshot. The strategy is the read.

Related Guides

What to Call MCP Apps: Terminology Guide – Working vocabulary for product teams shipping in 2026
How to Embed Your App in AI Clients with MCP – The full strategic framework
MCP Strategy Decision Framework – Should your app be in AI clients in 2026?
MCP Embedding Types Explained – Read-only, actions, agent-resident
MCP Auth and Security – OAuth 2.1, scopes, audit logs, enterprise readiness

Frequently Asked Questions

Which AI clients support MCP?

All major AI clients support MCP as of mid-2026: Claude, ChatGPT, Cursor (and other AI-first IDEs like Windsurf, Cline, Continue), Microsoft Copilot, Gemini, and Perplexity. The protocol itself is standardized across these clients; differences are in distribution, auth, audience, and discovery.

Is Claude or ChatGPT better for MCP apps?

Claude has the more coherent connector experience, stronger agent-led discovery, and the most spec-compliant OAuth implementation. ChatGPT has the larger raw audience and the more mature app store. For prosumer and knowledge-worker audiences, Claude is typically the stronger first ship. For consumer-facing products, ChatGPT typically wins on reach.

Does Microsoft Copilot support MCP?

Yes, through the Copilot agent framework (Copilot Studio + agents). Distribution is admin-controlled via the Microsoft 365 admin center, auth uses Entra ID, and AppSource provides the marketplace. Implementation overhead is higher than other clients; procurement story is stronger.

Does Cursor support MCP?

Yes, as a first-class extension model. Cursor and other AI-first IDEs (Windsurf, Cline, Continue) treat MCP as the primary extension surface. Auth is predominantly API-key based for local servers; OAuth is supported for remote servers. Distribution is via manual install (mcp.json config) and community catalogs.

Can one MCP app work in all AI clients?

The MCP protocol is standardized, so the underlying server can be reused. But each client has its own auth model, distribution mechanism, terminology, and metadata standards. Expect 30–60% additional work per added client even with full server reuse.

Which MCP client has the largest user base?

ChatGPT has the largest raw audience among the major AI clients in 2026, by a meaningful margin. Claude has the most engaged prosumer audience. Cursor leads in AI-first developer audience. Microsoft Copilot has the largest enterprise footprint via Microsoft 365 distribution.

What MCP transport should I use?

For local servers, stdio. For remote/hosted servers (the typical SaaS pattern), streamable HTTP is the right default in 2026. SSE is supported but is the older transport and is slowly being deprecated for new builds.

Does MCP support Dynamic Client Registration?

Yes – the MCP spec specifies OAuth 2.1 with Dynamic Client Registration (RFC 7591) and authorization server metadata discovery (RFC 8414) for remote servers. Claude has the strongest DCR support in 2026; other clients have partial implementations.

Originally published at launchdayadvisors.com. Launch Day Advisors is a buyer-side advisory firm: we help companies select AI, software, and design partners, and we are paid only by the buyer.

What It Costs to Build an MCP Server in 2026

Jonathan Blessing — Fri, 18 Sep 2026 12:06:08 +0000

In brief: A partner-built MCP server costs ~$100K–$300K for a level-1 read-only single-client app and ~$300K–$700K for a level-2 actions app; a second client adds 1.4–1.7×, and a level-3 agent-resident build starts at $1M+. In-house equivalents run 60–80% of partner cost in raw spend before opportunity cost. The number is driven by auth complexity, tool-surface size, your own product's complexity, multi-client overhead, and embedding depth – not by the server code itself. Budget $5K–$25K/month for ongoing maintenance on top of the build.

Building an MCP server costs between $100K and $1M+ in 2026, and the single biggest factor is how much the server is allowed to do. A read-only connector to one AI client runs $100K–$300K. A server that takes actions on a user's behalf runs $300K–$700K. An agent-resident rebuild starts at $1M. The server code itself is the cheap part – auth, audit, the safety story, and distribution are where the budget actually goes.

MCP servers are almost never priced as a license – the protocol is open and no major AI client has first-class paid-app billing yet – so "MCP server pricing" means the build ($100K–$1M+ by scope), the retainer that follows it ($5K–$25K/month), and the underlying API and token costs that land on whoever uses it.

What you are pricing	2026 figure
Level-1 read-only server, one client, partner-built	$100K–$300K
Level-2 actions server, one client, partner-built	$300K–$700K
Second client	1.4–1.7× the single-client total ($420K–$1.2M at level 2)
Security and auth line items in a level-2 build	OAuth $60K–$120K · audit log $40K–$80K · third-party pen test $30K · first-time SOC 2 Type II $50K–$150K
Ongoing maintenance	$5K–$25K/month retainer, plus ~$20K/year hosting
Fee to install or use the server	None – the cost is the underlying service's API plan, the AI client's token bill, and hosting; see MCP server pricing below

Those ranges come from the same place every figure in this guide does: real 2026 partner engagements and in-house builds, cross-checked against our MCP build vs buy analysis. This guide breaks the number down – what you are paying for, how scope moves it, what it looks like in-house versus with a partner, and three worked examples at different sizes. If you are still deciding whether to ship to AI clients at all, start with the MCP strategy decision framework; if you have decided and are choosing who builds it, see how to evaluate an MCP build partner.

The Estimate That Wrecks the Budget

Almost every blown MCP budget starts with an undersized estimate. A serious MCP server shipped to one client at actions depth is not a two-week sprint and not a single-engineer project. Teams that scope it that way routinely discover by month three that they are short two engineers and a designer, and by month six that the first ship will not clear the safety bar enterprise procurement asks about. The number below is what it costs to do it once, correctly, instead of twice.

What Goes Into an MCP Server Build

When you budget for an MCP server, you are budgeting for seven things, and only one of them is the server. A complete level-2 (actions) build for a single client is one to two quarters of work for a properly staffed team. The scope:

Server implementation – the process, hosting, observability, and deployment pipeline, built to the MCP spec (JSON-RPC 2.0 over stdio, SSE, or streamable HTTP).
Tool surface design – the create_, update_, search_, and get_ operations, each named and documented with the precision of a public API, because an agent reads the names to decide what to call.
Auth implementation – OAuth 2.1 + PKCE, typically with Dynamic Client Registration and authorization-server metadata, plus a scope taxonomy, token lifetimes, refresh, and revocation. This is one of the largest line items, and it is covered in depth in MCP auth and security.
Audit and logging surface – per-invocation logs, parameter capture, session reconstruction, and a customer-admin-facing view of what the agent did.
Safety story – idempotency keys, reversibility patterns (soft delete, revision history), and intent-preview-friendly parameter shapes. The depth required here scales with embedding level: read-only barely needs it, actions cannot ship without it.
Distribution package – submission to the host client's marketplace, store metadata, screenshots, documentation, and a support workflow.
Maintenance commitment – keeping up with the host client's spec, auth, and distribution-policy changes, plus your own evolving tool surface, indefinitely.

That list is the work for one client. The server code – item one – is genuinely the cheap part. Auth, audit, and the safety story are where a six-figure budget is spent, because they are the difference between a prototype that demos well and a product that survives a security review.

Cost Ranges by Scope

Scope is the master lever. "Scope" here means two things: how much the server is allowed to do (its embedding level) and how many AI clients you ship to. The rough envelopes for partner-built MCP servers in 2026:

Scope	Calendar time	Partner cost (USD)	In-house (raw spend)
Level-1 read-only, single client	~1 quarter	$100K–$300K	$80K–$240K
Level-2 actions, single client	~2 quarters	$300K–$700K	$200K–$520K
Level-2 actions, two clients	~2.5–3 quarters	$420K–$1.2M	$300K–$900K
Level-3 agent-resident	Multi-quarter program	$1M+	$700K+

Level-1 read-only lets an agent search and retrieve from your product but never change anything. The safety surface is small, so this is the cheapest serious ship. The bottom of the range – roughly $100K–$150K – buys a single client, 5–10 carefully chosen tools, OAuth 2.1 + PKCE + DCR, and basic audit logging.

Level-2 actions lets the agent create, update, and delete on the user's behalf. That single capability change roughly doubles the cost, because every write operation needs idempotency, reversibility, and an intent-preview-friendly shape, and the audit log moves from nice-to-have to mandatory.

Two clients is not double the work, but it is not free either. A second client adds 1.4–1.7× the single-client cost – different auth, different distribution, different terminology, different review process. You are porting a working design, not rebuilding it, but each surface wants to be excellent on its own terms.

Level-3 agent-resident is a different category: rebuilding the product so an agent can operate it end to end. It is a multi-quarter program starting at $1M, and most teams should not start here. The embedding types guide covers when level-3 is justified – almost always only when the company is rebuilding around an agent-first thesis.

Line-Item Cost Breakdown

Ranges are useful for a board slide; line items are what you negotiate against. Here is a representative breakdown for a level-2 single-client partner build at the middle of its range (about $500K total):

Component	Typical cost (USD)	What it covers
Discovery, design, scope taxonomy	$40K–$80K	Posture review, embedding-level decision, scope design, tool-surface specification
Server implementation, hosting, observability	$50K–$100K	MCP spec implementation, transport, hosting infra, monitoring
Tool surface (10–25 tools)	$80K–$180K	Implementation, validation, testing, and documentation per tool
OAuth implementation, scope design	$60K–$120K	OAuth 2.1 + PKCE + DCR, scope taxonomy, token lifecycle, revocation
Audit log + customer-admin surface	$40K–$80K	Per-invocation logging, tamper-evident storage, admin UI
Safety story	$60K–$120K	Idempotency keys, soft-delete and restore, revision history, intent preview
Marketplace submission, distribution polish	$20K–$50K	Listing copy, screenshots, review iteration, documentation
Project management, knowledge transfer, contingency	$40K–$80K	PM overhead, runbooks, pairing engagements, buffer

The two line items that dominate are the tool surface and the safety story. The tool surface is expensive because each tool is a small public API – it gets implemented, validated, tested, and documented, and an agent's willingness to call it depends on how well the last two are done. The safety story is expensive for the same reason auth is: it is invisible when it works and catastrophic when it does not. A proposal that lists these two as small numbers is a proposal that has not thought about write operations.

Questions to Ask a Proposal

Ask any partner to break the build into line items matching the table above. What does "auth design complete" mean as an acceptance criterion? Is the third-party penetration test in scope or extra? Who owns the code, and from what date? Does the safety story include reversibility for every write tool, or only some? A transparent, line-itemed proposal is a real estimate. A vague lump sum is padding or guessing – and you cannot tell which until it is too late.

In-House vs Partner and Break-Even

The instinct is that in-house must be cheaper, and in raw dollars it is – about 60–80% of partner cost. (If the partner route wins for you, how to choose an AI development partner covers the selection side.) Here is the same level-2 scope, staffed internally:

Component	Typical cost (USD)
1 PM @ 75% × 26 weeks	$50K
1 tech lead @ 75% × 26 weeks	$60K
2 senior backend engineers × 26 weeks	$130K
1 mid backend engineer × 20 weeks	$50K
Designer @ 30% × 16 weeks	$20K
Security engineer @ 30% × 12 weeks	$15K
DevOps @ 25% × 16 weeks	$15K
Technical writer @ 30% × 8 weeks	$10K
Hosting + tooling	$20K
Penetration test (third party)	$30K
Total	~$400K

So in-house lands near $400K against a $500K partner mid-point – a real gap of $100K in raw spend. The catch is that the gap closes, and often reverses, once opportunity cost is counted. Those four-plus engineers are not idle; they are pulled off the roadmap. If the delayed features, missed customer commitments, and slowed pipeline add up to more than ~$100K in value, the partner wins on total cost. For most growth-stage SaaS companies, they do. For more mature companies with genuine slack capacity, in-house wins.

There is also a calendar-time gap the dollars hide: a partner ships in roughly six months, an in-house team running its first MCP build in seven to eight. The full build-versus-buy decision – including the hybrid models that consistently work – is the subject of MCP build vs buy. The cost framing here is the input to that decision, not a substitute for it.

The False Economy

The most expensive MCP build is the one staffed thinly to "save money." One engineer, part-time, no security review, audit log as a TODO. By month three the team has half a server. By month six the company is hiring or hiring a partner anyway, and the rework – roughly 30–50% of the in-progress code – is on top of the original spend. Picking the right path before staffing is the cheapest decision in the whole project. Picking it after is the most expensive.

Three Worked Examples

Ranges land better against concrete shapes. Three teams, three budgets.

Small SaaS shipping a read-only Claude connector. A 30-person SaaS wants its data searchable inside Claude – no writes, one client, a focused tool surface of 6–8 read tools. This is the cheapest serious ship: level-1, single client, OAuth 2.1 + PKCE + DCR, basic audit logging. Budget $100K–$150K partner-built, one quarter of calendar time. The temptation is to add write tools "while we're in there." Resist it – that decision moves the project into the next tier.

Mid-market SaaS shipping level-2 actions to Claude and ChatGPT. A 200-person SaaS wants agents to create and update records, and it wants to be in both Claude and ChatGPT at launch. That is level-2 actions across two clients. Build the first client fully ($300K–$700K), then add the second at 1.4–1.7× the single-client cost. Plan for $420K–$1.2M and 2.5–3 quarters. Ship the strategic client first and port what works rather than abstracting across both from day one – the cross-client abstraction is what produces a server that is mediocre on every surface.

Enterprise SaaS shipping level-2 to Microsoft Copilot via AppSource. A large SaaS wants actions inside Microsoft Copilot, distributed through AppSource. The build itself is level-2 single-client: $300K–$700K. Two enterprise-specific costs sit on top. First, the AppSource review and listing process adds calendar time – plan for a 6–12 week review window, per the MCP client comparison, and budget the iteration. Second, enterprise procurement will ask for SOC 2; first-time SOC 2 Type II attestation typically runs $50K–$150K over 6–9 months, per MCP auth and security. If you are not already attested, that is part of the true cost of shipping to an enterprise client.

Ongoing Operational Costs

The build is a one-time number. The MCP server is not. Three recurring costs outlive the launch:

Hosting and tooling – roughly $20K/year for a single-client production server, scaling with traffic and client count.
Maintenance retainer – $5K–$25K/month, depending on complexity and number of clients. A good retainer covers host-client spec changes, auth-model changes, distribution-policy changes, security patches, and minor feature work. Watch for a retainer that covers nothing actionable – maintenance that is real work, not a line item.
Spec-change upkeep – the host clients you ship to keep changing. New spec versions, new auth requirements, new marketplace policies. A partner whose business is MCP absorbs these across many clients; an internal team treats each as an unplanned project. This is a cost either way; the only question is whether it is amortized or absorbed.

The honest framing: an MCP server is a product with an indefinite maintenance commitment, not a project that ends at launch. Budget for the retainer from day one, because the alternative – letting the server drift out of spec until it breaks – is more expensive and worse for the buyers who came to depend on it.

MCP Server Pricing: Do MCP Servers Cost Money to Use?

Most MCP servers are free to install and the protocol itself costs nothing – Anthropic open-sourced it in November 2024, and as of 2026 no major AI client has shipped a first-class paid-app billing pathway (see the MCP client comparison). So "MCP server pricing" is almost never a license fee. The money lands in three other places. First, the underlying service: the server is a thin door into a product, and that product's API is often gated to a paid plan or metered per call, so the API keys behind the server carry the real price. Second, tokens in the AI client: every tool definition and every tool result is fed to the model as input, billed at the model provider's per-token rate on each turn – roughly $3 per million input tokens for a frontier model, per the run-cost math in the AI implementation cost guide. A server with thirty verbose tools taxes every conversation it is installed in, whether or not a tool is called. Third, hosting, if the server is remote – small for a local stdio server, ~$20K/year for a production single-client server as above. If you are the vendor, the fourth cost is this guide: the build and the retainer.

Where the money goes	Who pays	Typical shape
Protocol and server software	Nobody	Open spec; most servers open-source or bundled free
Underlying service API	The user's company	Paid plan tier or per-call API metering
Tokens in the AI client	The user's model bill	Per-token; tool definitions + results count as input on every turn
Hosting (remote servers)	The vendor	~$20K/year for a production single-client server
Build and maintenance	The vendor	$100K–$1M+ build, $5K–$25K/month retainer

What Drives MCP Server Cost Up or Down

Five levers move the number more than any others. Knowing them lets you keep a build at the bottom of its range instead of the top:

Auth complexity. Basic OAuth with a handful of scopes is cheap. Fine-grained scopes, enterprise SSO, and per-client auth paths are not. Fine-grained scopes cost more up front but move enterprise procurement faster – a trade-off, not waste.
Tool-surface size. Each tool is implemented, validated, tested, and documented. Ten well-chosen tools cost far less than thirty mediocre ones, and agents call a tight surface more reliably.
Underlying product complexity. A clean, well-modeled product is cheap to expose. A tangled data model or brittle internal API means the MCP build pays to work around it – sometimes more than the server itself costs.
Multi-client overhead. Every additional client is a partial rebuild at 30–60% of the first ship. Shipping to one client excellently is cheaper and better than shipping to three clients adequately.
Embedding depth. Read-only is cheap; actions roughly double it; agent-resident is a different category entirely. The single largest decision you make about cost is how much the server is allowed to do.

The teams that come in at the bottom of the range are not cutting corners – they are scoping deliberately: one client, a tight tool surface, the embedding level the use case actually needs, and a clean product underneath. The teams that come in at the top usually got there by abstracting across clients too early or shipping write tools without a safety story, then paying to fix both.

Related Guides

MCP Build vs Buy: Should You Hire a Partner or Build In-House? – The decision this cost model feeds into
How to Embed Your App in AI Clients with MCP – The complete build playbook for product leaders
MCP Embedding Types: Read-Only vs Actions vs Agent-Resident – The embedding-level decision that drives most of the cost
MCP Auth and Security – Why auth is one of the largest line items
MCP Client Comparison – Per-client distribution, review timelines, and monetization
How to Evaluate an MCP Build Partner – Pressure-testing a quote against defensible ranges
AI Implementation Cost: A Buyer's Cost Model – The broader AI budget this sits inside

Frequently Asked Questions

How much does it cost to build an MCP server?

In 2026, a partner-built MCP server costs $100K–$300K for a level-1 read-only single-client app and $300K–$700K for a level-2 actions app. A second client adds 1.4–1.7×, and a level-3 agent-resident build starts at $1M+. In-house equivalents run 60–80% of partner cost in raw spend.

How much does an MCP server cost?

The build ranges from $100K to $1M+ depending on scope. Read-only single-client sits at the bottom ($100K–$300K), actions in the middle ($300K–$700K), and agent-resident at the top ($1M+). On top of the build, plan $5K–$25K per month for ongoing maintenance.

What's the cheapest way to build an MCP server?

Level-1 read-only, a single client (usually Claude or ChatGPT), 5–10 carefully chosen tools, OAuth 2.1 + PKCE + DCR, and basic audit logging. Partner-built, that is the bottom of the range at roughly $100K–$150K. In-house with experienced staff, less in raw spend but with longer calendar time.

How much does a level-2 (actions) MCP server cost?

A level-2 actions MCP server for a single client costs $300K–$700K partner-built, with a representative mid-point around $500K. The two largest line items are the tool surface ($80K–$180K) and the safety story ($60K–$120K) – idempotency, reversibility, and intent preview for write operations.

Is it cheaper to build an MCP server in-house or hire a partner?

In-house is cheaper in raw spend – about 60–80% of partner cost – but the gap narrows once you count the opportunity cost of pulling engineers off the roadmap. If that opportunity cost exceeds ~$100K, the partner usually wins on total cost. For most growth-stage SaaS teams, it does.

How much does MCP development cost per client?

The first client carries the full build cost. Each additional client adds roughly 30–60% of the first ship – different auth, distribution, terminology, and review process per client. Two clients at level-2 typically land at 1.4–1.7× the single-client cost, or about $420K–$1.2M.

What are the ongoing costs of running an MCP server?

Hosting and tooling (roughly $20K/year), plus a maintenance retainer of $5K–$25K/month covering host-client spec changes, auth changes, distribution-policy changes, security patches, and minor feature work. The maintenance is indefinite – the clients you ship to keep changing their specs.

Do MCP servers cost money to use?

Usually not as a license fee – the protocol is open and no major AI client has first-class paid-app billing yet. The real costs are the underlying service's API plan, the tokens the AI client spends on tool definitions and results every turn, and hosting for remote servers. Vendors additionally pay to build and maintain the server.

What drives MCP server cost up?

Five things: auth complexity (fine-grained scopes, enterprise SSO), tool-surface size (more tools, more testing), the complexity of your own product, multi-client overhead (each client is a partial rebuild), and embedding depth (read-only is cheap, actions and agent-resident are not).

Originally published at launchdayadvisors.com. Launch Day Advisors is a buyer-side advisory firm: we help companies select AI, software, and design partners, and we are paid only by the buyer.

AI-Native Apps Will Swallow the Web

Jonathan Blessing — Thu, 21 May 2026 19:20:05 +0000

Here is my prediction: AI-native apps will swallow the web. Not in ten years, but before 2026 is over – and the transition is already underway.

MCP – the Model Context Protocol Anthropic introduced in November 2024 – has already been adopted by Google, Microsoft, and the W3C. Every major LLM speaks it. The browser vendors are integrating it directly: WebMCP is a draft at the W3C with an early implementation already shipped in Chrome. The naming is still loose – agentic apps, agent-native apps, in-chat applications – but the category is real.

MCP is going to swallow the web just as the web did the desktop. AI-native apps (or whatever they come to be called) are the next web.

MCP is going to swallow the web just as the web did the desktop.

The web we have will not vanish. It will be subsumed. Before 2026 is over, AI-native-only will be a viable path: a product that exists as MCP-callable tools and machine-readable state, with no browser, no mobile app, no human-facing surface – and a real customer base. The agents are already there. The protocol is in place.

Users will pull this forward because the AI becomes both the access point and the source of enrichment. One conversation instead of a dozen tabs. The AI knows the sneakers, knows the cars, knows how you like to travel. Like the whole of the web, the merchant's site becomes raw material.

Like the whole of the web, the merchant's site becomes raw material.

This sounds extreme, but it is also already underway. Shopify has built a Storefront MCP for AI-mediated commerce. AI-native apps are bringing back the constraints that shaped the early web – stateless protocols, server-side logic, forms for input – for a new class of consumer.

It is because of this seismic shift that our client work has reorganized around it, and it is why we just published a new cluster of MCP guides – eight pieces written for product leaders deciding whether and how to be present inside leading AI clients. We start with the working vocabulary the category has not yet settled, lay out a strategic decision framework that determines posture, set the client comparison matrix for choosing where to ship first, walk through the embedding-types breakdown that distinguishes read-only from actions from agent-resident, frame the auth and security expectations enterprise procurement actually wants, work the build-vs-buy economics of in-house engineering versus a development partner, give you a partner evaluation checklist for a category too young for the usual portfolio signals, and tie it together in a hub guide. The category is moving fast enough that vague advice ages quickly. These guides are specific, current, and built to be useful for the decisions our clients are making right now.

AI-native apps will swallow the web.

Originally published at launchdayadvisors.com

Every Day is Y2K

Jonathan Blessing — Wed, 08 Apr 2026 16:22:27 +0000

Twenty-six years later, I think we should remember Y2K —a crisis named after its deadline.

My first job in New York was as the BBC's Y2K coordinator for the Americas. I spent months preparing systems for a single night. Fix the code, test and re-test the systems, and hold my breath at midnight. The sun rose the next morning and Y2K was happily forgotten.

Mythos-class AI does not offer a date. It offers a condition. Thousands of zero-day vulnerabilities surfaced in weeks, with no reason to believe the rate slows. The next model will find more. The one after that, more still. There will be no midnight.

Mythos-class AI does not offer a date. It offers a condition.

Consider: Mythos found a 27-year-old zero-day in OpenBSD —the operating system built, from the ground up, by people whose entire reputation rests on not having exploitable code. It is like discovering that if you hold water just so, it explodes. If that system had a door no one found for 27 years, what is hiding in the systems that were not built with security as a founding obsession?

This week, tech companies privately briefed the White House on what Mythos means for national security. The conversation is no longer theoretical.

Imagine a Y2K-level event every day. We are moving into a permanent state of crisis.

Most people have not yet absorbed this because they are still thinking in terms of events —a breach here, a hack there, each one reported, investigated, and forgotten. That is the old model. The new model is not a series of events. It is a climate.

The new model is not a series of events. It is a climate.

This is the new operating environment. Not a crisis to be resolved, but a tempo to be endured. We survived Y2K by treating it as an engineering problem with a deadline. The institutions that survive this will be the ones that recognize there is no deadline. The present does not end. It only compounds.

The question is no longer whether the vulnerabilities exist. Mythos answered that. The question is whether the rate of discovery will outpace the rate of repair. For any system where theft is irreversible —crypto being the most obvious, but not the only one— the math is not encouraging.

So much for the forecasted employment crisis. What comes instead is a permanent mobilization. The work of hardening systems, triaging vulnerabilities, and patching what each successive model discovers does not end. AI will not replace the workforce. It will redirect it —into an unending cycle of repair. The machines will not take your job. They will make sure you never finish it.

Originally published at launchdayadvisors.com