Model Context Protocol in practice: connecting SQL data to AI agents safely

Businesses with useful internal data face a practical question: how can an AI application work with that information without receiving unrestricted access to the systems behind it? Model Context Protocol, or MCP, offers a common interface for exposing selected tools and resources. Connecting a database through that interface still requires careful engineering and clear rules about what the application may access.

What is MCP, and how does it relate to internal data?

MCP is an open protocol originally introduced by Anthropic. It standardises communication between compatible AI applications and external tools or data sources. Instead of building a completely different connector for every compatible client, a team can expose a documented server interface that clients understand.

An MCP server can run locally or remotely. This does not mean information remains on premises: a hosted model may receive data returned by a tool as part of its context. The protocol is not a privacy or retention guarantee. Review the entire data path, client settings and applicable provider terms before connecting sensitive records. Retrieving data at request time also differs from training a model on that data.

Benefits for developers and technical leaders

A standard interface can make AI integration easier to maintain, particularly when several tools or clients need access to the same business capabilities.

• Consistent interfaces: compatible clients can use the same tool definitions.
• Reusable development: connection and discovery mechanisms reduce some repetitive integration work.
• Separation of responsibilities: data-access rules remain in an application layer rather than being embedded in a prompt.
• B2B use cases: a customer-facing assistant can retrieve authorised reports through narrowly scoped tools.

MCP does not remove the need for business APIs, permission checks or maintenance. Start with a specific workflow and evaluate whether the protocol actually makes that workflow simpler. Our development team can help assess the integration and its boundaries.

Preparing SQL data for a controlled integration

The first step is to describe the data and the business meaning behind it. An agent needs to know whether a price includes tax, whether an order has been cancelled and which dates a report should use. An accurate schema and a few clear definitions are more useful than a large undocumented export.

Separate structured records from supporting documentation. Document relevant tables, relationships and column meanings; for example, clarify whether total_price is before or after discounts. Then design the allowed questions and validate the results against known examples before granting access to real customer data.

The MCP server and its tool definitions

The server acts as an intermediary between the client and approved application operations. Choose a maintained SDK and runtime appropriate to the team, such as TypeScript or Python, and pin a supported version. Review compatibility with the intended transport and deployment environment.

Tools such as search_customers and get_invoice_details should have clear descriptions and input schemas. Validate their inputs on the server, apply business rules and return only the fields required for the task. A JSON schema helps describe a call; it does not establish that the caller is authorised or that a model has interpreted the result correctly.

Combining MCP with retrieval and orchestration

Frameworks used for AI orchestration, including LangChain and LlamaIndex, may be part of a wider implementation. MCP supplies a tool interface; retrieval-augmented generation supplies relevant reference material to a model. They solve different problems and can be used together when that adds value.

A document retrieval pipeline may split content into passages and index embeddings for semantic search. Ordinary SQL reporting may not need a vector database at all. Keep access restrictions attached to the data throughout retrieval, and test whether answers are supported by the retrieved material. Prompt instructions are useful guidance, not an access-control boundary.

Security and permissions for sensitive information

Define who may use each tool, which records that person may access and which operations are allowed. For an initial analytics use case, prefer narrowly scoped read-only database permissions and predetermined queries or application services. Read-only access still allows disclosure, so it is not sufficient on its own.

Apply authentication and authorisation outside the model, including tenant and record-level checks. Use restricted views or a separate dataset when that reduces exposure. Limit result size, execution time and request frequency, and avoid accepting arbitrary SQL generated by the model. Treat retrieved documents and tool output as potentially untrusted input.

Review token handling and transport security against the MCP security guidance. Keep secrets out of prompts and logs. A technical SEO audit is not a substitute for a security assessment of this integration.

A practical desktop reporting example

A compatible desktop client might request a sales report for the previous quarter. Its MCP tool can call an approved reporting operation, return the permitted aggregate values and let the assistant explain or visualise them. The user should be able to inspect the reporting period, definitions and underlying figures.

The SQL database can remain inside the company network while selected results are sent to the AI client or model provider. Decide which aggregates may leave that environment before implementation. Where policy requires local processing, choose an architecture that actually meets that requirement and verify it rather than relying on the location of the MCP server.

Preparing for multiple agents and production use

Separate agents may gather data, draft a report and check consistency. Giving work to several agents does not establish the accuracy or legal compliance of their output. Keep a clear responsible owner and approval points for consequential actions.

Monitor tool calls, failures, latency and resource use. Record enough information for an audit without unnecessarily copying sensitive data into logs. Enforce query limits and backpressure so inefficient requests cannot monopolise database capacity. Test timeouts, revoked permissions, missing records and partial failures before widening access.

Pre-launch checklist

• Are the important tables, fields and reporting definitions documented?
• Is there a repeatable process for investigating wrong answers and failed tool calls?
• Does a measurable use case justify the development and operating costs?
• Are database and application permissions restricted to the minimum necessary?
• Have latency, concurrency and failure recovery been tested?
• Do the data path, retention settings and approval process match company policy?

Start with a small, reviewable integration

A useful first project connects one clearly defined workflow to a limited set of trusted tools. Evaluate it with real examples, document its boundaries and expand only when the results justify doing so. devBoys can help design the application layer and integration around your existing systems.

The objective is useful access to the right information, with controls that remain effective even when the AI makes a mistake.