Definition
An MCP client is the connection layer an AI application uses to talk to an MCP server.
The AI application is often called the host. The host may be a desktop assistant, IDE, internal agent workspace, or chat product. Inside that host, an MCP client manages the connection to one MCP server and exchanges protocol messages such as tool discovery and tool calls.
In everyday product language, people often say Claude, Cursor, or VS Code is the MCP client. More precisely, those applications can host MCP client connections. The important point is practical: the client discovers tools from a server and sends structured tool calls when the model decides it needs external capability.
Typical client flow
The client discovers tools first, then calls them with structured arguments.
- Configure the MCP server URL or local server command.
- Send the required authentication headers or token for remote servers.
- Call tools/list to discover available tools.
- Show tool names, descriptions, and input schemas to the model or agent runtime.
- Let the model choose a tool when the task requires external capability.
- Send structured arguments to the selected tool.
- Use the tool result in the next response or workflow step.
Local vs remote MCP clients
The client connection can target a local MCP server or a remote Gateway endpoint.
| Connection type | Good for | Security note |
|---|---|---|
| Local server | Personal developer tools, local files, scripts, and single-user workflows. | Secrets may end up in local config if the server needs upstream credentials. |
| Remote server | Shared APIs, team tools, SaaS products, and scoped database access. | Authentication, source ownership, validation, and logging need to happen server-side. |
| Gateway endpoint | OpenAPI integrations and database scopes that need repeatable controls. | The client receives a Gateway token while upstream credentials stay in the Gateway. |
Configuration boundary
The client should know how to reach the MCP surface, not how to bypass it.
| Configuration item | Belongs in client config? | Reason |
|---|---|---|
| MCP URL | Yes. | The client needs the server address. |
| Gateway token | Yes, when calling a Gateway endpoint. | The client needs scoped authentication to the Gateway. |
| Upstream API key | No. | The Gateway should apply upstream API credentials server-side. |
| Database connection string | No. | Database credentials should stay encrypted server-side and never be returned after save. |
| Tool descriptions | No, not as client-only overrides. | Descriptions should be curated at the published tool surface so every client sees the same contract. |
The client is not the security boundary
A client can request a tool call, but the server must still decide whether it can run.
This distinction matters because MCP clients can be influenced by user prompts, retrieved content, project files, or a model's own reasoning. A client request is not authorization. The server or Gateway should check identity, tool publication state, source ownership, arguments, limits, and scope policy before execution.
For OpenAPI tools, the server should map the tool to a known upstream operation. For database tools, schema metadata and executor tools should stay separate, and executor calls should only use published tables and permitted columns.
Test clients
A simple test client is useful before wiring a full desktop assistant or IDE.
Teams often start with a small client, Gateway Chat, or command-line smoke test to confirm tools/list works, authentication is correct, and the expected tools are visible.
That early check catches simple mistakes before a model is asked to choose and call tools inside a longer workflow. It also reveals whether the published catalog is too broad, too vague, or missing the one tool the workflow actually needs.
What good client setup looks like
A good client setup is boring: the URL works, the token is scoped, the catalog is small, and logs explain what happened.
- tools/list returns only the expected tools.
- The client does not store upstream API keys or database connection strings.
- Tool descriptions are consistent across Gateway Chat and external clients.
- Rejected calls fail before upstream API or database execution.
- Usage, latency, errors, and validation failures are visible in Gateway logs.
- The team can rotate a token or unpublish a surface without editing the upstream API or database.
Sources and further reading
Common questions
Does an MCP client need database credentials?
Usually it should not. A safer design keeps database credentials on the server side and gives the client a scoped way to call approved tools.
Is Claude, Cursor, or VS Code the MCP client?
In practical product language, yes. More precisely, those applications can host MCP client connections to one or more MCP servers.
Can different clients use the same MCP endpoint?
Yes. The same published MCP surface can be used by multiple compatible clients when they have the right URL and token.
Can the MCP client enforce security by itself?
No. The client can request a tool call, but trusted server-side code should enforce authentication, scope, validation, limits, and redaction.
What should I test first in an MCP client?
Start with tools/list. It confirms the server URL, token, publication state, and resolver are working.