In December 2025, the Model Context Protocol (MCP) was donated to the Linux Foundation. By April 2026, every major AI vendor (Anthropic, OpenAI, Google, Microsoft) supports it natively. If you want Claude or ChatGPT to read from your CRM, post to your project management tool, or query your internal database, you no longer write a one-off integration. You build an MCP server once, and every AI client you use can talk to it.
This post is a practical walkthrough of building a small MCP server for a real business workflow. We will skip the theory and focus on what actually ships.
Why MCP Won the Standardization Race
Before MCP, every AI integration looked the same: copy a key, write a custom function calling adapter, paste the schema into your prompt, repeat for the next model. Three problems with that approach:
- Switching from GPT to Claude meant rewriting the integration layer.
- Each tool definition lived inside the prompt, eating context window.
- There was no way to share an integration across teams or products.
MCP fixes this with a simple JSON-RPC contract between AI clients and tool servers. Define your tools once, expose them via an MCP server, and any compliant AI client can discover and call them.
What an MCP Server Actually Is
An MCP server is a long-running process (or stdio handler) that exposes three things: tools (functions the AI can invoke), resources (data the AI can read), and prompts (reusable templates). Most servers only need tools.
The transport is either stdio (for local desktop clients like Claude Desktop) or HTTP/SSE (for hosted clients). For internal business tools, stdio is the simplest path. For shared team servers, HTTP is the right call.
A Real Example: Exposing Your Project Management Tool
Say your team uses Linear for issues and Slack for communication. You want Claude to be able to: list open issues assigned to you, create a new issue from a Slack thread, and post status updates to a channel.
Using the official MCP SDK in Node.js, the skeleton looks like this:
import { Server } from '@modelcontextprotocol/sdk/server/index.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
const server = new Server(
{ name: 'team-tools', version: '1.0.0' },
{ capabilities: { tools: {} } }
)
server.setRequestHandler('tools/list', async () => ({
tools: [
{
name: 'list_open_issues',
description: 'List issues assigned to the current user',
inputSchema: { type: 'object', properties: {} }
},
{
name: 'create_issue',
description: 'Create a Linear issue',
inputSchema: {
type: 'object',
properties: {
title: { type: 'string' },
description: { type: 'string' },
team_id: { type: 'string' }
},
required: ['title', 'team_id']
}
}
]
}))
server.setRequestHandler('tools/call', async (request) => {
const { name, arguments: args } = request.params
if (name === 'list_open_issues') return await linear.listMyIssues()
if (name === 'create_issue') return await linear.createIssue(args)
throw new Error('Unknown tool: ' + name)
})
await server.connect(new StdioServerTransport())That is the entire pattern. Define tools, handle the call, return the result.
Auth and Secrets: The Part Everyone Skips
The MCP spec leaves authentication to the implementation. For internal tools, the simplest pattern is environment variables read at server startup. For multi-tenant servers, OAuth 2.1 flows are now first-class in the 2026 spec update.
Three rules we follow:
- Never put credentials in tool inputs. The AI does not need to see them.
- Scope tokens narrowly. A read-only Linear token is enough for the list tool; the write token is separate.
- Log every tool call with the calling user, the inputs, and the result. AI agents move fast and audit trails save you.
Common Pitfalls When Building MCP Servers
- Vague tool descriptions. The AI client picks tools based on your description text. "Create issue" is worse than "Create a Linear issue with title, description, and team. Returns the issue ID and URL."
- Returning huge payloads. Tools that return 50KB of JSON blow out the AI's context window. Paginate, summarize, or expose a follow-up tool to fetch details.
- Missing error envelopes. When a tool fails, return a structured error the AI can reason about, not a stack trace.
- Forgetting to test with multiple clients. Claude Desktop, Cursor, ChatGPT, and Gemini all consume MCP slightly differently. Test in at least two before shipping.
When to Build vs. When to Use an Existing Server
By April 2026, there are 400+ open-source MCP servers on GitHub for popular tools (Linear, GitHub, Slack, Notion, Postgres, Stripe, etc.). Always check the registry first. Build your own only when:
- The tool is internal to your business (proprietary CRM, internal API).
- You need custom logic on top of an existing API (e.g., business rules around lead routing).
- The existing server is missing a capability you need.
What This Looks Like in Practice
We recently shipped an MCP server for a logistics client that exposes their dispatch system to Claude. The team uses it daily: "Claude, list pickups in Lagos for tomorrow morning" or "Reroute the Abuja shipment if the driver is delayed". Build time was 4 days. ROI was immediate because the team stopped context-switching between dashboards.
If you have an internal tool you wish your team could query in plain language, an MCP server is now the right tool. Our AI integration team can scope, build, and host MCP servers for your stack. Tell us what tools you want to expose and we will return a quote within 24 hours.