At work, we use several systems that contain the information people need to answer everyday engineering questions: documentation, source control, wikis, and databases. The problem is not that the information is missing. The problem is that it is spread across different interfaces, APIs, and permission models.
I have been building Model Context Protocol servers to put a consistent interface in front of those systems. These are workplace tools, not toy integrations. They need to handle authentication, multiple deployment models, compatibility, failures, and the consequences of giving an assistant access to real data.
The systems behind the interfaces
BookStack MCP exposes the BookStack API through 20 read-only and 20 write tools. It covers books, chapters, pages, shelves, attachments, comments, exports, recent changes, and the recycle bin. Write operations are disabled by default. It supports both stdio and Streamable HTTP transports.
GitLab MCP is designed for GitLab installations across Free, Premium, and Ultimate tiers. It uses personal access tokens and supports both stdio and Streamable HTTP. The deployment model matters: a developer using an IDE, a shared LibreChat service account, and a multi-user deployment using the calling user’s token have different security requirements.
MediaWiki MCP supports multiple named wikis and uses the modern REST API alongside the Action API. It handles page operations, search, files, categories, revisions, recent changes, links, pagination, and retry behavior. Authentication uses scoped bot passwords rather than a user’s primary password.
MySQL MCP goes beyond sending arbitrary SQL to one database. It supports multiple MySQL sources, source classification, federated queries, relationship detection, caching, connection pooling, and read-only query validation. That makes it useful for cross-system investigation, but also raises the bar for configuration and access control.
The hard part is the boundary
The protocol is the easy part. The engineering work is deciding what an assistant is allowed to see and do.
For most deployments, read-only access is the correct starting point. Write tools should be explicit, separately permissioned, and easy to audit. Credentials should be scoped to the integration, stored outside source control, and rotated without rebuilding the application.
Transport changes the threat model as well. A local stdio process has a different boundary than a long-lived HTTP service shared by multiple users. Binding an HTTP server to a network interface, accepting forwarded requests, and selecting an authentication model are operational decisions—not installation details.
What production use exposes
Real use finds problems that a demo does not. API responses are inconsistent. Some clients expect strings where others send numbers. A query that is safe for one database is expensive on another. A documentation page authored in a visual editor may not have a useful Markdown representation. A service that works locally may need a different transport, secret store, or network policy when deployed for a team.
Those details are why the projects include validation, compact responses, pagination, retries, caching, deployment examples, and compatibility notes. The goal is not to make an assistant sound capable. The goal is to make the underlying system easier to use without making it less controlled.
Why build this instead of waiting for a platform feature?
Because the systems already exist and the workflows already exist. A useful integration can be small, owned by the team that understands the data, and changed when the real environment changes. It also makes the assumptions visible: which API is used, which credentials are required, which operations are exposed, and what happens when the dependency is unavailable.
That is the pattern I keep coming back to: put a narrow, well-tested interface around a system people already depend on. The model can change. The boundary and the operational discipline still matter.
Current as of September 2026. These projects are used in workplace environments; deployment details and compatibility should be checked against the current repository documentation.
Leave a Reply