If your agency wants to offer clients an MCP server, the pattern that works is one server per client, built from that client's own website and documents, published on that client's own domain. On SuperCognit this takes no code: import the client's site — it is crawled into a cited knowledge base in about two minutes — upload the documents the site doesn't cover, attach any tools, publish. Each server lives in its own workspace, isolated from every other client you run.

One build produces two surfaces. The client gets a chat agent they can put on their website, and an MCP server their team or their customers can add to Claude or any other MCP client. Same knowledge, same configuration, answered in both places — which means the deliverable you demo in the first meeting and the deliverable their team connects to are the same object.

Why one per client, not one server with client folders

The tempting shortcut is a single agency server with a section per client. Resist it. Two clients' pricing rules sharing one knowledge base will eventually meet in one answer, and that is a phone call you do not want to take.

  • Isolation is structural. A workspace is a hard boundary; a server can only answer from what its own workspace holds. No prompt engineering is doing the separating.
  • Auth is per server. Every server implements OAuth 2.1 to the current spec — issuer validation, CIMD registration — so who can connect is decided client by client, not agency-wide.
  • Offboarding is clean. If a client leaves, you hand over or retire one workspace. No other client notices.
  • The brand separates too. Custom domains are supported, so each server answers at the client's own hostname, not yours.

What goes into a client's server

Three kinds of material, in whatever mix the client's business needs:

  • The website crawl. Imported and cited, so every answer points back to the page it came from — which matters when the client's own staff are checking the machine's work.
  • Documents. The things the site never says: rate sheets, policies, the onboarding guide, the FAQ that lives in someone's sent folder.
  • Tools. HTTP tools you configure become callable MCP tools, so the server can check availability or look up an order instead of only describing how one would.

Then one decision per client: private or public. A boutique hotel might publish a public server so a guest's assistant can ask about rooms and rates. A 40-person accounting firm probably wants a private one — an internal brain of SOPs and policies that only staff can connect to. Same build either way; different audience, different boundary.

The retainer question

An agency deliverable that decays is a liability, and most AI deliverables decay fast. This one maintains itself: knowledge re-syncs on a schedule, as often as hourly, so when the client updates their site, the server follows without a ticket. That is what turns the engagement from a project into a productised service you can describe honestly in a proposal.

For money, two roads. Fold the server into the retainer you already bill, or sell access per seat directly: Stripe subscriptions, invoices and payouts are built in, with SuperCognit as merchant of record taking a platform fee. Either way you are not building billing infrastructure, and you are not chasing invoices.

The first client, in an afternoon

01

Pick the client whose site is the product

Hotels, clinics, firms with deep service pages — businesses whose website already answers questions are the fastest wins. Four Seasons Fairways, a SuperCognit customer, is exactly that shape: a property whose guests ask the same questions all season.

02

Import and read

Crawl the site, then actually read what the knowledge base holds. The gaps you find are the documents to request in your kickoff email — clients respond faster to a specific list than to a request for content.

03

Publish both surfaces

The chat agent gives the client something to see in the first meeting; the MCP server is the part their team connects to Claude. Put it on their domain before the handover demo, not after.

04

Set the sync schedule and step back

Frequent for pages that change — rates, availability, menus — slower for the rest. Then the maintenance line in your proposal is true without being expensive.

Plans are in EUR with a 7-day trial — long enough to build the first client's server before you pitch it, which is the demo that closes it.