MCP sounds technical, but the idea is simple enough to explain with a restaurant.
The three parts
- The host is the app you talk to — your agent. Think of it as the customer walking into the restaurant.
- The MCP client lives inside the host. It is the part that knows how to read menus and place orders in the standard way.
- The MCP server is the kitchen for one app. It publishes a menu of tools — “search emails”, “create invoice”, “check stock” — and carries out the order when the agent calls.
What happens when you ask for something
Say you ask your agent: “Post this week’s update to my WordPress site.” First, the agent asks the WordPress MCP server, in effect: what can you do? The server replies with its tool list — this step is called discovery, and it happens automatically, every time.
The agent picks the right tool, fills in the details from your request, and calls it. The server does the work inside WordPress and reports back. The agent then tells you it is done — and shows you the link.
Why discovery is the clever bit
With older integrations, a developer had to hard-code every step in advance: if this, then call that. With MCP, the agent discovers what is possible at the moment you ask. Add a new server — a new app — and the agent can use it immediately, without anyone reprogramming it.
Permissions keep you in charge
A good MCP setup asks for the narrowest access that gets the job done: read-only where possible, and your approval before anything sensitive. You decide what is on the menu. The agent can only order from it.
Next read: MCP vs API — why agents prefer MCP, and when a plain API is still the right choice.