Learning Model Context Protocol

We have recently seen information related to the Model Context Protocol (MCP). I knew of them some part, but had some small questions. This post is a note for me about that.

Below is a summary of our conversation with ChatGPT, as summarized by them.

🔍 Understanding the Model Context Protocol (MCP)

Over the course of this deep-dive session, I explored how MCP empowers large language models (LLMs) to interact with external tools and APIs — dynamically, intelligently, and securely. Here’s a recap of the key ideas:

🧠 What is MCP?

MCP (Model Context Protocol) is an open protocol that allows LLMs to call external tools in real-time. The architecture typically involves:

• MCP Server – Hosts the actual logic or functions (e.g., APIs like get_forecast()).
• MCP Client – Acts as the conduit, routing requests and results.
• LLM – Thinks and decides when and how to use tools based on user input.

This structure decouples tool execution from reasoning, giving the LLM flexibility to orchestrate actions intelligently.

---

🔄 How the Interaction Works

1. User sends a message → e.g., “What’s the weather in Tokyo?”
2. Client forwards it to the LLM, along with tool metadata like function names and schemas.
3. LLM chooses a tool to call (e.g., get_forecast(latitude, longitude)), based on:
   • Natural language intent
   • Tool names and descriptions
   • Input schema and conversation context
4. Client executes the tool call on the MCP server and retrieves the result.
5. LLM integrates the result into a natural language response.

This means the LLM is the “brain,” while the client and server act as hands and mouth.

---

🧪 Observations & Best Practices

• The LLM’s reasoning is non-deterministic — its choices may vary across model versions or as descriptions change.
• To make tool usage predictable:
• Use descriptive function names (e.g., latitude instead of a).
• Provide clear tool descriptions and JSON schemas.
• Optionally add system prompts to bias tool selection.

Poorly named arguments (like a, b) can confuse the model, resulting in inaccurate calls.

---

🤔 Takeaways

• MCP enables dynamic composition of workflows — like chaining together scan_bluetooth() and analyze_latency() with no hard coding.
• But that dynamism relies on the LLM’s interpretation, which makes tool naming, schema design, and metadata clarity absolutely critical.
• It’s a shift in mindset: APIs aren’t just for developers anymore — they’re now for models, too.

---

Then, I asked if it’s a good idea to not use MCP for deterministic execution. The answer was:

Yes — if deterministic execution is a hard requirement (e.g., compliance testing, financial transactions, or regulated pipelines), then using MCP with free-form LLM reasoning might not be the best fit on its own.

Here’s why:

⚖️ MCP’s Tradeoff: Flexibility vs. Control

MCP shines when you want flexible orchestration — where the model can decide which tool to run, when, and how. But because the LLM is making those decisions based on probabilistic inference, results can vary:

• Tool selection might shift depending on wording or model version.
• Output could drift based on subtle prompt/context changes.
• New tools registered in the system may alter model behavior.

So if your goal is:

“Always run run_fuzz_test('bt_hci_scan') when a specific trigger occurs, no deviations.”

Then it often makes more sense to:

• Skip the LLM for that path entirely, or
• Use MCP in a constrained mode, where:
• You explicitly call the tool via the client (bypassing LLM decision-making), or
• You wrap the tool call in code or a finite-state machine that enforces specific logic.

---

🧩 Hybrid Pattern: The Best of Both Worlds?

That said, you could still use MCP for deterministic tasks — just not via dynamic model routing. For instance:

• User asks for a Bluetooth fuzz test → client invokes run_bluetooth_fuzz() directly.
• Model gets involved only after to interpret the logs or present results in natural language.

This hybrid setup lets you keep precise execution and friendly responses.

Would it be helpful if I sketched out how that might look with adb_fuzz() and latency_report() split into deterministic and dynamic paths?

---

These are interesting.