MCP 101: What It Is, Why It Matters, and How It Actually Works

MCP 101: What It Is, Why It Matters, and How It Actually Works

Introduction

There’s a lot of noise right now around MCP (Model Context Protocol).

Some people think it’s new technology. Others think it replaces APIs. Some think it’s magic.

It’s none of those things.

MCP is simple—but the shift it represents is powerful.

And if you understand it correctly, it fits perfectly into Intent-Driven Engineering.

What Is MCP?

MCP (Model Context Protocol) is a standard way to expose capabilities to AI models.

At its core, MCP is:

A structured, self-describing interface that tells a model:

• What tools exist

• What those tools do

• How to use them

That’s it.

It is not:

• A replacement for REST

• A new runtime

• A new infrastructure layer

👉 It’s a capability contract for AI systems

How MCP Is Different from REST

Let’s be honest—this is where most confusion starts.

We’ve been calling APIs for years. So why does MCP exist?

REST (Traditional)

• You call known endpoints

• You read documentation

• You hardcode integrations

👉 “Here are my URLs”

MCP (AI-Native)

• Tools are discoverable at runtime

• Capabilities are self-described

• Models can choose what to use

👉 “Here’s what I can do”

The Real Shift

REST

MCP

Developer-driven

Model-assisted

Static integration

Dynamic capability

Endpoint-based

Intent-based

How MCP Works (In the Real World)

Let’s break down the actual flow you saw in the diagram.

1. An Event Triggers the System

This could be:

• A GitHub push

• A Jenkins job

• A webhook

👉 This is where execution begins.

2. The Python Agent Orchestrates

The agent:

• Receives the intent

• Loads available tools (from an MCP server)

• Calls the model

👉 This is your control layer

3. The Model (via

AWS Bedrock

) Reasons

The model:

• Reads the intent

• Reviews available tools

• Decides what to do

Example decision:

• “Use analyze_repo”

👉 The model does not execute anything

It only chooses the next step

4. The Agent Executes the Tool

The agent:

• Calls your MCP / FastAPI endpoint

• Passes required inputs

• Receives results

👉 This is where real work happens.

5. The Loop Continues

The result goes back to the model:

• It may call another tool

• Or finalize the response

👉 This creates an intent-driven execution loop

Why MCP Matters

MCP isn’t about technology—it’s about control and flexibility.

1. Dynamic Tool Discovery

No more hardcoding:

tools = mcp_server.get_tools()

👉 Your system becomes plug-and-play

2. Centralized Governance

You control:

• What tools exist

• Who can use them

• How they are exposed

👉 Perfect for enterprise environments

3. Reusable Capabilities

Instead of building workflows:

• You expose capabilities

• The model composes them

👉 This is the foundation of shared services at scale

4. Alignment with Intent-Driven Engineering

This is where it all comes together.

MCP enables:

• Intent → interpreted by model

• Capabilities → exposed via MCP

• Execution → controlled by agent

👉 This is Intent-Driven Engineering in practice

Key Takeaways

• MCP does not replace REST—it builds on top of it

• The model decides, but does not execute

• The agent orchestrates and executes

• MCP servers expose capabilities, not endpoints

Final Thought

If you strip away the buzzwords, MCP is simply this:

A way to let systems understand what they can do instead of where to go

And that’s the shift.

From:

• Hardcoded workflows

To:

• Intent-driven execution