Data & AI platform by Data Analytics
Designing an MCP server as a controlled execution layer
An MCP server is a software component that exposes capabilities to an MCP client. For your organisation, design centres on responsibilities: who makes a request, who checks permission and where does execution happen? MCP is a protocol, not a language model or ETL process. This page covers server architecture, not the selection of a particular connector. Start with one bounded task and describe its boundaries before selecting technical components.
The examples on this page are hypothetical situations, not customer cases.
Meet our team
Trusted by data-driven organisations
01
Divide responsibilities between host, client and server
The host is the application in which a user works with AI. It manages MCP clients that maintain connections to servers. A server exposes supported capabilities and translates permitted requests into downstream execution. The model may propose a tool call; that does not make the call authorised. Define where the host requests approval and where the server checks authorisation. Also distinguish the user’s identity from the technical account the server uses to access a source. When multiple users share one account, their permitted scope must still be demonstrably enforced. A network connection alone does not establish a user’s entitlement.
02
Make tools, resources and prompts recognisable
Tools describe callable functions with inputs and results. Resources provide context a client can read, such as an approved definition document. Prompts are reusable instruction templates for a task. Available capabilities depend on the server and support in the host. Do not design an all-purpose function when a few focused tools suffice. Example: a hypothetical planning application provides a tool for weekly capacity, a resource containing capacity definitions and a prompt for a weekly review. The prompt does not determine access rights. A user without departmental permissions must not receive that department’s staffing details through a differently worded question either.
03
Design contracts and error handling
For each tool, define required parameters, permitted values, result fields and error codes. Validate inputs again on the server; a well-designed input screen does not control direct calls. Agree how missing data, expired permissions and source failures are represented. An empty result must be distinguishable from a failed query. Set maximum execution time, concurrency and result size according to the underlying source. Returning fewer rows alone does not prevent expensive computation. Versioning helps prevent a changed field silently acquiring a different meaning. Also test older clients and repeated requests so that recovery attempts do not create unlimited additional load.
04
Separate read access from permission to change data
Enforce a read-only setup through server checks and restricted database or source permissions, not a prompt that prohibits changes. Treat any write tools as a separate design requiring explicit permission for the specific action. Within the transaction, recheck authority, current state and business rules before committing. Define what happens with duplicate requests and conflicting changes. Example: a hypothetical reservation tool may book capacity only after the user confirms the proposal and execution checks that capacity is still available. An earlier read is insufficient evidence. Return an understandable error on conflict rather than silently booking an alternative.
05
Make processing and operations visible
Choose an appropriate local or remote connection setup and assess authentication, transport and secrets management for that situation. MCP does not guarantee that information stays within your environment. When the host sends context to an external model provider, external processing takes place there; assess data selection, terms and retention accordingly. For operations, preferably record identity, tool name, duration, status and a correlation identifier. Avoid sensitive inputs, complete results and access tokens in logs. Determine who can read records and when they are deleted. Test access revocation and source failure before onboarding users, and appoint an owner to follow up incidents and contract changes.
06
Place the server above a clear data foundation
ENABLE brings the data foundation, integration and dashboards together: source data receives structure and definitions for reusable analysis. An MCP server can connect to this where the chosen implementation supports it. This is not a promise that a particular ENABLE connector or host integration is available. First discuss sources, ownership, freshness and desired tools. Then compare tool output with an existing dashboard calculation and explain differences in filters or refresh timing. This lets you assess not just whether a connection returns an answer, but whether the execution layer uses the same business meaning. Start small and expand only after functional and authorisation tests.
Frequently asked questions
Is an MCP server itself an AI model?
No. The server exposes capabilities through the protocol; a model processes context within the chosen host environment.
Does every source need its own server?
Not necessarily. Set boundaries according to ownership, permissions, maintenance and failure impact, not simply the number of databases.
Does a prompt make a tool read-only?
No. The server and underlying source must technically prevent changes for the identity being used.
How do you start an assessment?
Choose one task, define inputs and permissions, and test normal requests, denials and failures before scaling up.
Technical documentation
Discuss your question with Data Analytics
Which sources, users and checks does your application need? Discuss your question in an ENABLE demo.
Meet our team