What is inside an MCP server?
- A tool catalog: every action the server is willing to perform.
- Schemas: the exact arguments each tool accepts and their types.
- An authentication layer that resolves the caller to a real identity.
- Handlers: the code that performs the work against the underlying system.
- An audit layer that records what was called and what happened.
How does a call actually flow?
The client connects and asks for the tool list. The server returns names, descriptions and schemas. The model reads those descriptions and decides which tool matches the request.
It sends a call with arguments. The server validates them against the schema, checks permissions, executes, and returns a structured result — which the model then explains in plain language.
Why the tool description matters so much
The description is the entire interface between human intent and machine action. A vague description produces wrong tool selection; a precise one produces reliable behaviour.
Descriptions should state what the tool does, what it does not do, and when not to use it.
One server, many systems
A well-built server hides internal complexity. Creating a job might touch several tables, emit events and trigger notifications — but the tool is still one call with a clear name.
This is why the catalog should be organised around business actions rather than database operations.
Where MCP servers run
Usually alongside the application whose data they expose, because they need direct, privileged access to it. They are not public APIs — access is granted per session to an authenticated user's AI client.