Who is Michel Fritzsch?

Michel Fritzsch is an AI expert and technical consultant from Eisenach. After his apprenticeship he was technical consultant at BSS Business Software Solutions GmbH from 2014 to 2018, and at Join GmbH since September 2018 – with a career path from system administrator via enterprise search (Sinequa) to generative AI, RAG and CompanyGPT.

What is Enterprise Search?

Enterprise search covers large, heterogeneous data estates – from full-text indexing and semantic search to AI-powered answers (RAG). Source connectivity, access rights, relevance and stable operations are critical.

What Sinequa experience does Michel Fritzsch bring?

As Sinequa Certified Professional and Architecture Expert he supports implementations, relevance tuning, scaling and operations. Typical topics: connectors, index architecture, semantic search, NLP enrichment and RAG integration with ACL safety.

What is Retrieval-Augmented Generation (RAG)?

RAG connects large language models with enterprise knowledge via retrieval – for more accurate answers from your own documents instead of general model knowledge. In enterprise environments sources, chunking, re-ranking and citations are decisive.

What matters most for RAG in enterprise environments?

ACL-compliant retrieval, reliable sources, evaluation with golden queries, monitoring of cost/latency and clear guardrails against hallucinations. RAG does not replace a solid search architecture – it builds on it.

CompanyGPT is Join's corporate AI platform – often described as "ChatGPT for business". It connects LLMs with internal knowledge in a GDPR-compliant way with governance. Michel Fritzsch guides use cases from idea to rollout. Learn more at ki.join.de/loesungen/company-gpt/

How does a typical engagement work?

It often starts with a readiness or use-case workshop, followed by architecture/pilot, then rollout and operational support. The interactive tools on this site (readiness, use-case finder, incident triage) serve as a structured conversation starter.

What experience does Michel Fritzsch have?

Technical consultant at BSS Business Software Solutions GmbH (2014–2018), then at Join GmbH (since 2018): foundation in system administration and integration, 10+ years in enterprise search with Sinequa, today AI expert for RAG, generative AI and corporate AI platforms.

Which industries and organization types does he work with?

Experience with mid-market companies, enterprises and public sector organizations – each with different governance, source and operations requirements. Anonymized project profiles are in the “Selected project profiles” section.

What system administration experience does he have?

The foundation of his expertise: training as IT specialist for system integration and years of practice in server, network, monitoring and troubleshooting scenarios – the base for stable search and AI platforms.

Is Michel Fritzsch also a trainer?

Yes – he trains IT apprentices at Join GmbH and teaches practical knowledge in system administration, system integration and enterprise IT.

Does he offer workshops or training?

Within projects and as a trainer he teaches enterprise search and sysadmin fundamentals. The apprenticeship roadmap and sysadmin cheat sheet on this site reflect his teaching approach.

How can I get in touch?

Exclusively via LinkedIn – for readiness assessments, architecture discussions, RAG design or incident reviews.

Where is Michel Fritzsch based?

Eisenach, Thuringia, Germany – working as an AI expert on generative AI, RAG, CompanyGPT and enterprise search, remote and on-site by arrangement.

Model Context Protocol (MCP): The USB Standard for AI Tools

Last week I sat in an architecture review for a CompanyGPT rollout. The question wasn't "which model" but: how do we connect Confluence, Jira, the ticketing system, and our enterprise search — without building a separate adapter for every host-and-data-source combination? That's exactly where Model Context Protocol (MCP) shows up.

I've seen this pattern across ten years of enterprise search: every application builds its own connectors, auth, and error handling. MCP aims to standardize that for the AI layer. Not a buzzword — a genuinely useful approach if you know where it helps and where it doesn't.

Over the past months I've tested MCP in IDE agents (Cursor), pilots with Claude Desktop, and first internal agent prototypes. The common thread: MCP saves integration work when switching hosts. The work lives in the server — and that's where responsibility for auth and data quality begins too.

What MCP Is — and What It Isn't

MCP is an open standard for communication between AI applications ("hosts") and external data sources or tools ("servers"). Initiated by Anthropic, now community-driven. Think of MCP as a uniform plug: a host (Cursor, Claude Desktop, your own agent app) speaks MCP; servers expose resources (readable context), tools (executable actions), and prompts (templates).

MCP is not a replacement for RAG pipelines, not a replacement for access control, and not a magic fix for agents that "can do everything." It standardizes connectivity — not data quality or prompt craft.

Architecture in Practice

┌─────────────┐     MCP       ┌──────────────┐
│  MCP Host   │ ◄───────────► │  MCP Server  │
│ (IDE, Chat) │  JSON-RPC /   │ (Wiki, DB,   │
│             │  stdio / SSE  │  tickets, …) │
└─────────────┘               └──────────────┘
       │                              │
       ▼                              ▼
   LLM / UI                     APIs & data

Three concepts I actually use in projects:

Resources — files, records, search results as readable context
Tools — run search, create ticket, send query
Prompts — reusable templates for recurring tasks

MCP vs. REST vs. Function Calling

Aspect	REST API	Function Calling	MCP
Discovery	Manual OpenAPI	Schema per model/provider	Standardized via MCP
Reuse	Per application	Per model provider	Across hosts
Transport	HTTP	Embedded in model request	JSON-RPC, stdio, SSE
Typical use	Backend integration	Single chat with tools	Agent UIs, IDEs

Function calling happens inside the model request. MCP sits in front as a layer between host and systems. An MCP server for your internal wiki can work in Cursor, Claude Desktop, and a custom CompanyGPT app — without three separate integrations.

Enterprise Scenarios That Make Sense

From my perspective, these entry points pay off:

Knowledge access: MCP server on enterprise search (Sinequa, Elasticsearch, SharePoint index)
Development: GitHub or Jira MCP in IDE agents for code and ticket context
IT ops: servers for monitoring data, runbooks, log snippets
Compliance: log tool calls at the server, enforce permissions there

What I don't recommend: rolling out ten MCP servers before one runs reliably. Or selling MCP as a replacement for a thoughtful RAG pipeline.

A Concrete Example: Wiki Server

Imagine an MCP server connected to your Confluence or wiki API:

Resource wiki://page/{id} — returns page content as Markdown
Tool search_wiki — parameters query, limit — returns hits with IDs
Tool get_page — parameter page_id — loads a page

The host (e.g. Cursor) calls search_wiki, gets IDs, loads relevant pages as resources. The LLM works with real context — not guessed URLs. The server enforces the same ACLs as the wiki API under the hood: if the user can't read the page, no content returns.

Such a server is buildable in one to two weeks — if the wiki API is well documented. The fine work is in pagination, rate limits, and error messages the LLM can understand.

Transport: stdio, SSE, HTTP

MCP supports multiple transports. Locally in the IDE I often use stdio — simple, no network exposure. For central servers in the enterprise, SSE or HTTP behind a reverse proxy with OAuth. stdio servers on every laptop don't scale; a central MCP server with auth can — if latency and availability fit.

Security — the Part Many Skip

MCP solves integration, not authorization. In enterprise projects I still need:

Authentication host ↔ server (OAuth, mTLS, scoped API tokens)
Least privilege: each MCP server only the rights it needs
Audit logs for every tool call (who, when, which tool, which result)
Dev/prod separation: which servers are allowed in which environment

An MCP server with write access to Jira without role checks is a ticket-spam risk — regardless of how elegant the protocol is.

How MCP Fits My Stack

I deliberately combine MCP with other layers:

LiteLLM for model routing, budget, and keys
n8n for deterministic process automation (workflow, not agent)
RAG backend for document retrieval with ACL and evaluation

MCP complements these building blocks. It doesn't replace them. An agent in the IDE searching a wiki via MCP still needs clean index data. An n8n workflow closing tickets doesn't need an MCP server — REST is enough.

When I Don't Use MCP

Not every integration needs an agent. Batch imports, nightly sync, fixed reports — that stays with n8n or classic ETL jobs. MCP pays off when an interactive host dynamically decides which tool it needs when. For deterministic flows, a workflow is more readable, testable, and cheaper to operate.

Also: an MCP server delivering the same data as your RAG index but without hybrid search and evaluation reproduces the same quality problems — just over a different protocol.

What I Do Differently in Projects

One server first. I start with the most-used source — internal wiki or ticketing. Measure usage, error rate, latency. Only then the next server.

No agent without boundaries. Every MCP server gets a clear tool list. "Can do everything" doesn't exist. Write tools only with confirmation or in separate environments.

Same identity as the rest of the system. The MCP server must respect the host user's identity — not access all data as super-admin.

Logging from day one. Who called which tool when is mandatory in regulated environments.

Not every problem is an agent problem. Many requirements I solve faster with n8n and fixed workflows than with an exploring agent.

In regulated environments I also ask: who is accountable for a wrong tool action? With MCP the answer must be in server design — confirmation for write access, clear error text, no silent defaults. An agent that pulls 200 wiki pages into context because the tool has no limit isn't a model problem — it's poor tool design.

Recommendations and Checklist

Define use case: which data source, which host, which tools?
Build or adapt one MCP server with a minimal tool list
Implement auth and least privilege before pilot users land
Enable audit logging
Observe latency and error rate for two weeks
Then scale — more servers, more hosts
In parallel: don't neglect RAG quality and ACLs

Conclusion

MCP is becoming the de facto integration layer for agents and IDE tools in 2026 — not because it's magic, but because connector sprawl otherwise slows every AI project. If you're planning enterprise RAG and CompanyGPT, factor MCP into your architecture: as the standard for tool and context connectivity, not as a shortcut around solid retrieval pipelines.

Questions about agent architecture in your environment? LinkedIn