In spring 2026, an "in-house MCP server fleet" became a realistic option
Since entering April 2026, the option of "running an in-house MCP server fleet" has rapidly gained traction as a way to open internal enterprise workflows to AI agents. Several developments have converged.
- April 2–3, 2026: Approximately 1,200 attendees gathered at the New York Marriott Marquis for MCP Dev Summit North America 2026. Discussions focused heavily on enhancing the protocol's "production readiness," including MCP gateways, gRPC support, and observability.
- April 9, 2026: Google officially added MCP support to Colab, enabling AI agents to run by calling MCP servers directly from notebooks.
- April 7, 2026: On Zenn Trending, a hands-on article titled "Opening Internal Operations to AI — Complete Reveal of Our In-House MCP Server Fleet!" went viral, sparking buzz among domestic IT systems and DX leadership.
Since the core concepts of MCP itself are covered in our Complete MCP Guide, anyone asking "What is MCP in the first place?" should read that first before returning here. This article serves as a hands-on guide for designing, building, and operating an in-house MCP server cluster after becoming familiar with MCP.

Why "in-house MCP"? — three primary drivers
When simply using public MCP servers or SaaS vendor-provided MCPs should suffice, why are more companies going through the trouble of building their own MCP servers? There are three main reasons.
- Data Sovereignty: When AI agents access internal databases and file servers, companies want the intermediary relay points under their own control. From the perspectives of auditing and permission governance, this makes obtaining IT approval significantly easier.
- Avoiding Vendor Lock-in: Building integrations tied exclusively to "Claude only," "Cursor only," or "Copilot only" means starting over from scratch whenever you switch AI providers. Positioning MCP as an intermediary abstraction layer preserves independence between the AI tier and business applications.
- Workflow-Specific Tool Design: Proprietary internal workflows (approvals, internal terminology, unique KPIs) that generic MCP servers cannot handle can be cleanly abstracted.
Minimal setup — the first four MCP servers you should build
Attempting to "turn every internal system into an MCP server" overnight is unrealistic. The following set of four servers represents the sweet spot common to most enterprises.
| # | MCP Server Name (Example) | Integration Target | Use case |
|---|---|---|---|
| 1 | kb-mcp (Knowledge Search) | Internal Wiki, Notion, Confluence, SharePoint | Search and summarize past meeting minutes, specifications, and contract templates |
| 2 | crm-mcp (Customer Info Lookup) | Salesforce, HubSpot, proprietary CRM | Meeting preparation, generating customer history summaries |
| 3 | ticket-mcp (Development & Support) | GitHub Issues、Jira、Zendesk | Bug filing, duplicate ticket detection, support history summarization |
| 4 | ops-mcp (Workflow Automation) | Slack, Google Workspace, Spreadsheets | Regular report generation, notifications, data aggregation |
We recommend TypeScript or Python as implementation languages. With over 500 pre-built MCP servers already published by the community, there is no need to write everything from scratch. The practical strategy in 2026 is: "Start from pre-built → Fork for company requirements → Build internal implementation only for the auth layer."
Sample: Minimal skeleton for kb-mcp (TypeScript)
// kb-mcp: 社内ナレッジ検索 MCP サーバーの最小例
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { z } from "zod";
const server = new Server(
{ name: "kb-mcp", version: "0.1.0" },
{ capabilities: { tools: {} } },
);
server.tool("search_wiki", {
description: "社内 Wiki を全文検索し、関連度順に返す",
inputSchema: z.object({
query: z.string(),
limit: z.number().default(5),
}),
handler: async ({ query, limit }) => {
// ① 認証コンテキストを取得(誰がリクエストしたか)
// ② 権限に応じてインデックスを絞り込み
// ③ ベクトル検索 + BM25 のハイブリッドで検索
// ④ 結果を構造化して返却
return { content: await searchInternalWiki(query, limit) };
},
});
await server.connect();
With this skeleton of barely 20 lines, you can already "write code while referencing your internal wiki" from Claude Code or Cursor 3. The barrier to entry is surprisingly low.
Operational rules that satisfy IT systems — a five-item checklist
While MCP is powerful, an architecture that cannot explain "who executed what, when, and under which permissions" will definitely get stuck during budget approval, audits, or incident response. Ensure you agree on the following five items before building an in-house MCP setup.
| # | Item | Decision Item |
|---|---|---|
| 1 | Authentication Policy | Employee SSO integration (Okta / Entra ID / Google Workspace) |
| 2 | Permission Model | Role- and attribute-based controls at both the MCP tool level and data row level |
| 3 | Audit Logging | Persisting "who called which tool, when, and with what input" |
| 4 | Rate Limiting & Cost Management | Per-tool call caps, LLM token ceilings, alerting |
| 5 | Prohibited Task List | Prohibited use cases such as HR evaluations, external transmission of personal data, and legal judgments |
These five items connect directly to the operational AI rollout governance introduced in ChatGPT Enterprise Organizational Rollout Roadmap. Utilizing the same framework across both operational AI and development AI is the secret to minimizing operational overhead.
Requirements to cover when ordering from a development firm
If your company lacks the internal resources to write an MCP server cluster, outsourcing to a software development agency is the standard route. In that scenario, the minimum items you should include in your RFP (Request for Proposal) are as follows. Ordering with ambiguous specifications will almost certainly cause disputes later.
- List of target systems to connect (internal wiki, CRM, ticket management, etc.) and access protocols (REST / GraphQL / direct DB)
- Authentication and audit requirements (SSO, roles, audit log retention periods, SIEM integration requirements)
- Target AI clients (from where calls will originate: Claude Code, Cursor 3, GitHub Copilot CLI, ChatGPT Enterprise, etc.)
- Observability (whether integration with LLM observability platforms such as Langfuse is required)
- Deliverables (MCP server source code, OpenAPI/MCP manifests, operations manuals, training materials)
The latest developments on the AI integration side are also compiled in GitHub Copilot CLI Rubber Duck Mode and Cursor 3 Comprehensive Comparison, so please leverage them when selecting your target AI client.
Conclusion
- In spring 2026, the confluence of the MCP Dev Summit, Google Colab's MCP support, and hands-on Zenn articles has made operating an in-house MCP server fleet a practical option.
- The first four you should build are kb-mcp, crm-mcp, ticket-mcp, and ops-mcp. Starting with pre-built servers → forking → implementing your auth layer is the fastest path.
- IT departments must reach prior agreement on five key areas: authentication, permissions, auditing, rate limiting, and prohibited tasks.
- When outsourcing, explicitly specify the list of connection targets, auth requirements, target AI clients, observability, and deliverables in your RFP.
At GleamHub, we provide end-to-end support for designing, implementing, and running MCP servers, including internal guideline development. If your company has introduced Claude Code or Cursor but is unable to unlock their full potential due to a lack of internal data connectivity, please reach out to us.



