Skip to content

Commit 7632a9f

Browse files
juliettech13juliettech13
authored
mcp blog (#5510)
1 parent 847b9f3 commit 7632a9f

File tree

4 files changed

+165
-0
lines changed

4 files changed

+165
-0
lines changed

‎bifrost/app/blog/blogs/mcp-blog/metadata.json‎

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
{
2+
"title": "MCPs: What, Why, and How",
3+
"title1": "MCPs: What, Why, and How",
4+
"title2": "MCPs: What, Why, and How",
5+
"description": "Model Context Protocol (MCP) provides a standardized interface for connecting Large Language Models to external data sources and tools. Here's a rundown of what it is, why to use it, and how to implement.",
6+
"images": "/static/blog/mcp-blog/cover.webp",
7+
"time": "5 minute read",
8+
"author": "Juliette Chevalier",
9+
"date": "January 14, 2026",
10+
"badge": "Frameworks & Tools"
11+
}

‎bifrost/app/blog/blogs/mcp-blog/src.mdx‎

Lines changed: 149 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,149 @@
1+
As LLMs became smarter, it became clear that APIs were built for humans, not for models.
2+
3+
Model Context Protocol (MCP) emerged to fill that gap, not by replacing APIs, but by standardizing how models interact with them through a consistent, discoverable protocol.
4+
5+
## What Is MCP (and Why It Exists)
6+
7+
**Model Context Protocol (MCP)** is a standard for connecting LLMs to external tools and services through a consistent, machine-readable interface. Similar to APIs, but for LLMs.
8+
9+
MCP defines a **shared contract** between:
10+
11+
* LLMs (i.e. Sonnet 4.5)
12+
* Tool clients (i.e. apps)
13+
* Tool servers (i.e. Google, maintained by service providers or the community)
14+
15+
That way, **it's easy for LLMs to discover tools at runtime and execute better autonomous actions.**
16+
17+
*-- For a comprehensive technical guide on getting started with MCP, see our [full developer guide](https://www.helicone.ai/blog/mcp-full-developer-guide) or learn how to [build your first MCP server](https://www.helicone.ai/blog/building-first-mcp-for-developers).*
18+
19+
At a high level:
20+
21+
```
22+
LLM -> MCP Client (your app) -> MCP Server (i.e. Google) -> External Service (i.e. Google API)
23+
```
24+
25+
## MCP vs APIs
26+
27+
As you can see, MCPs don't replace APIs. MCP sits *above* them.
28+
29+
APIs are for humans and applications. MCP is for models.
30+
31+
MCP assumes:
32+
33+
* Tools are **discovered** at runtime,
34+
* Inputs and outputs are **structured** for machines,
35+
* Models decide **when** and **how** to use tools,
36+
* Servers are maintained by the service owner who knows their API best.
37+
38+
| APIs | MCP |
39+
| ------------------------------ | ------------------------------ |
40+
| Designed for developers | Designed for models |
41+
| Custom integration per service | Standard interface everywhere |
42+
| App owns maintenance | Tool provider owns maintenance |
43+
| Hard-coded behavior | Model-driven behavior |
44+
45+
## The Role of MCP in Agents
46+
47+
MCP improves agent systems in a few key ways:
48+
49+
### 1. Tool discovery instead of hardcoding
50+
51+
**MCP servers expose what they can do.** Agents don't need prior knowledge of every function signature.
52+
53+
This enables:
54+
55+
* Agents to make dynamic decisions
56+
* Pluggable tools from external servers
57+
* No need to redeploy when APIs change because the MCP maintainers adapt this for you
58+
59+
### 2. Clear separation of concerns
60+
61+
With MCP:
62+
63+
* The **agent** decides *what* to do,
64+
* The **tool client** manages the connection,
65+
* The **tool server** handles auth, validation, and API calls.
66+
67+
Each layer does one thing well.
68+
69+
### 3. Multi-step, multi-tool workflows
70+
71+
Modern agents rarely call one tool and stop. They:
72+
73+
1. fetch context,
74+
2. transform it,
75+
3. act somewhere else.
76+
77+
MCP supports this naturally. The agent can chain tool calls across different MCP servers **without every integration being bespoke.**
78+
79+
<CallToAction
80+
title="Ready to build AI agents?"
81+
description="Join our free 7-day email course: From Engineer to AI Engineer. You'll learn how to build, monitor, and deploy AI agents with MCP, complete with working code examples."
82+
primaryButtonText="Join the Course"
83+
primaryButtonLink="https://www.helicone.ai/agent-course"
84+
/>
85+
86+
## MCP in Practice
87+
88+
MCP is most valuable when tools are:
89+
90+
* External
91+
* Stateful
92+
* Not owned by you
93+
94+
Some strong use cases:
95+
96+
* **Content workflows** (drafting, scheduling, publishing)
97+
* **Developer tooling** (GitHub, Linear, CI systems)
98+
* **Internal ops** (Slack, Notion, Sheets)
99+
* **Autonomous background agents** (cron-driven, event-driven)
100+
101+
To get started with the Helicone MCP server for querying your observability data, see our [MCP integration documentation](https://docs.helicone.ai/integrations/tools/mcp).
102+
103+
## How to Trace MCP Workflows?
104+
105+
Because agents are calling on external servers when using MCP tools, **MCP observability tends to be a black box.**
106+
107+
We can review when a model reasons, calls multiple tools, handles retries, fails, and recovers. But we can't see the actual tool call beyond its inputs and outputs because this is **logged on the external server.**
108+
109+
Once you introduce MCP, tool calls stop being “side effects” and start being first-class events in an agent's lifecycle.
110+
111+
This is where **Sessions** come in. Sessions let you group:
112+
113+
* Model calls
114+
* Tool calls
115+
* MCP interactions
116+
* Retries and failures
117+
118+
Instead of seeing: `“The model failed”`
119+
120+
You see: `“The model called Tool A → Tool B → Tool C, Tool B timed out, the model adapted, and the workflow recovered.”`
121+
122+
For MCP-based agents, observability is critical so debugging is not "guessing":
123+
124+
* Which tool caused this agent to fail?
125+
* How often does a given MCP server error?
126+
* Are retries coming from the model or the tool?
127+
* What does a "successful" agent run actually look like?
128+
129+
*-- To implement session tracking for your MCP workflows, see our [Sessions documentation](https://docs.helicone.ai/features/sessions).*
130+
131+
## Conclusion
132+
133+
Similar to APIs, the real impact of MCP is the ecosystem it enables for LLMs.
134+
135+
When service providers publish MCP servers, agents can dynamically discover and use their tools.
136+
137+
This means we stop building one-off agent demos and can start building interconnected **systems**.
138+
139+
APIs gave us composable software.
140+
MCP gives us composable *capabilities* for models.
141+
142+
---
143+
144+
**Ready to start building with MCP?**
145+
146+
- Set up the [Helicone MCP server](https://docs.helicone.ai/integrations/tools/mcp) in your product to query your observability data and train your agent to make better desicions
147+
- Learn how to [build your first MCP](https://www.helicone.ai/blog/building-first-mcp-for-developers) from scratch
148+
- Implement [session tracking](https://docs.helicone.ai/features/sessions) to monitor your MCP workflows
149+
- Explore our [AI agents guide](https://docs.helicone.ai/guides/cookbooks/ai-agents) for building autonomous systems

‎bifrost/app/blog/page.tsx‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -224,6 +224,11 @@ export const BLOG_CONTENT: BlogStructure[] = [
224224
folderName: "ptb-gateway-launch",
225225
},
226226
},
227+
{
228+
dynmaicEntry: {
229+
folderName: "mcp-blog",
230+
},
231+
},
227232
{
228233
dynmaicEntry: {
229234
folderName: "what-is-ai-gateway",

‎bifrost/public/static/blog/mcp-blog/cover.webp‎

232 KB
Loading

0 commit comments

Comments
 (0)