Introduction to MCP: from fragmentation to shared tool servers

What if a language model could connect, communicate, and act on the real world? MCP is the connector between intelligence and action.

ChatGPT launched on November 30, mid-late 2022 and accelerated mainstream AI use—productivity, everyday tasks, problem-solving. Vendors then folded AI into products people already lived in: productivity suites, chat apps, search, IDEs, enterprise software. Assistants stopped being only standalone chatbots.

A harder problem followed. Models can reason and write, but meaningful work needs the right context, data, tools, and systems. Wiring those pieces usually meant custom integrations, APIs, auth, and tool-specific code. That sprawl has a name: fragmentation.

The fragmentation problem

Fragmentation shows up when teams adopt many AI assistants, each trapped in its own ecosystem.

Picture a developer in VS Code. The in-editor assistant understands the repo within its walls. The moment they need GitHub issues or Confluence pages outside the IDE, they leave the assistant, copy text, paste it back, and hope the model gets enough context.

That constant tool-switching and manual context ferrying is fragmentation: the model is smart, but it does not automatically see every system the task needs.

What “context” means

Context is everything the model can see when it answers. Practically: whatever the LLM uses to structure a reply—often chat history plus whatever the user pasted.

Example: building a security feature with ChatGPT. A developer might:

1. JIRA — copy requirements and acceptance criteria into the chat.
2. GitHub — paste related implementations and repos.
3. MySQL — pull system data by hand and feed it in.
4. Google Drive — paste docs, security guidelines, architecture notes.
5. Teams/Slack — gather undocumented tribal knowledge from teammates.

Only then do they ask the real question. The model answers better—but the process hurts:

• Manual copy-paste across systems is slow.
• Context scatters; developers become human APIs.
• Assembly time can exceed development time.
• More sources make the ritual unscalable; real systems are larger than a paste buffer.

That pain helped drive function/tool calling in mid-2023 (OpenAI’s line of work).

Function calling

Function calling lets a model reach external resources via functions and use the results as context. Chat alone gave way to task automation: the model picks a tool, the app runs it, the model continues.

With tools defined for JIRA, GitHub, MySQL, Drive, Slack, and so on, the model can choose what to invoke from the user prompt, fetch context, and answer—without the human paste treadmill.

Limits of per-app function calling

Imagine three AI assistants in one company. Each still needs its own functions/integrations for databases, GitHub, JIRA, Slack, and friends.

If you have N assistants and M external resources, you risk N × M integrations. Ten assistants × twenty resources ≈ two hundred bespoke links. Growth makes that mesh expensive to build and keep alive.

If every app still owns every integration, fragmentation simply moved: context-assembly pain became integration pain.

Can N × M shrink to N + M? That is where MCP enters.

Model Context Protocol (MCP)

MCP is an open protocol that standardizes how AI applications connect to external tools, data, and services.

Two main roles:

• MCP client — lives in the AI app/agent, connects to a server, discovers and uses exposed tools/resources.
• MCP server — bridges the AI app to GitHub, JIRA, a database, Drive, Slack, or another service.

Client ↔ server speak MCP. Instead of every assistant inventing every vendor adapter, apps discover and call capabilities through one shape.

Function calling vs MCP — weather example

1. Function calling

You define an app-local function that talks to the weather API:

import requests

def get_weather(city):
    response = requests.get(
        "https://api.weather.com/current",
        params={"city": city}
    )
    return response.json()

You register that function as a tool. User asks “What is the weather in Bengaluru?” The model may call get_weather("Bengaluru"). The app runs it, returns data, the model finishes the answer.

The app team owns defining and maintaining that function and its API glue.

2. MCP

Weather lives on an MCP server that talks to the API and exposes a standard tool:

@mcp.tool()
def get_weather(city: str):
    """Get the current weather for a city."""
    return weather_api.get_current_weather(city)

The AI app is an MCP client that discovers get_weather. Same user question → discover/invoke via MCP → use the result in the reply.

The difference: MCP standardizes the hop between AI app and capability, so one server can serve many compatible clients.

Benefits of MCP

• Less repetitive maintenance than per-app function catalogs
• Lower cost and time spent on glue
• Clearer security boundary at the server
• Integrations scale closer to N + M than N × M

That is the “why.” Later pieces cover architecture, internals, and hands-on implementation.

Walking through the security-feature story again

Return to the developer building a security capability. Without MCP or tools, the day is a scavenger hunt across JIRA, GitHub, MySQL, Drive, and Slack. Each hop is a context paste. With function calling, those hops become named functions the model can invoke—but every assistant in the company still needs its own copy of the integrations.

MCP collapses that duplication. One weather server, one JIRA server, one GitHub server can serve many MCP-compatible clients. The N×M mesh becomes closer to N clients plus M servers.

Design notes teams miss

Treat tool descriptions as product copy: clear names and parameter docs drive correct model selection. Keep write tools behind confirmation and separate servers from read-only catalog tools. Log tool calls with correlation IDs so a bad answer can be traced to a bad retrieval, not blamed on “the model” in the abstract.

When comparing function calling and MCP for a new system, ask who owns the integration lifecycle. If the answer is “every product team forever,” MCP’s shared servers pay for themselves. If the answer is “one throwaway demo,” a local function is fine.

What comes next

Once the motivation is clear—fragmentation, context assembly, and integration blow-ups—the follow-on work is architecture: how clients discover tools, how servers authenticate, how sessions stream results, and how to ship a first production server. Those topics belong in dedicated deep dives; this piece’s job was to make the “why” undeniable and to show the weather example both ways.

Fragmentation as a budget problem

Count the hours your team spends pasting JIRA and GitHub into chats. That labor is a tax on every AI assistant you adopt. Function calling reduces paste time but multiplies adapter code. MCP aims the spend at shared servers instead of per-assistant forks.

Write the business case in those terms: fewer human API hours, fewer duplicate integrations, clearer audit points. Architecture diagrams matter less to finance than the N×M spreadsheet.

Weather example takeaways for reviewers

In the function-calling path, the weather HTTP client lives in the app. In the MCP path, it lives in a server other apps can reuse. Same user utterance, different ownership of the integration. Prefer the server when a second client is already on the roadmap; prefer the local function when the experiment dies next sprint.