What is MCP, and why should you care?

How to integrate your tools and your context with your assistants and your code

Diego Garber

Director,

Slalom

Published: Jan 12, 2026

12 minute read

TL;DR

AI is only as useful as the context it can access—and most enterprise context lives across disconnected tools.
MCP gives AI assistants a standard way to securely connect to tools like Jira, Figma, GitHub, and databases.
Instead of copy-pasting information, AI can retrieve the context it needs to answer questions and complete tasks.
MCP extends APIs for the AI era, making integrations more consistent, secure, and reusable.
As adoption grows, MCP is becoming the foundation for more capable, context-aware AI applications.

Why better context changes the way developers work with AI

As a developer, you’re juggling a dozen tools every day. Your Figma designs live in one place. Your Jira tickets in another. Your Playwright tests? Yet another system. Your Git history, your database, your API logs—they’re all scattered across different platforms.

Now, you want to use an AI assistant to help with your work, but here’s the problem: The AI has zero context about any of these tools. It doesn’t know about your Figma component library. It can’t see your open Jira tickets. It has no idea if your Playwright tests are passing or failing. So what do you do? You copy-paste. A lot. You screenshot your Figma designs. You copy-paste Jira ticket descriptions. You manually feed it test results. You’re constantly playing translator between your tools and AI.

But here’s the thing—sometimes you don’t even know what context you’re missing. Did Sarah update that Figma component yesterday? You wouldn’t know unless you checked. Is there a Jira ticket about that bug from the other team? Maybe, but you haven’t seen it. Did someone change the database schema last week? It could be sitting in your Git history, but you haven’t looked.

Your AI assistant is blind to your workflow, but often you’re partially blind too. You don’t know what you don’t know.

What if your AI could directly tap into Figma, Jira, Playwright, and all your other tools (with proper permissions, of course)? That’s what Model Context Protocol (MCP) enables.

When I first heard about MCP, I thought, “Great, another protocol.” But after seeing it work in real projects, I realized it wasn’t just about convenience—it was about giving AI access to context that even I didn’t know existed.

In this article, I’ll break down what MCP is, why it matters for your development workflow, and how you can start using it in your own applications today. By the end, you’ll understand how to give your AI assistant real context about your tools—not just the context you manually feed it.

What’s MCP?

Model Context Protocol is a standardized way for AI applications to connect to external tools and data sources.

Think of it like this: APIs expose functionality so other applications can reuse it, right? MCP does the same thing, but specifically for AI applications. It’s a protocol that lets tools like Figma, Jira, or your database expose their functionality in a way that AI can actually use.

Just like HTTP lets your browser talk to websites, MCP lets your AI talk to any tool that implements it.

Simple as that.

Why does MCP exist? What problem does it solve?

Before MCP, every AI tool had to build custom integrations for every service it wanted to connect to. Want to connect your AI to Figma? Custom integration. Jira? Another custom integration. This meant AI tools could only connect to whatever they specifically built support for, each integration worked differently, and there was no easy way to add your own tools or internal systems. You were stuck with whatever integrations your AI provider decided to build.

Sound familiar? It’s the same problem APIs solved for web applications. Before standard protocols like REST, every integration was a snowflake. MCP brings that same standardization to AI tooling.

With MCP, any tool can expose itself to any AI assistant using one common protocol. Build an MCP server once, and suddenly every MCP-compatible AI can use it. No more waiting for your AI provider to maybe, someday, add support for that niche tool you need!

How does it work?

So how does MCP actually work? Let’s break it down.

MCP follows a client-server architecture. Your AI assistant is the client, and each tool or service you want to connect runs its own MCP server.

What is an MCP server?

An MCP server is a separate process that runs alongside your AI assistant. It could be:

A standalone application (like a Node.js or Python process)
A service running locally on your machine
A remote service you connect to over the network

Each MCP server is responsible for one thing: exposing specific functionality from a tool or data source to AI assistants. The Figma MCP server knows how to talk to Figma’s API. The database MCP server knows how to query your database. The Playwright MCP server knows how to run your tests.

You configure which MCP servers your AI should connect to, usually through a config file. Depending on the setup, you might need to start them manually or toggle them on yourself, though some AI tools can spawn or connect to these server processes automatically. If you want to dive deeper into the technical details, check out the MCP specification.

The discovery process

When your AI connects to an MCP server, the first thing it does is ask: “What can you do?”

The server responds with a manifest of its capabilities. Here’s what that looks like:

Tools: functions the AI can call. Think of them like API endpoints. A Figma server might expose tools like get_design, list_components, or export_asset. Each tool has a name, description, and schema that define the parameters it accepts.
Resources: data sources the AI can read. A file system server might expose resources like file://path/to/file. A database server might expose db://users or db://orders. Resources are identified by URIs.
Prompts: predefined prompt templates provided by the server. These help guide how the AI should interact with the server’s capabilities.

And that’s it! The AI now knows exactly what it can ask this server to do. No guessing. No custom integrations. It’s all declared up front in a standard format.

Putting them to work

Let’s say you ask your AI: “What components are in the Figma design?”

Here’s what happens behind the scenes:

You send the list of available MCP servers.
The AI recognizes it needs Figma data.
It checks which MCP servers are connected and sees the Figma server.
It looks at the tools the Figma server exposed during discovery.
It calls the list_components tool with appropriate parameters.
The Figma MCP server receives the request, calls Figma’s API, and returns the data.
The AI receives the component list and presents it to you.

All of this happens transparently. You asked a question and the AI figured out how to get the answer using the tools available to it.

Pretty cool, right?

Access control

Here’s the important part: You control what gets exposed. Each MCP server only exposes what it’s programmed to expose. The AI doesn’t get blanket access to your Figma account or your entire database. It can only call the specific tools the server provides, with whatever authentication and permissions you’ve configured. Think of it like API endpoints—you wouldn’t expose a DELETE endpoint if you only want read access. Same principle here.

The API parallel: Impossible to ignore

I’ve been comparing MCP to APIs throughout this article for good reason—the mental model is identical. Now that you’ve seen how MCP works in practice, let’s formalize that comparison.

Here’s the exact mapping:

REST API: You have endpoints like GET /users, POST /orders, DELETE /products/{id}. Each endpoint has a defined schema—what parameters it accepts, what it returns, what errors it might throw.
MCP: You have tools like list_users, create_order, delete_product. Each tool has a defined schema—what parameters it accepts, what it returns, what errors it might throw.

See the pattern?

Instead of HTTP requests to endpoints, the AI makes function calls to tools. But the concept is identical: expose specific functionality through a well-defined interface.

API documentation tells developers what they can do. MCP discovery tells the AI what it can do. Same idea, different audience.

API authentication controls who can access what. MCP configuration and authentication controls which AI can access which tools. Same security model, different clients.

The beauty is that developers already understand this mental model. If you’ve built or consumed APIs, you already know how to think about MCPs. You’re just exposing functionality to AI instead of to other humans or applications.

Examples of existing MCPs

Let’s look at some real MCP servers you can use today.

Filesystem: Gives your AI access to read and write files on your local machine. No more copy-pasting file contents—your AI can directly read your codebase, configuration files, logs, and whatever else you need.
GitHub: Connects to GitHub’s API. Your AI can search repositories, read issues, review pull requests, and check continuous integration (CI) status, all without you leaving the conversation.
PostgreSQL: Direct database access. Ask your AI, “How many active users do we have?” and it queries your database directly. Or “Show me the schema for the orders table.” No SQL copy-pasting required.
Slack: Your AI can read channels, send messages, and search conversations. Imagine asking your AI to summarize what your team discussed in a specific channel today.
Puppeteer: Browser automation. Your AI can interact with web pages, run tests, take screenshots, and extract data from websites.
Atlassian: Connects to Jira and Confluence. Your AI can read tickets, update statuses, search documentation, check sprint progress—all the project management tasks you’d normally do manually.

The list keeps growing. There’s an ecosystem forming around MCP servers for various tools and services. Some are official implementations by the tool providers; others are community-built. You can browse the official MCP servers repository to see what’s available.

As long as they follow the MCP protocol, they all work the same way.

How they’re already integrated with other tools

MCP isn’t some future spec waiting for adoption. It’s already integrated into tools you might be using.

GitHub Copilot: Microsoft’s AI coding assistant has MCP support. Connect your MCP servers, and Copilot gains access to your tools and data sources.

Claude Code: Anthropic’s command-line interface (CLI) and VS Code integration supports MCP. You configure your MCP servers in a JSON config file (see the configuration guide), and Claude can immediately start using them. Your AI coding assistant has context about your entire development environment, not just the code in front of it.

The important thing here is that these tools don’t need to build custom integrations for every possible service. They just implement the MCP protocol once. After that, any MCP server works automatically. That’s the power of standardization.

As more AI tools adopt MCP, the ecosystem grows. Build an MCP server for your internal tool once, and it works across every MCP-compatible AI assistant. No vendor lock-in, no rebuilding integrations for each AI provider.

How to use them in your code

So you’re building an application—maybe a C# service or a Python script—and you want to give it MCP capabilities. How do you actually integrate MCP into your own codebase?

Let’s walk through it.

Using MCP client libraries

There are official MCP client libraries for different languages. You can find the full list in the MCP documentation, but let’s start with a Python example using the Python SDK:

from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

# Configure which MCP server to connect to
server_params = StdioServerParameters(
  command="npx",
  args=["-y", "@modelcontextprotocol/server-filesystem", "/path/to/directory"]
)

async with stdio_client(server_params) as (read, write):
   async with ClientSession(read, write) as session:

     # Initialize the connection
     await session.initialize()

     # List available tools from the server
     tools = await session.list_tools()
     print(f"Available tools: {tools}")

     # Call a tool (read a file, for example)
     result = await session.call_tool("read_file", arguments={"path": "src/main.py"})
     print(result.content)

In C#, you’d use the MCP .NET client library similarly:

using MCP.Client;

var serverParams = new StdioServerParameters
{
    Command = "npx",
    Args = new[] { "-y", "@modelcontextprotocol/server-filesystem", "/path/to/directory" }
};

using var client = await McpClient.ConnectAsync(serverParams);

// Initialize and discover capabilities
await client.InitializeAsync();
var tools = await client.ListToolsAsync();

// Call a tool
var result = await client.CallToolAsync("read_file", new { path = "src/Program.cs" });
Console.WriteLine(result.Content);

What’s happening here?

Let me break down these steps:

You specify which MCP server to connect to: Just like before, you tell your code how to spawn the MCP server process.
You initialize the connection: Your client connects to the server and performs the handshake.
You discover capabilities: Ask the server what tools it exposes.
You call tools: Invoke the tools you need, passing the required parameters.

Simple, right?

Integrating with AI models

Here’s where it gets really powerful.

You can combine MCP with AI model APIs (like the Anthropic SDK) to build AI-powered applications that have access to your tools:

using Anthropic.SDK;
using MCP.Client;

// Connect to your MCP servers
var mcpClient = await ConnectToMcpServersAsync();

// Get available tools
var tools = await mcpClient.ListToolsAsync();

// Create an Anthropic client
var anthropicClient = new AnthropicClient("your-api-key");

// Send a message with tool availability
var response = await anthropicClient.Messages.CreateAsync(new MessageRequest
{
    Model = "claude-sonnet-4-20250514",
    Messages = new[] { new Message { Role = "user", Content = "What files are in the src directory?" } },
    Tools = tools  // Pass MCP tools to Claude
});

// If Claude wants to use a tool, call it via MCP
if (response.StopReason == "tool_use")
{
    var toolUse = response.Content.OfType<ToolUseContent>().Last();
    var result = await mcpClient.CallToolAsync(toolUse.Name, toolUse.Input);
    // Send result back to Claude...
}

You’re building the bridge between the AI model and your tools. The MCP servers expose the capabilities, your code orchestrates the calls, and the AI decides when and how to use them.

Control and security

When you integrate MCP into your code, you control:

Which MCP servers to connect to
What parameters to pass (which directories, which database, etc.)
When to call tools and with what arguments
How to handle the responses

You’re in full control of the integration.

Authentication and security

Let’s address the elephant in the room: You’re giving an AI access to your tools and data. How do you make sure this is secure?

Again: You’re in control

First and foremost: MCP doesn’t grant access automatically. You explicitly configure which MCP servers to connect to and what parameters to pass.

If you don’t configure a server, the AI can’t access it. Period.

Authentication happens at the server level

When an MCP server needs to access an external service (like Jira, GitHub, or your database), it handles authentication itself. You provide credentials to the MCP server through:

Environment variables
Configuration files
API keys passed as parameters
Some even open a browser for you to authenticate

The AI doesn’t see these credentials. It just calls tools and gets results. The MCP server is the one actually authenticating with the external service.

Scoped access

Remember those tool definitions from the discovery process? Each MCP server only exposes specific tools.

You’re not giving blanket access to your entire system.

A database MCP server might expose a query_users tool, but not a drop_table tool. A filesystem server might only allow reading from specific directories. A Jira server might only allow reading tickets, not deleting them. You control what gets exposed by choosing which MCP servers to run and how to configure them. Would you expose a DELETE /users API endpoint to an untrusted client? Of course not. Same principle here.

Transport security

For remote MCP servers (ones not running locally), communication happens over secure transports. If you’re running an MCP server as a remote service, you’d use HTTPS and standard authentication mechanisms like API keys or OAuth tokens.

For local servers running as child processes, communication happens through standard input/output streams that never leave your machine.

Audit trail

Because you’re orchestrating the MCP calls in your code (or your AI tool is doing it transparently), you can log every tool call: What was requested, what parameters were passed, what was returned, and who requested it. Full visibility into what the AI is accessing.

The bottom line

MCP’s security model is straightforward: You configure what’s exposed, the MCP servers handle authentication to external services, and the AI can only use the tools you’ve made available.

So, why should you care about MCP?

Because you’re tired of being a copy-paste middleman between your AI and your tools. Because you want your AI assistant to actually assist with your real workflow, not just theoretical examples. Because standardization works—we’ve seen it with HTTP, REST APIs, and every other protocol that made software development easier.

But more importantly, because there’s context in your tools that you don’t even realize you’re missing. That Figma update from yesterday. That Jira ticket from the other team. That database change someone committed last week.

MCP doesn’t just save you from copy-pasting what you know—it helps surface what you don’t know.

Your AI can pull context from across your entire toolchain, finding connections and information you might have missed. Figma, Jira, your database, your file system—all accessible through a standard protocol. No more waiting for your AI provider to build custom integrations. No more vendor lock-in.

If you’re building AI-powered applications, MCP lets you give your AI real capabilities without reinventing the wheel. Use the MCP client libraries, connect to existing MCP servers, and you’re done. Want to add a new capability? Just add another MCP server or a tool to one you maintain.

The ecosystem is still growing, but the foundation is solid. The protocol is simple, the mental model is familiar (it’s just APIs for AI), and the benefits are immediate.

You can probably take your current AI workflow and give it real context about your tools in an afternoon. Who said you can’t have your cake and eat it too?

Want to get started? Check out the MCP quickstart guide or browse the available servers to see what you can connect to.

Stop copy-pasting. Start using MCP.

Happy coding :)