The Model Context Protocol lets an AI assistant use your product the way a person would: look things up, take actions, follow your rules. You build one server, and every MCP-compatible assistant can use it.
I have built MCP servers for a production CRM, FindRE, and for a commerce platform. The protocol is the easy part. The decisions below are where a server becomes useful or useless.
1. Start from questions, not endpoints
The most common mistake is to wrap every API endpoint as a tool. You end up with sixty tools the model cannot choose between.
Instead, write down what a user would actually say to an assistant:
- "Which deals have gone quiet this week?"
- "Add a follow-up for this lead on Friday."
- "What is low on stock, and what is on order?"
Each of those becomes one tool, even if it takes three API calls behind the scenes. Aim for a short list. The commerce server I built exposes catalog, inventory, promotions and orders, and that covers what people ask for.
2. Know the three primitives
| Primitive | What it is for | Example |
|---|---|---|
| Tools | Actions the model decides to call | find_stalled_deals, create_follow_up |
| Resources | Information the client can load into context | A lead's record, a policy document |
| Prompts | Ready-made starting points for users | "Review my pipeline" |
Most of the value is in tools. Add resources and prompts once the tools are solid. The full specification and the official SDKs are at modelcontextprotocol.io.
3. Write descriptions for the model
The model reads each tool's name, description and input schema every time it decides what to do. That text is your interface.
Name the intent
find_stalled_dealstells the model when to use it.get_deals_v2does not.Say when to use it, and when not to
"Use to find deals with no activity for a number of days. Do not use for a single deal; use get_deal for that."
Keep inputs few and typed
Enumerate allowed values. Give defaults. Every optional free-text field is a chance for the model to guess wrong.
Describe the output
Tell the model what comes back, so it knows whether it has what it needs or must call something else.
4. Enforce permissions in every tool
This is the part that decides whether the server is safe to ship.
- Act as the user, never as the system. Every call carries the identity of the signed-in person, and each tool applies the same rules your app applies to them.
- Scope by tenant. In a multi-company product, a tool must never be able to reach another company's data, whatever arguments the model sends.
- Do not trust the model. It will sometimes pass an ID it should not know. The check belongs in your code.
- Confirm before writing. Reads can be automatic. Anything that changes data should be reviewable, and destructive actions should need explicit confirmation.
5. Choose the transport
There are two ways a client connects:
- Standard input and output. The client starts your server as a local process. Simple, and right for developer tools or anything that needs the user's own machine.
- HTTP. The server runs remotely and clients connect over the network with sign-in. This is the right choice for a SaaS product, because customers should not have to install or run anything.
For a remote server, use the protocol's authorization flow so each user signs in to your product and the server receives a token scoped to them.
6. Return less
Large responses cost tokens, slow the assistant and hide the answer.
- Return the fields that answer the question, not whole records.
- Page long lists, and say how to get the next page.
- Return errors the model can act on: "No lead matches that email. Try searching by phone number."
7. Test with real assistants
Unit tests tell you the tools work. They do not tell you whether a model will use them well.
- Use the MCP Inspector to check that the server lists its tools and that each one runs.
- Connect a real client, such as Claude, and ask the questions from step one in plain language.
- Watch which tools it picks. When it picks the wrong one, fix the name or the description, not the prompt.
- Try to misuse it: ask for another customer's data, or for a destructive action. The server should refuse.
8. Ship it and document it
- Log every call: who, which tool, what input, how long, what came back.
- Rate-limit per user.
- Write a short setup page for customers, with three example prompts that show what the connection is for.
- Version your tools. Changing a tool's meaning silently will break someone's workflow.
Mistakes worth avoiding
- Mirroring the whole API instead of designing a small tool set
- One service account for every user, instead of acting as the signed-in person
- Returning entire records "in case the model needs them"
- Write actions with no confirmation and no log
- Testing only with code, never with an actual assistant
In FindRE the MCP server is a small set of permissioned tools over the CRM, so an assistant can work with leads and deals on request without direct database access. That is the whole idea: the assistant gets to be useful, and your product's rules still apply.
If you want this built for your product, it is what I do under MCP servers. If you are still working out the agent that will use it, start with how to build an AI agent.