Model Context Protocol (MCP): Security, Metrics, and RAG
Modern AI needs context to stay accurate. It also needs strong security and dependable performance. The Model Context Protocol (MCP) brings a clean way to connect models to external knowledge without losing control.
The Model Context Protocol (MCP) acts as a universal communication layer. It allows large language models to securely connect with external tools and services. An MCP server is the adapter in this architecture. It gives the AI access to live data and actions beyond its training data. An AI agent can act only through the tools its MCP servers expose.
You can run retrieval augmented generation (RAG) close to users and data. That reduces latency. It also helps with data residency and privacy. With an MCP server and SQL Database, you can add semantic search and vector storage close to your users.
This guide explains how MCP works, what to measure, and how to design secure RAG pipelines on a distributed architecture. It also compares running your own MCP server on Azion with connecting a coding agent to the Azion MCP servers. If you are new to the protocol, start with What is Model Context Protocol (MCP)?.
Model Context Protocol (MCP) Fundamentals
The Model Context Protocol is built on a clear client-server architecture. This design intentionally separates responsibilities to improve security and scalability. At the heart of this model are three key components. The host is the user-facing application, like a chatbot or an IDE, that contains the large language models. The host creates and manages multiple clients. Each client maintains an isolated connection to a single MCP server.
An MCP server is an independent program that provides context and specialized capabilities to the AI application. It is a connector, enabling LLMs to interact with external systems. Communication between the client and server relies on the JSON-RPC protocol, which provides a structured format for messages.
This architecture defines three key primitives:
- Tools: These are executable functions that allow the LLM to perform actions. A tool could be anything from calling an API to a weather service to querying a database. The LLM decides when and how to use these tools as part of its reasoning process.
- Resources: Unlike tools, resources are read-only data that provide additional context. They act as an extended memory for the AI. Examples include file content, database schemas, or a Git history.
- Prompts: These are pre-defined templates or sets of instructions that guide how the AI should interact with a tool or resource. A prompt can help the model structure a query or outline steps for an action.
MCP Servers on a Distributed Architecture
Traditional cloud computing can present major hurdles for modern AI applications. The round-trip time for data traveling between a user’s device and a centralized cloud data center introduces latency. This can be a deal-breaker for applications requiring a rapid, real-time response.
That is where a distributed architecture helps. It moves computation and data storage closer to the user, which makes it a good fit for a high-performance MCP server.
Deploying a server on a distributed infrastructure with data centers close to users reduces network latency. It allows the MCP server to process requests in milliseconds. This enables applications to provide true real-time data and low-latency interactions. This is especially critical for AI agents that need to make split-second decisions, for example, in fraud detection or autonomous driving.
The benefits of a distributed architecture go beyond speed. It also enhances data privacy by processing sensitive information locally. This reduces the need to transmit data over less secure public networks. It helps organizations comply with regulations like GDPR and HIPAA.
A distributed approach also improves reliability. Applications remain operational even during regional outages or connectivity issues. Another data center can take over the workload.
An effective way to run an MCP server on a distributed architecture is with serverless functions. These functions, like the ones that run on WebAssembly, provide an isolated and secure environment. This “scale-to-zero” model means you only pay for resources when your server is actively processing a request, making it a cost-effective solution for variable workloads.
Securing Your MCP Server: A Zero-Trust Approach
The power of AI agents to act on behalf of a user creates a complex new attack surface. A zero-trust security model is the only viable approach for deploying an MCP server in a production environment. With a zero-trust model, you never automatically trust any entity. This requires security controls at every layer.
One of the most dangerous security risks is prompt injection. This attack vector exploits the fact that large language models do not clearly differentiate between system instructions and user input. An attacker can craft a seemingly harmless message containing hidden instructions. This tricks the LLM into performing an unauthorized action, such as extracting a sensitive file or sending a malicious email.
Other vulnerabilities also pose serious threats. The “confused deputy” problem can occur if a server has elevated privileges. This allows a low-privilege user to trick the AI into accessing resources they shouldn’t have. There are also supply chain risks from using open-source servers with vulnerabilities, like the SQL injection bug found in a reference SQLite server that was forked thousands of times.
Unauthorized command execution is another major risk. A server is not properly sandboxed, and an attacker can exploit it to run arbitrary code on the host system. This is a critical security vulnerability.
To mitigate these security risks, developers must implement a layered defense. This starts with treating every server as untrusted code. Deploying servers in isolated environments, such as a container orchestrated by a Kubernetes cluster, is an essential step to prevent unauthorized access to the host system.
Strong authentication and authorization are also critical. A server should use modern standards like OAuth and Role-Based Access Control (RBAC) to ensure only authorized users and systems can access specific tools. Continuous monitoring is the final layer of defense. A platform with integrated threat detection can help identify and block malicious traffic before it ever reaches the server.
Performance Metrics for a Healthy MCP Server
The performance of an MCP server directly impacts the utility and reliability of the AI application it supports. Traditional performance metrics are not enough for these complex systems. You must measure the quality of the interaction, not just the speed. The classic framework provides a holistic view, evaluating cost, latency, accuracy, security, and stability.
When it comes to speed, low latency is a non-negotiable requirement. Running the server close to users reduces network latency. Two key performance metrics are:
- Time to First Token (TTFT): The time from when a request is sent to when the first part of the response is generated. A low TTFT keeps the user experience responsive.
- Throughput: The number of requests or tokens a system can process per unit of time. High throughput ensures that the server can handle peak loads without degrading performance.
The quality of the response is just as important. The Groundedness metric measures the degree to which a model’s response is supported by the context provided by the MCP server. This is the opposite of a model “hallucinating.” Monitoring Groundedness helps ensure factual accuracy and reliability. A task completion rate is another key metric. This measures the percentage of complex, multi-step tasks that the AI agents can successfully complete.
Monitoring these metrics requires an observability platform. This type of solution aggregates performance data from all components, including the serverless functions acting as servers. It visualizes them in a unified dashboard. This provides a single source of truth for troubleshooting bottlenecks and detecting anomalies in real-time.
Benchmarking and SLAs: From Metrics to Guarantees
You need clear goals before you tune. SLAs force design clarity.
- Set a target p95 latency for search and generation phases.
- Track throughput metrics at the node and cluster layers.
- Measure time to first token for perceived speed.
Add health budgets for each region. If a region misses targets, rate-limit or fail over to a neighboring region. Use OpenTelemetry tracing to find bottlenecks. Drill into spans for embedding model calls, vector search, and re-ranking.
When you change an index (HNSW index to IVF-Flat index), run A/B tests. Watch recall, latency, and cost per request. Keep both indexes for a week before you cut over.
Example Scenarios and Expert Insights
Financial services:
- Goal: Use retrieval augmented generation for policy Q&A without moving PII.
- Approach: Keep data residency in-region. Enforce GDPR, SOC 2, and audit logging. Gate tools with role-based access control.
- Result: Lower p95 latency after moving vector queries to SQL Database. Better precision after tuning cosine similarity thresholds.
Retail search:
- Goal: Improve semantic search for product discovery.
- Approach: Switch from a single global cluster to regions close to users. Test HNSW index for hot categories and IVF-Flat index for the full catalog.
- Result: Faster time to first token during peak hours. Higher click-through with better recall at low latency.
Expert input:
- NIST promotes zero trust architecture for modern systems. Adopt least privilege and continuous verification.
- The OpenTelemetry community recommends standard attributes to make traces portable across tools.
To learn more about running AI on a distributed architecture, see the Azion Blog.
Best Practices for Secure and Performant MCP
Security:
- Apply role-based access control to tools, indexes, and content types.
- Enforce data residency rules per tenant and per index.
- Sanitize prompts and tool outputs to limit prompt injection.
Performance:
- Pick an embedding model that balances quality and cost. Keep the model near your vector database.
- Tune your HNSW index parameters for recall. Adjust IVF-Flat index lists and probes for scale.
- Cache recent queries and frequent results. Use warm starts for fast time to first token.
Observability:
- Instrument everything with OpenTelemetry tracing.
- Track p95 latency for each stage: retrieval, re-rank, generate.
- Monitor throughput metrics to plan capacity.
Table: Key Metrics and Targets
| Metric | Why it matters | Typical target |
|---|---|---|
| p95 latency | Keeps tail slowdowns in check | < 150 ms end-to-end |
| time to first token | Improves perceived performance | < 400 ms |
| throughput metrics | Ensures capacity under load | Sustained RPS target |
| semantic search precision | Protects answer quality | 85–95% per intent |
| cosine similarity threshold | Controls relevance trade-offs | 0.75–0.85 |
Run Your Own MCP Server on Azion
You can run your own MCP server as a function on Azion. Each tool maps to a call to an API you already have, and you can put a firewall with WAF and a rate limit in front of the server. To build one, follow Run an MCP server on Azion. For a production setup that logs every tool call, see the Deploy remote MCP servers use case.
Function calling lets the model ask for a tool by name. In the server code, you validate inputs, mask sensitive fields, and log enough for audit logging without exposing raw payloads.
Connect a Coding Agent to Azion with the Azion MCP servers
The Azion MCP servers are five hosted servers that connect coding agents to the Azion Platform. The docs server searches the Azion documentation, code samples, and the references for the Azion API, CLI, and Terraform Provider, and returns the source of each result.
The build, secure, observe, and storage servers expose more than 200 tools to manage applications, rules, WAF, DNS, certificates, data streams, buckets, and SQL databases through the Azion API. Each write tool accepts dry_run, which returns the exact request before anything changes. The servers authenticate with your personal token, work with ten documented clients, and every Azion plan includes them.
This setup follows the least-privilege practice from the security section: you connect only the servers your agent needs. The agent acts with the permissions of your personal token, so give the token a short expiration.
| Your own MCP server on Azion | Azion MCP servers | |
|---|---|---|
| What it does | Exposes your API or data to AI agents as MCP tools | Gives your coding agent the Azion documentation and the Azion API |
| Who runs it | You, as a function on Azion | Azion, as hosted servers |
| Access control | The authentication you choose, with an optional firewall and WAF | The permissions of your personal token |
| Best for | Offering your services to AI agents | Working on your Azion account from your editor or terminal |
To connect Claude Code with one command, follow the quickstart.
Conclusion: Model Context Protocol (MCP) in Production
The Model Context Protocol (MCP) brings order and safety to context retrieval. You can scale retrieval augmented generation while you meet strict data residency and audit needs. Strong policies, clear metrics, and consistent tracing turn complexity into routine.
With an MCP server on Functions and vector search in SQL Database, you run semantic search and vector storage close to users. That reduces p95 latency and improves time to first token. With the right indexes and role-based access control, you gain performance without losing control.
Adopt a zero trust architecture, bake in TLS 1.3 encryption, and measure everything with OpenTelemetry tracing. With these habits, you’ll keep your MCP pipelines reliable as your traffic grows.