AI & Developer Tooling

MCP for Software Companies: Giving Your AI Assistant a Company Brain

May 2025 16 min read Jefferson Valandro
MCP AI architecture developer tools LLM context

Your developers use AI assistants every day. They ask questions, generate code, review pull requests, and explore unfamiliar services. The AI answers fluently — but it answers as if your system were a blank-slate generic codebase. It doesn't know that your team calls the payment flow "reconciliation", that services must never call the user service directly but go through the identity gateway, or that the ADR from 2023 explicitly banned a certain ORM pattern due to a production incident. Every developer either carries this context in their head or wastes time re-explaining it in each conversation.

The Model Context Protocol (MCP) changes this. It's a standardized way to connect AI assistants to external data sources and tools — and it gives software companies the primitive they've been missing: a way to make company-specific architecture, patterns, and business knowledge a first-class citizen in every developer interaction with AI.

What Is MCP, Precisely

MCP is an open protocol created by Anthropic that defines how AI models communicate with external context providers. Think of it as USB-C for AI context: a single, standardized interface that allows any compliant AI client (Claude, Cursor, VS Code Copilot, and others) to connect to any compliant server and receive structured tools, resources, and prompts.

An MCP server exposes three types of primitives:

The protocol runs over stdio (for local servers) or HTTP with Server-Sent Events (for remote servers), and the full spec is open-source. This means you can write your own MCP server in any language, deploy it wherever makes sense for your infrastructure, and connect it to any MCP-compatible AI client your developers already use.

The Problem MCP Solves for Development Teams

Consider what happens today when a developer asks an AI assistant a question about your system:

Developer: "How should I call the notification service from my new feature?" AI: "You can make an HTTP call to the notification service endpoint. Here's a generic example using fetch/axios/RestTemplate..." [proceeds to suggest a direct HTTP call that violates your service mesh policy]

The AI isn't wrong in the abstract. It just doesn't know your architecture. It doesn't know that inter-service communication in your platform goes through a service bus, that direct HTTP calls bypass your circuit breakers, that there's a shared SDK for exactly this use case already published in your internal registry, or that the notification service has a quota policy you must respect.

The same problem appears across dozens of interactions every day: code review suggestions that ignore your team's specific quality gates, architecture proposals that re-litigate decisions already captured in ADRs, onboarding questions about domain concepts that have precise definitions in your internal glossary, test patterns that don't match your team's standards.

A company MCP server fixes this by turning your institutional knowledge into context the AI can access on demand.

The Three Pillars of a Company MCP

A well-designed company MCP server exposes three categories of knowledge that together cover the vast majority of what developers need when writing and reviewing code.

1. Architecture Data

This is the structural knowledge of your system: what services exist, how they relate to each other, what they own, and what boundaries cannot be crossed. It includes:

2. Development Patterns

Patterns are the "how we build things here" layer: the conventions, standards, and shared solutions your team has developed over time. Without this, AI-generated code is generic. With it, generated code looks like it was written by a senior member of your team.

3. Business Context

This is the hardest category to maintain but the one that generates the most value for senior work. It bridges the gap between technical implementation and business intent.

What the Developer Experience Actually Looks Like

With a company MCP server connected to their AI assistant, a developer's interactions transform from generic to contextually accurate:

Developer: "I need to send an async notification when an order is confirmed." AI (with company MCP): → [calls get_service_topology("notification")] → [calls get_patterns("async-messaging")] → [calls get_business_rules("order-confirmation")] "In your platform, async communication between services uses the internal event bus. I found the OrderConfirmedEvent schema in your shared event catalog — use that instead of defining a new one. The notification-sdk package already wraps the connection details. Here's a usage example following your standard pattern... Note: per business rule BR-104, order confirmation notifications must be sent within 30 seconds of the state change for compliance reasons. Your circuit breaker configuration defaults to a 60s timeout, so make sure not to use the default retry policy here."

This isn't a hypothetical. It's the direct output of an AI that has access to your service registry, your ADRs, your internal SDK catalog, and your business rules — all through tool calls defined in your company MCP server.

Designing Your Company MCP Server

Building an effective company MCP is less about technology and more about information architecture. The technical implementation is straightforward; the challenge is deciding what to expose and how to structure it so the AI can retrieve the right context at the right time.

Tool Design Principles

Architecture and Data Sources

A company MCP server is typically a thin API layer over your existing knowledge sources. You probably already have most of this data — it just lives in different places:

Knowledge Source → MCP Resource/Tool ─────────────────────────────────────────────────── Confluence / Notion → ADRs, runbooks, patterns Service catalog (Backstage, internal CMDB) → service topology Git repos (README, CODEOWNERS) → ownership, tech stack OpenAPI / AsyncAPI specs → API contracts, event schemas Internal package registry → SDK catalog Jira / Linear → in-flight work context Architecture diagrams → C4 model export

The MCP server itself doesn't need to be the source of truth — it aggregates and normalizes from the sources your teams already maintain. This is critical for adoption: the server adds value without adding maintenance burden on top of what already exists.

Implementation: Getting Started Without Boiling the Ocean

The mistake most teams make when approaching company-wide tooling is trying to solve everything before shipping anything. For an MCP server, start with three tools that solve real, daily pain points:

# Minimal viable company MCP — three tools that matter immediately 1. get_service_info(service_name: str) -> ServiceInfo # Returns: owner team, tech stack, repo URL, current on-call, # known incidents, and a one-paragraph description of what it does. # Pain it solves: "who owns X and what does it do?" — asked 20x/day. 2. search_adrs(query: str) -> List[ADRSummary] # Returns: ADR title, status (Accepted/Deprecated/Superseded), # one-line decision summary, link to full document. # Pain it solves: prevents re-proposing already-rejected solutions. 3. get_pattern(pattern_name: str) -> CodePattern # Returns: canonical code example for this pattern, context for when # to apply it, known pitfalls, link to internal documentation. # Pain it solves: "how do we handle X here?" answered with our standard.

With these three tools, you've addressed the most common category of lost context in AI-assisted development. The server can run locally via stdio initially — developers configure it in their AI client's MCP settings and immediately see the benefit. A remote HTTP server can come later when you're ready to centralize it.

A Minimal Server in TypeScript

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { z } from "zod"; const server = new McpServer({ name: "company-context", version: "1.0.0", }); server.tool( "get_service_info", "Get owner, tech stack, and description for any internal service. " + "Use when the user asks about a specific service, its ownership, dependencies, or tech stack.", { service_name: z.string().describe("The internal service name") }, async ({ service_name }) => { const info = await serviceRegistry.lookup(service_name); return { content: [{ type: "text", text: formatServiceInfo(info), }], }; } ); server.tool( "search_adrs", "Search Architecture Decision Records by keyword or topic. " + "Use when the user proposes a solution or asks about a design decision — " + "check if an ADR already exists for this before generating recommendations.", { query: z.string().describe("Keywords or topic to search for in ADRs") }, async ({ query }) => { const adrs = await adrIndex.search(query); return { content: [{ type: "text", text: adrs.length === 0 ? "No ADRs found for this topic." : adrs.map(formatADRSummary).join("\n\n"), }], }; } ); const transport = new StdioServerTransport(); await server.connect(transport);

Configuration in Claude Desktop / Cursor: Once deployed locally, developers add it to their MCP client config in seconds. The AI then has access to your company context across every conversation without any manual context-loading.

Onboarding: The Highest-ROI Use Case

The impact of a company MCP is felt most acutely during onboarding. A new developer joining a team today spends weeks building a mental model of the system — what exists, what calls what, what the naming conventions mean, which services are stable versus in-flux. Most of this knowledge lives in the heads of senior developers and is transferred through 1:1s, code review comments, and tribal knowledge accumulated over months.

With a company MCP, the new developer can ask the AI "what does the billing service do and how does it relate to the subscription service?" and get an authoritative answer backed by your actual service catalog. They can ask "what's the right way to handle database transactions in this codebase?" and receive your team's specific pattern, not a generic best practice. They can ask "why do we use X instead of Y here?" and surface the ADR that explains the decision, including the alternatives that were considered and rejected.

This doesn't eliminate the need for human mentorship — it eliminates the mechanical lookup work that consumes it. Senior developers get to spend their 1:1s on judgment and growth conversations instead of explaining for the third time why the team doesn't use Hibernate's second-level cache.

Governance and Maintenance

The most common objection to company knowledge systems is maintenance burden: the data goes stale, no one keeps it up to date, and eventually the system becomes a source of misinformation rather than a source of truth. An MCP server has the same vulnerability. Three practices mitigate it:

Security Considerations

A company MCP server exposes institutional knowledge through an API. Before deploying, consider what that means for your threat model:

The compounding effect: A company MCP doesn't just help today's AI interactions. It forces your team to actually write down and structure the institutional knowledge that currently exists only in senior developers' heads. The act of building the MCP surface — defining tools, writing descriptions, organizing ADRs — surfaces gaps in your own documentation that were costing you time independently of AI. The MCP is both the product and the forcing function for better knowledge management.

Key Takeaways

Back to all articles