What MCP is
Model Context Protocol (MCP) is an open protocol published by Anthropic in November 2024 that standardizes how AI assistants connect to external data sources and tools. Before MCP every AI client (Claude Desktop, Cursor, Zed, Continue) had to implement integrations with each tool separately: Gmail required one piece of code, ClickUp another, Postgres a third. Every integration was ad hoc, incompatible between clients, hard to maintain.
MCP solves this problem in the same way the Language Server Protocol (LSP) solved IDE integrations with compilers and linters. You define an MCP server once for a given tool, and every MCP-capable AI client can use it. Communication uses a local inter-process protocol (for local integrations) or HTTP with event streaming (for remote integrations). The specification is available at modelcontextprotocol.io, with reference implementations in Python, TypeScript, and other languages.
The practical benefits for SMBs are three. First: the MCP server ecosystem grows exponentially. Around 50 servers in 2024, around 800 in 2025, more than 2500 in early 2026. Most are open source and ready to use. Second: portability. You configure an MCP server for Gmail once, then use it in Claude Desktop, Claude Code, Cursor, and n8n. No vendor lock-in at the integration layer. Third: security. MCP servers can run locally, so the data never leaves the client’s machine. For integrations subject to DSGVO compliance, this is a critical aspect.
MCP is not the first attempt at standardization. OpenAI Function Calling, LangChain Tools, and OpenAPI specs were earlier approaches. The MCP difference: it is language-agnostic (the server can be in Python while the client is in TypeScript), process-isolated (each server is a separate process with its own credentials), and has native support on the model side from Anthropic Claude. Claude Sonnet 4.5 and newer are fine-tuned to use MCP tools effectively (fewer confused calls, better schema understanding).
Architecture: server, client, transport
MCP defines three roles: server (exposes tools and resources), client (inside an AI application, uses servers), and host (the end-user application like Claude Desktop). A server can expose three kinds of things: tools (functions the AI can call, such as “send an email”, “query a database”), resources (static read-only data the AI has access to, such as “list of files in a directory”), and prompts (preconfigured conversation templates for common use cases).
Communication uses a standardized JSON message format. Transport can be one of two: a local channel (the server runs as a local process and communicates over standard input/output, used for local integrations) or HTTP with event streaming (the server runs as a separate service, used for remote integrations like cloud-hosted Gmail). Transport choice affects latency (local sub-millisecond, HTTP 50-200ms) and security (local never leaves the host, HTTP requires TLS and authorization).
A real-world example: the claude.ai connector for Gmail is a cloud-side MCP server, run by Anthropic, accessible over HTTP after OAuth with your Google account. When you use Claude in the browser and ask “summarize the last 10 emails”, Claude calls the “search_messages” tool on the Gmail MCP server, the server fetches the emails, returns a JSON structure, and Claude generates a summary. Everything is secure, auditable, and revocable through Google Account Security.
The second architectural layer: discovery. An MCP client can ask the server “what do you expose” and receive a list of tools with JSON schemas, resources with URI templates, and prompts. This makes it possible to build dynamic UIs where the AI itself discovers available tools without hardcoding function names in the prompt. It matters when the server updates (adds new tools), the client sees them automatically without reconfiguration.
Third layer: lifecycle. The server can push notifications to the client, such as “resource X changed” or “the authorization token expires in 5 minutes”. The client can react without waiting for the next user question. For long-running agents this mechanism allows event-driven workflows (a new email arrived, an invoice was issued in the CRM, an order status changed) rather than polling every few seconds. The MCP specification defines subscriptions, although in 2026 host-side support is still uneven (Claude Desktop full, Claude Code partial, other clients variable).
Available servers in the 2026 ecosystem
Anthropic maintains official reference servers for the most common use cases: Filesystem (access to local files), Git (repository operations), GitHub (PRs, issues, code search), Postgres (query, schema), Slack (messages, channels), Memory (a persistent KV store), Sequential Thinking (structured reasoning). These servers are code-reviewed, tested, and actively maintained. The github.com/modelcontextprotocol/servers repository has 50 plus official implementations.
The community ecosystem is more than 2500 servers at the start of 2026. In our setup we use: Higgsfield (image generation), Telegram (bot bridge), Chrome DevTools (browser automation), Context7 (live docs fetcher), Firecrawl (web scraping), Playwright (headless browser). Each installed through Claude Desktop config plus credential configuration. The community repository is fragmented (different organizations, different languages), but the awesome-mcp-servers GitHub repo collects an index.
The third layer: commercial aggregators. Composio (1000 plus apps with auto-OAuth), Zapier MCP integration (Zapier flows exposed as MCP tools), Pipedream MCP (workflows from Pipedream as tools). These platforms charge a subscription (Composio 49-199 dollars/mo, Zapier per their pricing), but they completely remove the problem of writing servers for popular apps by hand. For AI Assistant V0.1 (June 2026) we use Composio as primary aggregator plus our own MCP servers for custom integrations per client.
Server choice per use case matters. For Gmail/Calendar integration you have three paths: the official Anthropic Gmail server (you handle OAuth yourself), community zapier-mcp (through a Zapier subscription), or Composio (auto-OAuth, management dashboard). Each has trade-offs: the official one is free but requires DevOps, Zapier is convenient but expensive, Composio is the middle ground. We typically pick Composio for the first client and the official self-hosted option from 3 plus clients (economies of scale).
Finally, an under-appreciated category of servers: developer experience. Context7 (live docs fetcher) lets the AI pull up-to-date documentation for Next.js, Stripe, Postgres without hallucinating versions. Chrome DevTools MCP lets the AI physically check how a page renders in the browser (screenshots, console errors, network requests). Playwright MCP gives full browser automation. These three in our daily setup save 5-10 hours a week on client work: Claude validates the implementation result itself, takes a screenshot, compares it with the design, reports regressions. That is a different productivity tier than “AI only writes code, the human checks manually”.
Building your own MCP server, when it is worth it
Signals that it is worth writing your own MCP server: the client has a proprietary CRM, a custom ERP, an in-house API, a local German accounting system (DATEV), a Polish one (Comarch Optima), or any system without a ready-made connector. The aggregator (Composio, Zapier) does not have those systems, the official Anthropic server does not exist, and the alternative is custom code.
Implementation time for a typical MCP server: 1-3 days of dev in Python with the mcp library or TypeScript with @modelcontextprotocol/sdk. Scope: 5-15 tools with JSON Schema validation, an OAuth flow or API-key auth, error handling, logging, unit tests. We deliver a custom MCP server under the automation package at 3000-6000 PLN per integration (depending on client API complexity).
Key benefits of an in-house server: full control over scope (which data the AI sees and which it does not), an audit log of every action, deployment alongside the client’s application (no cross-cloud data flow), and customizable tool descriptions optimized for Claude (better hit rate than a generic Zapier wrapper). For regulated industries (medical, finance, legal) an in-house on-prem server is often a compliance requirement, not a nice-to-have.
Anti-patterns to avoid: do not build a custom server as a thin wrapper around a public API (Composio/Zapier likely already has it, your version will be worse maintained). Do not expose every CRM endpoint as a tool (the AI gets confused above 50 plus tools; 10-15 carefully picked are better). Do not skip idempotency for tools with side effects (the AI can retry, the client gets duplicates). More on patterns in our article on Claude Agent SDK.
Fourth anti-pattern: lack of schema validation on the server side. If you trust that the AI will always pass valid arguments, sooner or later you will get a call with null instead of an email address and the operation will flow into the database with an HTTP 500. Best practice: every tool has an input schema (JSON Schema with required fields, type coercion, value constraints), the server validates before calling business logic, and returns a descriptive error to the AI (“field email is required, got null”). The AI learns from that error and corrects arguments on the next call without human intervention.
Setting up an MCP server locally, step by step
Configuring an MCP server for Claude Desktop is file-based: claude_desktop_config.json in OS-specific paths. Mac: ~/Library/Application Support/Claude/claude_desktop_config.json. Windows: %APPDATA%\Claude\claude_desktop_config.json. Linux: ~/.config/Claude/claude_desktop_config.json. The file is JSON with an mcpServers section, each server as a key-value entry.
Example entry for the Filesystem server: key “filesystem”, command “npx”, arguments include the “-y” flag, the package name @modelcontextprotocol/server-filesystem, and the path to the directory you want to share. After saving the file you restart Claude Desktop, check in the UI (settings > developer > MCP servers) that the server is connected, and test a tool call in a new conversation (“show files in the shared directory”).
The most common gotchas: environment variables (PATH, GMAIL_TOKEN) are NOT automatically inherited from the shell; you must define them explicitly in the env section per server entry. Paths must be absolute (relative paths do not work, Claude Desktop has no known working directory). After every config change you need a full app restart (closing the window is not enough). Server logs are visible through stderr redirected to Claude Desktop’s log file.
The second path: configuration in Claude Code (CLI/IDE). Here configs live in ~/.claude/settings.json with an analogous mcpServers section. Plus there is the option of per-project overrides in .claude/settings.local.json. That is convenient for teams: dev1 can have their own set of MCP servers for the project, dev2 a different one, while the project itself shares a common section like Postgres-to-staging.
Practical tip: keep configs in git (shape only, no tokens), keep tokens in a local .env ignored by git, and have server entries reference environment variables. Onboarding a new developer becomes: git clone, copy .env.example to .env, paste your tokens, restart Claude Desktop. Without this discipline every client onboarding ends with someone pasting a config in Slack and forgetting one field, which costs half a day of debug and frustration. For distributed teams it is worth rotating who checks whether the config is current, ideally once per sprint.
MCP versus Function Calling versus custom tools in the SDK
Three approaches to AI tool use are often conflated. Function Calling is a feature in the API itself (OpenAI Functions, Anthropic Tools), where the tool definition is part of the HTTP payload sent to the model. The model decides it wants to call a tool, your application executes that function, and you return the result to the model on the next call. Same-process, language-specific (a Python implementation is not shared with TypeScript).
Custom tools in Claude Agent SDK are a wrapper on Function Calling with extra infrastructure (router, validation, caching). Still same-process, but more ergonomic to maintain. MCP, by contrast, is an inter-process protocol: the server can be in a different language than the AI application, deployed elsewhere, restarted independently. The exchange is a standardized JSON message format, not an in-memory function call.
When to pick which: for quick prototyping and an agent specific to a single application, use custom tools in the SDK (built-in, simple). For an integration that should be reusable across AI applications (Claude Desktop plus Claude Code plus Cursor), build an MCP server. For an internal integration in a single process (for example a Telegram agent with 5 tools against your CRM) custom tools are enough. For an integration inside an organization but used by many teams (cross-department internal AI assistants), MCP wins.
Use cases in the studio
AI Assistant V0.1 (June 2026 launch) uses MCP heavily. Stack: a Telegram bot endpoint plus a Claude Agent SDK orchestrator plus 4-6 MCP servers per client (Gmail, Google Calendar, ClickUp or Notion, a custom CRM if the client has one, an n8n webhook bridge). For the first client (a DACH e-commerce business owner) the configuration took 2 days: Composio for Gmail/Calendar (auto-OAuth), a custom MCP for the packing dashboard API (our plugin v0.1.1), Composio Slack plus Notion. Setup 3000 PLN.
The second pattern: a custom MCP server per client for a proprietary system. One of our clients has an old ERP with a REST API and no ready-made connector. We write an MCP server (Python, 12-15 tools for CRUD on invoices, clients, orders), deploy it on the client’s premises (a Docker container), and the AI assistant queries it via a local bridge. Implementation time: 4-6 days of dev plus 1 day of tests plus 1 day of training. Package 8000-12000 PLN one-time, retainer 800 PLN/mo.
The third pattern: an MCP-based research agent for internal use. Our internal agent uses MCP servers for Perplexity (deep research), Firecrawl (web scraping), defuddle (article cleaning), Chrome DevTools (visual verification) plus our own MCP to an Obsidian vault. The agent helps with discovery for new clients: scrape the site, audit, propose scope. Internal tool, not sold. More on the pattern in our Telegram AI bot article.
If you are wondering whether MCP makes sense in your firm, the simplest start is an AI audit at 1500 PLN. As part of the audit we map your tools (CRM, mailing, calendar, custom systems), assess which already have ready MCP servers (most do), which require custom development, and which AI assistant use cases will deliver ROI fastest. PDF roadmap plus a 1-hour call, the form on the contact page.
FAQ
MCP versus Zapier MCP integration, what is the difference?
Zapier added an MCP integration in 2025: any Zap can be exposed as an MCP tool. That is convenient for SMBs who already have 50 plus Zaps: instead of writing your own MCP servers, you use existing Zaps as tools. The trade-off: you keep paying the Zapier subscription plus tasks per use, latency is higher (Zapier execution overhead), and scope control is limited to what the Zap does.
Is MCP secure?
Yes, at the protocol level MCP is neutral: it neither imposes nor blocks any security policy, but it gives you the tools to implement one (per-tool permissions, audit logging, OAuth flows, TLS transport). Security depends on per-server configuration: a local server with filesystem access can be an attack vector if the AI host runs in a shared environment. Best practice: principle of least privilege, server-side audit log, regular credential rotation.
What is MCP’s latency?
Local communication is sub-millisecond, HTTP with event streaming is 50-200 milliseconds (depending on server location and network). For most use cases acceptable: an AI tool call is typically 200-500 milliseconds of model time plus 50-200 milliseconds of MCP, total 250-700 milliseconds per call. For high-frequency tool calls (an agent making 50 tool calls per task) prefer the local transport.
Can I write an MCP server on-prem for a client?
Yes, MCP is designed for on-prem deployment. The server is just a process (Python, TS, Go, Rust), run as a Docker container, a systemd service, or a Windows service. Communication via the local channel (if the AI client is on the same host) or HTTP plus a reverse proxy (if the client is on a different network). For DACH compliance and Polish clients in regulated sectors this is often a requirement, not an option.