Develop MCP servers.
Connect systems with purpose.
AI can do more than answer questions: it can work with existing systems through defined functions. DAXS develops suitable MCP servers and adapters, with clearly defined tools, limited permissions and verifiable results.
An MCP server exposes defined functions to AI applications.
An assistant may need to retrieve a ticket status, search authorised documentation or create a prepared entry. It needs clearly described, limited access for each task. DAXS develops suitable MCP servers and the underlying API connections for existing business systems.
The Model Context Protocol describes how AI applications can use tools, data resources and prepared prompts, among other capabilities. An MCP server acts as a technical adapter. A well-chosen tool name alone does not make it secure or turn it into an autonomous agent.
Conventional API
An application calls a defined function in another system. The data model, permissions, validation and error handling are designed for that access.
MCP integration
A compatible AI client can use described functions and resources through a common protocol. Specific approvals and implementation in the target system remain separate responsibilities.
AI agent
An application combines a model, state and tools to perform several steps. It needs a bounded task, stopping conditions and traceable control over its actions. An agent can use MCP or other APIs.
The client, interface and target system each enforce their own controls.
The AI application proposes a tool call. The MCP server checks identity, the permitted function and inputs. The target system also enforces its own access rules. Critical actions require a specific approval before execution.
The diagram shows an example architecture for a custom integration. Compatible client, SDK and protocol versions are selected and tested before implementation.
The task determines the data and actions.
An interface to a ticketing system does not need to expose the entire database. One tool might return exactly the fields needed for an authorised status enquiry. Another creates only a draft. General shell, SQL or administration functions would create an unnecessarily broad scope for these tasks.
| Type | Example tool | Key check |
|---|---|---|
| Read access | Retrieve a ticket status, search authorised documentation or check a technical condition. | The user may view the specific object; return only the required fields, a limited result set and no data belonging to another tenant. |
| Limited write access | Prepare a draft reply or structured internal note. | Validate fields and permitted content, clearly mark drafts, control retries and return a traceable result. |
| Critical action | Initiate an agreed change in a production system. | Additional approval bound to the action and target object; recheck permissions immediately before execution and define limits and a recovery route. |
Even a read tool can disclose confidential data. Read-only access therefore still needs authorisation. For write calls, we also plan idempotency, error states and handling of uncertain outcomes: a timeout does not prove that an action was not executed.
Successful authentication does not grant permission to every object.
We distinguish authentication in the AI client, authorisation at the MCP server and permissions in the target application. User, group and tenant context come from a trusted identity. The model must not assign its own role or permitted data scope through a text input.
A remote HTTP integration needs an appropriate authorisation design. Tokens must be intended for the relevant service and checked for validity and scope. Credentials for downstream systems are protected and limited for their specific destination. Arbitrarily forwarding a client token does not provide universal system access.
A local process connection has different boundaries from a remote business service, including the program being launched, its origin and its operating system permissions. Easy local execution does not replace a review of the program or its data access. For both approaches, we agree on permitted connections and technical responsibilities.
MCP is a protocol, rather than a complete security architecture.
Server logic, target system permissions, protected credentials, network rules and verifiable approvals enforce the actual limits. The implementation depends on the client, data, actions and operating model.
The boundaries also apply to unsuitable model suggestions.
A document, ticket or tool result may contain manipulated instructions. That content is treated as data. It must not grant new permissions or justify an otherwise prohibited action. Prompt instructions can support the application; binding controls operate outside the model.
Inputs and destinations
Validate types, permitted values, object references, paths and result sizes on the server. Limit permitted APIs and network destinations; avoid freely assembled commands and uncontrolled URL requests.
Actions and approvals
Make call scope and side effects understandable. Bind critical approvals to the specific operation, limit their validity and verify them before execution. Define cancellation and retry rules.
Operations and traceability
Provide rate limits, time limits, error handling and purpose-specific logs. Keep credentials out of model context and diagnostic output. Investigate unusual access and make credentials revocable.
We test normal workflows alongside prohibited object access, manipulated content, expired permissions, duplicate calls and denied approvals. This reduces risks; a general promise to prevent every prompt injection would be unrealistic.
Start with a manageable function.
We review the target application, existing APIs, user roles and required fields. This defines a limited tool catalogue with clear inputs and results. A read pilot can show whether the integration helps in everyday work; write steps can be added and tested separately where needed.
- Define the task: which problem, which objects and which users?
- Develop the interface: connect the target API, describe the tool and implement permissions and error handling.
- Validate in practice: test permitted and prohibited cases, approvals and retries.
- Handover with support: document the solution, access management, version maintenance and responsibilities.
DAXS can deliver this as custom development and integration. A straightforward data query may also suit a conventional API or script. We discuss the appropriate scope using your existing systems.
A specific desired function, the application involved, available API documentation and an anonymised example. Credentials and confidential customer data do not belong in a public enquiry.
We clarify this in our conversation.
How does an API differ from MCP?
An API exposes a system’s functions. MCP defines a common way to offer tools and context to compatible AI applications. An MCP server can use existing APIs; their permissions and business rules remain necessary.
Does every automation need an AI agent?
No. A fixed import or clearly defined calculation is often simpler to implement with a script or direct API connection. An agent becomes relevant when variable tasks need a flexible choice of steps.
Can an MCP tool make changes itself?
Yes, when the business requires it and technical safeguards are in place. Read functions, limited changes and critical actions are treated separately. Approvals, target permissions, input validation and traceable results are part of each function.
Is signing in to the AI service sufficient authorisation?
No. The server must verify the caller and their permissions; the target system must also permit access to the specific function and object. A tool call must not create rights the user would not otherwise hold.
How should a useful pilot begin?
With a clear benefit and a few limited tools, initially read-only where possible. We define success criteria and test unauthorised access, problematic content, timeouts and repeated calls before expanding write functions.
Tool access does not itself authorise unrestricted operation.
An agent on a Linux system can use APIs, local tools or external services. Its service identity, limited file access, process isolation, permitted network destinations and securely managed credentials are planned separately. A local agent is not automatically offline; every external call belongs in the data flow. Model changes, tool failures, runtime and cost limits, and a traceable abort mechanism are also tested.
Let's discuss your use case.
What should become easier, which data is involved and which systems are already in place? We use this to develop a practical starting point and a manageable next step.