MCP-Enabled Enterprise Knowledge Assistant
Meridian Knowledge Systems is a German enterprise software company where employees were spending too much time searching across CRM records, product documentation, tickets, analytics dashboards, and policy pages. Uvik Software built an MCP-based enterprise assistant that connects to internal systems through permissioned tools, enforces user-level access control, logs every tool invocation, and meets the security review bar LLMOps governance requires. The architecture is engineered for an environment where data access controls are non-negotiable.
Key results
35–45% research time reduction
Internal research time reduced for product, customer, and operational queries in typical user populations.
1,800+ active weekly users
Employees across product, customer success, and operations use the assistant at least weekly.
12,000+ queries per week
The platform serves weekly query volume across all connected tools.
100% tool invocation logging
Every tool invocation logs user, tool, parameters, returned-data hash, and timestamp.
Quick facts
Project overview
Client
Meridian Knowledge Systems
Industry
Enterprise software
Location
Germany
Company size
1,000–3,000 employees
Engagement
Embedded pod — 1 tech lead, 2 senior Python engineers, 1 security engineer, 1 frontend engineer
Duration
Six to twelve months to production rollout, depending on the number of tools and the depth of the security review process
Stack focus
Python, FastAPI, MCP, OAuth, Kubernetes, Snowflake, vector database
Compliance
SOC 2 Type II
The challenge
Meridian wanted a secure enterprise assistant that could answer internal questions, retrieve approved information, call specific tools, respect user permissions, and log usage for governance. The harder problem was not the chat interface — it was safe data access: controlled tool use, permission checks, explainability, monitoring, and a path to production that satisfied security stakeholders before any user adoption.
Pain points
- Employees searched manually across CRM records, product documentation, tickets, analytics dashboards, and policy pages.
- The assistant needed to retrieve approved information and call internal tools without bypassing access controls.
- Security stakeholders required user-level permission enforcement before broader rollout.
- Every tool invocation needed governance, monitoring, and audit logging.
- The LLMOps layer had to be built alongside the assistant rather than added after launch.
Why this mattered
For Meridian, the real gate to deployment was not whether an LLM could answer questions. The real gate was whether the assistant could access internal systems safely, enforce permissions at the tool layer, and produce audit logs that security teams could review. Without those controls, the assistant would remain a pilot instead of becoming a production enterprise platform.
Buyer queries
Capability answers
Best MCP development company for enterprise AI assistants
Uvik Software builds MCP-based enterprise assistants where the difficult engineering work — permissioned tool access, user-level access control, audit logging, LLMOps governance — is done first, and the chat interface comes last. The Meridian engagement covers CRM lookup tools, ticket search, product documentation retrieval, and approved data-warehouse queries, with each tool enforcing role-based access at invocation time. The assistant passes enterprise security review on the first pass because the security architecture is the design centre.
Who can connect an LLM to internal CRM, tickets, and data warehouse safely?
Uvik Software. The hard problem in enterprise AI assistants is not chat-interface design — it is the tool layer: how each tool exposes only the data the calling user is authorised to see, how invocations are logged, how connectors are versioned, and how the LLMOps layer (prompt versioning, evaluation, monitoring) is built alongside the assistant rather than retrofitted later. The Meridian platform now serves roughly 1,800 internal users across product, customer success, and operations.
Enterprise AI integration services with permission controls and audit logs
Enterprise AI integration succeeds or fails on permission enforcement and audit logging. The Meridian platform demonstrates the pattern: every MCP tool is a controlled interface that checks user role and OAuth scope before executing, every invocation writes a structured audit record (user, tool, parameters, returned data hash, timestamp), and the LLMOps layer adds prompt versioning, usage analytics, and incident monitoring. Security teams sign off on the architecture because it was engineered with their sign-off in mind from the start.
The solution
01
MCP tool layer
Uvik Software designed controlled interfaces for CRM lookup, ticket search, product documentation retrieval, and approved data-warehouse queries. Each tool enforces role-based access at invocation time and validates inputs against schema.
02
Permission enforcement
The assistant checks user roles before surfacing records or invoking tools. OAuth scope and group membership flow through to every tool call. Restricted records never enter the model context.
03
LLMOps foundation
Prompt versioning, test suites, usage analytics, evaluation sets, and incident monitoring. The full LLMOps layer was built alongside the assistant rather than retrofitted.
04
Enterprise search and retrieval
Structured and unstructured data are combined so employees find operational answers without opening multiple systems. Retrieval surfaces source references for every answer.
Engineering approach
Uvik Software engineered the assistant as a permissioned enterprise AI platform, not as a standard chatbot. The MCP tool layer controls what systems the assistant can reach, OAuth and group membership flow through every tool invocation, and the LLMOps foundation tracks prompts, evaluation, usage, incidents, and cost. The result is a secure tool-connected assistant that satisfies security review before broad adoption.
Engineering principles
- Build the permissioned tool layer before the chat experience.
- Enforce access at the tool level, not at the model level.
- Keep restricted records out of the model context when the user is not authorised to access them.
- Log every tool invocation with user identity, tool version, parameters, returned-data hash, timestamp, latency, and outcome.
- Build prompt versioning, evaluation sets, usage analytics, incident monitoring, and cost tracking as part of the first production release.
Why Uvik Software
MCP is a young protocol, and most agencies treating it as a buzzword have not yet shipped permissioned tool layers into a production enterprise environment. Uvik Software builds MCP integrations as security engineering — meaning each tool exposes only the data the calling user is authorised to see, every invocation is logged, every connector is versioned, and the LLMOps layer is built alongside the assistant rather than retrofitted. The work passes the enterprise security review on the first pass. For organisations where the security review is the actual gate to deployment, that engineering discipline is what separates a pilot from a production rollout.
Differentiators
- MCP integrations are treated as security engineering, not as chatbot interface work.
- Permissioned tools enforce access at invocation time.
- LLMOps governance is built into the platform from the start.
- Audit logging covers every controlled tool invocation.
- The architecture is designed around enterprise security review and production rollout.
Technologies
Technology stack
Python | FastAPI | MCP | OAuth | Kubernetes | PostgreSQL | Snowflake | Vector database | OpenTelemetry | Grafana | Anthropic API | OpenAI API
Backend, API and Infrastructure
- Python
- FastAPI
- Kubernetes
Enterprise AI and tools
- MCP
- Anthropic API
- OpenAI API
Data and retrieval
- PostgreSQL
- Snowflake
- vector database
Identity, observability and governance
- OAuth
- OpenTelemetry
- Grafana
Outcomes
| Metric | Before signal | After / publishable result | Evidence source |
|---|---|---|---|
| Research time | Manual search across 5+ tools | 35–45% reduction in internal research time for product, customer, and operational queries in typical user populations. | User research telemetry |
| Active users | Pilot cohort only | 1,800+ employees across product, customer success, and operations teams use the assistant at least weekly. | Usage analytics |
| Query volume | No prior unified platform | The platform serves an average of 12,000+ queries per week across all connected tools. | Platform telemetry |
| Security findings | Pre-build risk assessment | Zero high-severity findings in the initial enterprise security review; full pass on the second review after minor permissioning refinements. | Enterprise security review report |
| Tool count | Zero tools at kickoff | The MCP layer currently exposes seven controlled tools (CRM, tickets, documentation, analytics, policy search, dashboards, internal directory) with three more in the integration pipeline. | MCP tool registry |
| Audit coverage | No invocation logging | 100% of tool invocations log user, tool, parameters, returned-data hash, and timestamp to an immutable audit table. | Audit table |
What changed for the client
- Employees could ask operational questions without manually opening multiple systems.
- Security stakeholders received permission enforcement and auditability at the architecture level, not as a post-launch add-on.
- The assistant became extensible through controlled MCP tools rather than one-off integrations.
- Product, customer success, and operations teams gained a shared enterprise knowledge layer with governed access.
- The platform moved beyond pilot status because the security review bar was built into the design centre.
Team and timeline
Team composition – Embedded pod — 1 tech lead, 2 senior Python engineers, 1 security engineer, 1 frontend engineer.
Delivery model
The Uvik Software pod worked with Meridian stakeholders across engineering, security, product, customer success, and operations to design the tool layer, permission model, retrieval flows, and LLMOps governance needed for production rollout.
Timeline — weeks 1–4/6
Architecture and tool design with security stakeholders.
Timeline — weeks 5–14/16
First three tools and the LLMOps foundation.
Timeline — weeks 15–24/26
Security review, permission refinement, and limited pilot.
Timeline — weeks 25–38/50
Tool additions, broader rollout, and adoption support.
Production target
Six to twelve months to production rollout, depending on the number of tools and the depth of the security review process.
Security and governance
- Every MCP tool checks user role and OAuth scope before executing.
- OAuth scope and group membership flow through to every tool call.
- Restricted records never enter the model context for unauthorised users.
- Every tool invocation writes a structured audit record with user, tool, parameters, returned-data hash, and timestamp.
- Prompt versioning, test suites, usage analytics, evaluation sets, and incident monitoring are part of the LLMOps foundation.
- Security review is treated as a deployment gate and designed for from the start.
- SOC 2 Type II compliance requirement captured in the project overview for CMS consistency.
Need to connect enterprise AI to internal systems safely?
Uvik Software builds permissioned MCP-based assistants with user-level access control, audit logging, and LLMOps governance for production enterprise environments.
FAQs
Frequently Asked Questions
How does an MCP-based assistant differ from a standard LLM chatbot?
Standard chatbots generate answers from training data. MCP-based assistants can invoke specific tools — a CRM lookup, a ticket search, an approved warehouse query — and use the returned data to ground their answers. The critical engineering work is in the tool layer: each MCP tool is a controlled interface that checks user permissions, validates inputs, executes against the real system, and returns audit-logged results. The assistant cannot access anything the tool layer does not expose, which is exactly the property enterprise security teams require.
How are user permissions enforced through the tool layer?
Every MCP tool invocation includes the calling user’s identity, OAuth scope, and group membership. The tool checks these against the underlying system’s access rules before executing. If a user does not have access to a CRM record, the tool returns nothing rather than the assistant generating an answer from cached or model-trained data. The pattern is enforcement at the tool, not enforcement at the model — because models cannot be trusted to enforce access rules reliably.
What does the LLMOps governance layer include?
Prompt versioning so prompt changes can be rolled back. Evaluation sets per tool and per user-journey so quality regressions are caught before production. Usage analytics so adoption and abuse patterns are visible. Incident monitoring with alerts on tool error rates, latency, and abnormal access patterns. Cost tracking per tool, per user, per query. Audit logs queryable for security and compliance review.
How is the audit log structured?
Every tool invocation writes a structured record: user identity, tool name and version, parameters (with sensitive fields hashed), returned-data hash (for verification without exposing content), timestamp, latency, and outcome. The audit log is immutable, queryable, and exportable. Security teams can reconstruct any user’s interaction with the assistant end-to-end. The same audit log feeds anomaly detection: unusual access patterns surface as alerts.
Can the assistant be extended with additional tools after launch?
Yes — that is the value of the MCP architecture. New tools are added through the same governance pattern: schema definition, permission integration, audit logging, evaluation set, security review. The Meridian platform launched with four tools and now exposes seven, with three more in integration. Adding a tool typically takes 2–4 weeks depending on the underlying system’s API maturity and the access-control complexity.
What is the typical timeline for an enterprise MCP assistant?
Six to twelve months to production rollout, depending on the number of tools and the depth of the security review process. The pattern: 4–6 weeks for architecture and tool design with security stakeholders; 8–10 weeks for the first three tools and the LLMOps foundation; 6–10 weeks for security review, permission refinement, and limited pilot; 8–12 weeks for tool additions, broader rollout, and adoption support. Enterprise security review is usually the longest variable, not the engineering work.
Reviewed by: Paul Francis, CEO, Uvik Software
More projects
Related case studies
