How to sell MCP: a field guide for agencies, consultants and internal champions

"Selling MCP" is shorthand for selling a company's knowledge and actions, made available to AI assistants in a form they can actually use: an MCP server the buyer's team connects from Claude or any other MCP client, or that the buyer's own customers connect to. Nobody buys a protocol. They buy answers that are right and cited, actions that are permitted rather than improvised, and the end of copy-and-paste. On SuperCognit a server is built without code from a website, documents and tools, published private or public, sold per seat if you want, and run alongside every other server you operate for every other customer. This guide covers the whole loop: what to sell, to whom, in which words, how to package it by industry and by department, how to sell it inside a company, and how to manage a portfolio of them.

Why "MCP" is suddenly a search term

The Model Context Protocol went from one vendor's specification to the shared plug standard for AI tools in under two years. Claude, coding assistants, desktop apps and a growing set of enterprise software all speak it; the spec is now stewarded by a foundation rather than a single company, and its auth model has already been through a major revision. Commercially that means one thing: the buyer's staff already have MCP clients on their machines. The question in the market has moved from "what is this" to "who will build ours" — which is why the phrase is being typed into search bars by agency owners, consultants and IT leads at the same time.

The window matters. Every business that gets an MCP server this year gets it from somebody. Being that somebody is the opportunity, and the skill it takes is more commercial than technical: knowing what to promise, what to show, and what not to say.

What you are actually selling

Strip the acronym away and the offer has four parts. Sell these, in this order, and the protocol becomes a footnote.

• Accuracy. Assistants improvise about companies they have never seen. An MCP server answers from published, approved material, with citations pointing at the source. The pitch is not "AI" — it is "the AI stops guessing about you".
• Reach. The answers show up where the buyer's people already work: inside Claude, inside the assistants their customers use, and — from the same build — in a chat widget on the website, on WhatsApp and Telegram, and over an API. One build, many doors.
• Permission. Tools turn a server from a reference into a colleague: check availability, look up an order, create a ticket, capture a lead. Each action is one the buyer chose to expose, and every user is authenticated — OAuth 2.1, per person, per server.
• Maintenance you don't do. Knowledge re-syncs on a schedule, as often as hourly, so the server tracks the website and the documents instead of drifting from them. This is the line that turns a project into a subscription.

Translating benefits into the buyer's words

Buyers do not share your vocabulary, and the fastest way to lose a sale is to teach it to them. Say the outcome; let them ask about the mechanism.

The objections, and the honest answers

Five objections come up in almost every conversation. Have the answers ready, and keep them short.

The demo that closes: build it before the meeting

The single most effective sales move in this market is to arrive with the buyer's server already built. Import their website — it is crawled into a cited knowledge base in about two minutes — and you walk in with a chat agent that answers questions about their business better than their own homepage does. The first fifteen minutes of the meeting are the buyer asking it things.

Then run the three-questions test: ask the three questions their team answers most often. If the answers come back right and cited, the sale is mostly done. If one comes back wrong, you have found the document they need to send you — which is the kickoff email written for you. Either outcome moves the deal.

The chat agent is the demo; the MCP server is the deliverable. They are the same build, so the thing the buyer saw and the thing their team connects to are the same object. Never demo one and deliver another.

Three offers that fit almost every buyer

Most MCP engagements fall into one of three shapes. Name them in your proposal and the buyer will pick.

Sell the first two as services and the third as a product. The mechanics are identical; the pricing conversation is not.

How the build works on SuperCognit

Plans are priced in EUR with a 7-day trial — long enough to build the first buyer's server before you pitch it.

Horizontal or vertical: the same server, two ways to sell it

A horizontal solution solves one job for every industry: customer support, sales qualification, employee onboarding, policy lookup. A vertical solution solves every job for one industry: the hotel, the clinic, the property agency. MCP servers are unusual in that the same build sells both ways — and the mistake is to pick one when the market wants you to sell the horizontal job in the vertical's vocabulary.

Selling horizontally: departments

Departments buy outcomes they already measure. The knowledge and tools differ; the pitch is the same across industries.

Selling vertically: industries

Industries buy from people who speak their language. Build the horizontal template once, then sell it in the vertical's words with the vertical's tools.

The productised move is to keep a template per department and clone it per industry: the same support server, dressed in hospitality vocabulary for the hotel and in clinical vocabulary for the clinic. Knowledge and tools change; the structure of the engagement does not, which is what lets you quote it in a day.

Selling MCP inside a company

Not every sale crosses a company boundary. The internal champion — an operations lead, an IT manager, the head of a department — is selling to their own leadership, and the pitch changes shape. Nobody inside cares about the protocol either; they care about the twelve people who ask the same forty questions.

The internal case is easier to make than the external one, because the proof is already in the building: the chat thread where the policy was explained for the fourth time, the onboarding doc nobody can find, the spreadsheet of answers that lives on one person's laptop. A private MCP server is that person's knowledge, made available to everyone, inside the assistant they already have open.

The internal pitch, in three lines

• Staff already use Claude and other assistants at work — often without telling anyone. A company server gives them a sanctioned source instead of a guessed one, which is a governance win before it is a productivity win.
• It is behind login. Every employee signs in with OAuth; access ends when the person leaves. Nothing is public unless someone makes it so.
• It costs a subscription, not a project. No developers, no integration backlog, and it follows the documents as they change.

Where to start internally

One department, one server, the questions that department is tired of answering. Operations SOPs and HR policies are the usual first wins because the content already exists and the audience is the whole company. Publish it, connect it from Claude, and let the head of the department watch their inbox shrink for a month. That number is the budget request for the second server.

For an agency, internal servers are also the second sale at every client: the public front door for customers, then the private brain for staff — same workspace, built from the same imports.

Managing many MCP servers for many customers

Once the second customer signs, you are no longer building servers; you are operating a portfolio. The rules that keep a portfolio sane are structural, and they are easier to set up on the first customer than to retrofit on the tenth.

One workspace per customer, always

A workspace is a hard boundary: a server can only answer from what its own workspace holds. Give each customer their own — their knowledge bases, their tools, their credentials, their conversations and leads — and cross-contamination becomes impossible rather than merely unlikely. It also makes offboarding one action: hand the workspace over to the customer or retire it, and no other customer notices.

One login for your team

Under a partner arrangement your workspace is linked to each client workspace, and your staff work inside every one of them from the dashboard login they already have — as administrators, never as owners. Access is derived from the partnership rather than from membership rows, so a client cannot accidentally remove you mid-engagement, and ending the relationship is one change on your side. When a client wants to take a server in-house, the workspace is already theirs; you step out rather than migrate.

The operating rhythm

What isolation buys you commercially

Isolation is not only a security property; it is the reason you can say yes to competitors. Two hotels on the same street, two accounting firms in the same city: separate workspaces, separate servers, separate domains, and no prompt engineering doing the separating. Say it in the proposal. The buyers who ask about it are the ones worth having.

Pricing that survives the second conversation

Three anchors keep pricing simple across all three offers.

• Price against the alternative. A seat that saves one email to a person a month is worth a fraction of that person's hour, and the buyer already knows what their people cost.
• Keep the menu short. Setup fee plus retainer for services; one per-seat price for products. A buyer forced to compare tiers ends up comparing you to doing nothing.
• The test is approval, not accuracy. If the buyer can say yes without calling a meeting, the price is right.

For products sold by the seat, the platform handles checkout, recurring invoices and payouts as merchant of record and takes a platform fee; your accounting sees payouts. For agency retainers, bill as you already do and treat the seat cost as a line item. For partners with many clients, wholesale seat pricing under an agreement is the same conversation with a smaller number in it.

What not to promise

The buyers who renew are the ones you were straight with. Four lines to keep out of every proposal:

• It does not replace judgment. The server handles the repeatable layer; the bespoke decision still needs a person. Subscribers who outgrow the answers are the consulting pipeline, not a failure.
• It does not know what was never published. A server is as good as its sources, and "we'll add that document" is a legitimate answer to a wrong demo.
• Public means public. A front-door server is a deliberate decision about what a stranger's assistant may ask. Curate it; do not let it accumulate.
• Cheap tokens are not free tokens. Answering costs something per question; static tools cost nothing per call, which is why methodology products should lean on them.

A 30-day plan for the first three customers

Selling MCP is selling the end of a specific, familiar frustration: the assistant that guesses. The protocol is what makes the fix portable; the platform is what makes it deliverable without code; the offer is what makes it a business. Build one this week and sell it to someone who already trusts you.