In practice
It might connect to a database, file system, API or product's own data. The AI app is the host, and it runs 1 client for each server it connects to.
Servers can run locally on your machine or remotely at a URL. Remote servers update in 1 place and need no local install. Local servers can reach files and programs on your machine that a remote server can't.
Say you run a four-person team and use Claude Code. You connect a server that exposes your customer feedback. It offers two tools: one lists your ranked priorities and one reads the spec on a single priority. You ask your agent what to build next. The agent's client calls the first tool, the server returns the list, and the agent answers from it. You never copied anything between windows.
A server can offer three kinds of things, according to the MCP documentation: tools, which are functions the AI can run; resources, which are data it can read; and prompts, which are reusable templates. Most servers you will meet are mostly tools.
An MCP server isn't a model or the agent, and it isn't an API: it often sits in front of one and describes it in a form an AI app can discover on its own. It only offers tools and data, and popular doesn't mean safe. The app you connect it to decides what gets used.
How to check a server before you connect it
- Find out who runs it. A server from the product's own maker is a different bet from a stranger's repository.
- Read the tool list before you use it.
- Sort the tools into read and write. A tool that creates, edits or sends needs a closer look.
- Start with one real question that only reads, and look at what the agent got back.
The full checklist is in the guide on MCP servers for product management, which also covers what a server should do for product work.
Common mistakes
- Connecting a server without reading its tool list. You can't judge what an agent might do with a tool you haven't looked at.
- Trusting a server because the tool descriptions sound safe. The MCP specification says descriptions of tool behavior should be treated as untrusted unless they come from a trusted server.
- Mixing up the server and the client. The server holds the tools and data. The client is the part inside your AI app that connects to it.
- Granting write access when a read would do. If the question is what to build next, the agent doesn't need to edit anything.
- Connecting a server and assuming it is on. Many apps load servers when a session starts, so a server added mid-session may need a new session.
Why it matters for product builders
Before MCP, every tool needed a separate integration with every AI app. A server written once can work with any client that speaks the protocol. That helped the ecosystem grow quickly through 2025.
**Source note**
Anthropic published the [Model Context Protocol](https://modelcontextprotocol.io) as an open standard in November 2024.
For a product builder, a server is the door your product work walks through to reach an agent. If your priorities, customer evidence and specs sit behind a server, every agent you run can read the same facts. If they sit in a document only you read, each agent starts from whatever you paste in.
It also changes what to ask of a tool you buy. A useful question is no longer only whether it has an API. It is whether it has a server your agents can connect to, and what that server lets them do.
What changes in AI-first products
The MCP server is an AI-era idea. Nothing about it existed in the same form before AI apps began calling tools on their own. What changed is who does the asking. Before, a person opened a tool, copied the answer and pasted it into a chat. Now the agent asks the server directly, in the middle of a task.
What didn't change is that a server is a program with permissions. Someone has to decide what it exposes, who may use it and what needs a human yes before it runs. The MCP documentation itself says there should always be a human in the loop with the ability to deny tool invocations. A server makes agents more capable. It doesn't make their choices good.
See how Annsa does it: Integrations →