How an MCP connection works
The host is the AI application used by a person. It creates an MCP client connection to the server. The server describes the tools and information it provides, then translates approved requests into calls to company systems.
What is an MCP server?
Model Context Protocol is an open protocol for connecting language model applications to external tools and information. An MCP server is the program that makes those capabilities available. The host application contains an MCP client that connects to the server.
MCP uses JSON-RPC messages. During connection setup, the client and server negotiate the protocol version and supported capabilities. A server can expose any combination of tools, resources, and prompts.
- Tools
- Functions the model can call, such as searching a database, creating a ticket, running a calculation, or updating a record.
- Resources
- Information the application can read and place in context, such as a file, database schema, product record, or API documentation.
- Prompts
- Reusable instruction templates that help users start a known task with the correct inputs and context.
What an MCP project can include
The scope depends on the systems being exposed and the clients that need to connect. A typical MCP development project may include the following work.
Server design
Define the tools, resources, prompts, naming, schemas, errors, and capability boundaries.
System integration
Connect REST or GraphQL APIs, SQL databases, document stores, SaaS products, queues, or internal services.
Authentication
Implement user or service authentication, authorization scopes, tenant separation, and credential handling.
Local and remote deployment
Use stdio for a local process or deploy a remote server over Streamable HTTP.
Client integration
Configure and test the server with the intended host applications or model APIs.
Testing and operation
Test tool selection, schemas, failures, timeouts, permissions, logging, and changes in connected systems.
Systems that can be exposed through MCP
An MCP server can sit in front of an existing system. The underlying API does not need to be replaced. A smaller, purpose-built interface gives the AI application access only to the operations and information it needs.
- • Internal REST and GraphQL APIs
- • PostgreSQL, MySQL, SQL Server, and other databases
- • Document libraries and company knowledge bases
- • CRM, ERP, ticketing, and project management software
- • Cloud storage and collaboration tools
- • Source code, CI systems, infrastructure, and developer tools
- • Company calculations, validation rules, and reporting services
Do you need MCP or a direct API integration?
MCP is an integration standard, not a replacement for every API. The number of clients and the expected reuse usually determine whether it is worth adding.
MCP is usually a good fit when
- • Several AI assistants or agents need the same company capability
- • Users need to choose which tools or data sources to connect
- • The available tools should be discoverable at runtime
- • You want the integration to work with more than one model provider or host
- • The tool set will be maintained as a separate service
A direct integration may be simpler when
- • One application calls one fixed API operation
- • The model never needs to discover or select the function
- • The existing application already owns authentication and tool execution
- • No other client is expected to reuse the integration
MCP security and permissions
An MCP tool can read sensitive information or change another system. The server must check every request independently of the model. Tool descriptions and model instructions are not access controls.
For remote HTTP servers, the MCP authorization specification defines an OAuth-based flow. Local stdio servers normally receive credentials from their environment. The correct setup depends on whether the connection represents a user, an application, or an internal service.
- Least privilege
- Each tool receives only the permissions required for its own operation.
- Approval boundaries
- Read operations and actions that change data can use different confirmation rules.
- Input and output checks
- The server validates arguments, limits returned data, and rejects values outside the expected schema.
- Token handling
- Access tokens are validated for the intended server and are not passed through to unrelated systems.
- Prompt injection controls
- Content returned by tools is treated as data. Untrusted text does not gain permission to call another tool.
- Audit records
- Logs can record the user, tool, arguments, result status, approval, and timing without copying unnecessary sensitive data.
What you receive
You receive a working MCP server and the code needed to run it in the agreed environment. The repository includes tool schemas, configuration, tests, deployment instructions, and documentation for the connected systems and each tool's required permissions.
For an existing MCP server, the scope can cover tool design, protocol compatibility, authentication, security boundaries, error handling, and behavior with the target clients. The result may be a written review, implemented changes, or both.
- • Source code and typed tool or resource schemas
- • Automated tests for protocol and business behavior
- • Authentication and authorization configuration
- • Container or local installation package
- • Client configuration examples
- • Deployment, monitoring, and maintenance documentation
MCP development questions
Can MCP connect to our existing API?
Yes. The MCP server can call an existing REST, GraphQL, SOAP, or internal API. The existing API normally stays in place, while MCP exposes a smaller set of operations designed for model use.
Can an MCP server connect directly to a database?
Yes, but unrestricted database access is rarely appropriate. A safer design exposes specific read or write operations, applies the user's permissions, validates parameters, and limits the returned fields and number of records.
What is the difference between an MCP server and an MCP client?
The server provides tools or information. The client is the protocol component inside an AI host application that connects to one server. A host can create several clients to connect to several servers.
Can the server run inside our network?
Yes. A local server can run through stdio on the same machine as the host. A remote server can run in a private network or cloud environment. Whether a particular external host can reach a private server depends on that host's supported connection method.
Which programming languages can be used?
MCP has official or community SDK support in several languages. TypeScript and Python are common choices, but the language should fit the connected system, deployment environment, and your team's maintenance needs.
Will it work with every AI application?
Only applications that support the required MCP features and transport can connect. Client support differs, so the target hosts need to be identified and tested individually. A remote server usually needs Streamable HTTP; local desktop and development tools often support stdio.
Does MCP make an integration secure?
No. MCP defines communication and authorization mechanisms, but the server still needs correct permissions, token validation, input checks, approval rules, and logging. The connected systems must enforce their own access rules as well.
How long does an MCP server take to build?
A small read-only server for a documented API can be relatively short work. A server with several systems, user authorization, write actions, and multiple client targets takes longer. A reliable estimate requires a review of the operations, permissions, and deployment environment.
Can you improve an MCP server we already have?
Yes. An existing implementation can be reviewed for client issues, unclear tool design, missing authentication, excessive data exposure, weak tests, or compatibility with the current MCP specification.
Protocol references
The implementation is based on the current MCP specification and the documentation of the clients included in the project.