MCP Server Examples: Six We Run in Production, and the Rules Behind Each

An MCP server exposes a system to AI assistants like Claude or ChatGPT as a set of typed tools the assistant can call: search a contact, create a draft page, preview a price change. The examples you usually find are a filesystem server or an echo tool. Below are six we run in production: a CRM, a travel marketplace's catalog, an online store's pricing, a data pipeline, a spreadsheet reader and an image generator. For each one: what it does for the business, some of its real tools, and the design rule it taught us. If you're new to the protocol, start with what MCP is.

---

1. A CRM: the whole sales pipeline, from a conversation

What it does. Our own CRM is exposed to Claude through more than 160 tools. Most of our daily sales work happens from the assistant, not the CRM screens: "Who needs a follow-up today, and why?", "Log this call against the deal", "Draft the follow-up and move the deal to proposal sent."

Some of its tools: search_contacts, get_contact, log_interaction, update_deal_stage, get_todo_list, draft_message, send_for_signature, preview_merge.

The rule it taught us: the server enforces permissions, never the prompt. Every call runs as the signed-in user through MCP OAuth. Read and write are separate scopes, and any tool not explicitly marked read-only needs write access. Updates and deletes accept a dry run that shows what would change before anything does. Every query is limited to the caller's own organization on the server side. A model can be talked into anything; a database filter can't. The full story is in Claude for small business.

2. A travel marketplace's catalog: drafts freely, publishes only with a person

What it does. For an airport-transfer marketplace we built, an assistant sets up new destinations end to end: it creates the airport with its country, coordinates and time zone, builds the booking page, adds the places travelers are taken to, and attaches them. About 75 tools cover airports, booking pages, places, providers, translations, media and the dispatch board.

Some of its tools: airports_create, destinations_find, destinations_update, hotspots_attach_booking_page, pages_render, media_prepare_upload, dispatch_board.

The rule it taught us: let the assistant write drafts freely, and make publishing a person's decision. Drafts are saved straight away with no approval step. After every change the server returns the edit page and a preview link, so the person sees the result immediately. pages_render lets the assistant look at the page on a mobile screen before saying it's done. Nothing can be deleted, only set to draft or published. And files never pass through a tool call: the server hands back an upload link, and the file goes straight to storage.

3. An online store's prices: a guard the model can't talk its way past

What it does. For an online store selling travel data plans, an assistant manages the catalog: countries, regions, plans, articles, orders and promotions. It can resend an order email, retry a failed activation, or write a destination guide. About 50 tools.

Some of its tools: plans_list, plans_sheet_preview, plans_sheet_apply, orders_resend_email, orders_retry_provisioning, articles_create.

The rule it taught us: put money behind a guard and a preview. Prices are integer cents, never floating-point numbers. Every price passes one check: at least the cost, plus card fees, plus a minimum margin. A price can only change through a sheet: the assistant sends the rows to plans_sheet_preview, the person sees the changes, and only then does plans_sheet_apply write them. No tool creates or deletes a product; the catalog import does. The assistant can do a lot of useful work without ever being one prompt away from selling at a loss.

4. A data pipeline: long jobs as runs, not one blocking call

What it does. A wine data onboarding pipeline turns the files a client uploads (spreadsheets, exports from old systems, several sources at once) into one clean catalog. The assistant inspects the uploaded files, checks a configuration, starts a run, follows its progress, reads the logs when something fails, reruns from the failed step, and pushes the result when it's right.

Some of its tools: inspect_sources, validate_config, create_run, get_run, get_run_logs, rerun_from, push_run.

The rule it taught us: model long work as runs the assistant starts and checks, not one call that blocks. A run can take minutes. One tool starts it and returns an id, another reports progress, and a failed step can be rerun without starting over. Validation is its own tool, so most mistakes are caught before a run starts, not ten minutes in, and its description says plainly that the run checks again: a pre-flight pass is not a guarantee. Pushing the result is a separate, deliberate step.

5. A spreadsheet reader: tools to understand a file, not a paste of it

What it does. Clients send spreadsheets: price lists, inventories, exports from old systems. Instead of pasting a whole file into a conversation, the assistant gets tools to understand it: list the sheets, detect where the real table starts, read the column types, then read the ranges it needs.

Some of its tools: spreadsheet_list_sheets, spreadsheet_detect_structure, spreadsheet_get_column_types, spreadsheet_read_range, spreadsheet_read_csv.

The rule it taught us: give the model a way to look before it reads. A real workbook has title rows, merged headers, notes in the margins and three tables on one sheet. Detecting the structure first, then reading only the relevant range, is more reliable and cheaper than handing over the whole file. It's the same lesson as the 90-tab price book: the structure is the specification.

6. An image generator: the brand rules travel with the tool

What it does. The hero images on this blog, including this one, come from an MCP server attached to our website's code. The assistant asks for an image for a blog post, and the server writes optimized files straight into the right folder, ready to commit.

Its tools: images_presets, images_generate, images_optimize.

The rule it taught us: put the rules in the server, so every caller follows them. images_presets returns the house style and what an image may never show: no text, no logos, no real people, no screen facing the camera. The server adds those rules to every prompt itself. Whoever asks, whatever they ask, the output stays on brand.

What these MCP servers have in common

Six different systems, the same handful of rules:

• Permissions live in the server. The assistant acts as the signed-in user, with read and write separated.
• Drafts are free; commitments need a person. Publishing, prices, deletes and anything touching revenue go through a preview or an approval.
• Money and identity get hard guards. Integer cents, minimum margins, records scoped to one organization.
• Long work is a run you can check. Start it, poll it, read the logs, rerun the failed step.
• The server teaches the assistant. A readme tool, presets, clear names and error messages that say what to do next.

None of this is about the protocol. The protocol is the easy part, as our how to build an MCP server guide shows in about 50 lines. The months go into the tools, the permissions and the guards. More on that in MCP servers for AI agents: from demo to production.

Where to start with your own

1. Pick one system and one job. The CRM after calls, the catalog before a launch, the price list in January.
2. List the five actions a person does there most often. Those are your first tools.
3. Mark which ones only read. Ship those first.
4. For each write, decide its guard: a dry run, a preview, an approval, or a hard rule like a minimum price.
5. Connect it to the assistant your team already uses, and watch what they ask for next.

Our published prices: scoping one workflow costs $2,300 to $4,700, and a first workflow in production starts at $17,500, then from about $470 a month to run it.

Related: What is MCP?, 91 tools, one server, and MCP security.