How Agents Touch the World — API · CLI · MCP

§ 01 — Orientation

The one-paragraph mental model

These acronyms are not rivals competing for the same job. They live at different layers of the same stack, and the fastest way to stop confusing them is to picture that stack from the bottom up.

At the bottom is the API: the raw contract by which any two pieces of software talk, agent or not. One step up, the CLI lets an agent borrow the developer's terminal and drive existing tools directly. MCP sits above that as a standardized adapter so an agent can discover and call tools and data without bespoke wiring for each one. And ADK sits highest, as the framework you use to build the agent itself — including coordinating several agents at once.

ADKHow do I build & orchestrate the agent(s)? — the framework that defines reasoning, planning, memory, and multi-agent coordination.

MCPHow does the agent discover & call tools in a standard way? — one protocol, many servers, dynamic discovery at runtime.

CLIHow does the agent run the tools that already exist? — shell commands the model has seen a million times: cat, grep, git, curl.

APIHow do the underlying systems talk at all? — the bedrock request/response contract everything else is ultimately built on.

Crucially, the upper layers usually wrap the lower ones. An MCP server very often turns around and calls a REST API; an ADK agent very often connects to an MCP server as a client. Two more pieces complete the picture — Skills (the knowledge of how to use these capabilities) and A2A (how agents talk to each other) — both covered below.

§ 02 — Definitions

Four definitions at a glance

API

Application Programming Interface

A defined contract that lets one program request something from another. In the agent world this usually means a REST/HTTP endpoint with fixed routes, parameters, and response shapes.

Era: decades old · Shape: static contract · Consumer: any software · Discovery: read the docs.

CLI

Command-Line Interface

Text commands run in a shell. An agent uses the same terminal a developer would — chaining ls, cat, grep, git, curl — because the model absorbed huge volumes of these examples in training.

Era: 1970s → still default · Shape: high-privilege tool · Consumer: humans & agents · Discovery: --help / man pages.

MCP

Model Context Protocol

An open standard (Anthropic, Nov 2024) that standardizes how LLM apps connect to external tools and data. A client–server protocol over JSON-RPC; servers expose tools, resources, and prompts the agent can discover at runtime.

Era: 2024+ · Shape: typed, discoverable protocol · Consumer: AI agents · Discovery: tools/list.

ADK

Agent Development Kit

An open-source framework for building agents — reasoning, tool use, state, and orchestration of multiple agents. Most-cited version is Google's ADK; IBM ships a watsonx Orchestrate ADK too.

Era: 2025+ · Shape: SDK / framework · Consumer: developers · Discovery: it uses MCP & A2A.

Read the layer, not the logo

API answers how systems connect. CLI answers how the agent executes. MCP answers how the agent integrates tools in a standard way. ADK answers how you build and coordinate the agents themselves. Keep those four questions straight and the rest follows.

§ 03 — The bedrock

API — the universal contract

An Application Programming Interface is the oldest and most general idea here: a published contract that says "send me a request shaped like this, and I'll send back a response shaped like that." A weather service, a payments processor, your company's CRM — almost every digital service of the last twenty years exposes one, typically as a REST API over HTTP.

APIs are wonderful and they are not going anywhere. But they were designed for developers writing code ahead of time, not for an agent reasoning on the fly. Three frictions show up when you point an LLM straight at raw APIs:

Static, per-service contracts. Each API has its own auth scheme, endpoint names, pagination, and error format. Integrating ten services means ten bespoke integrations.
No native discovery. An agent can't ask a plain REST API "what can you do?" — that knowledge lives in human documentation, not a machine-queryable form.
Brittle to change. When a provider renames a field or bumps a version, hand-written glue code breaks silently.

This is exactly the gap MCP was built to close — not by replacing APIs, but by putting a consistent, agent-friendly layer in front of them. As you'll see, an MCP server is frequently just a thin, standardized jacket over one or more ordinary APIs. [5][11]

§ 04 — The execution layer

CLI — the agent at the terminal

Give a coding agent a shell and something surprising happens: it is often more capable, not less. The command-line interface exposes tools the agent already understands intimately, because models trained on an enormous corpus of terminal usage — Stack Overflow answers, man pages, READMEs, shell scripts. Reading a file and finding a line is, from the model's perspective, a well-worn path. [3][8]

In the IBM CLI vs MCP video, Martin Keen uses a plain file-operations example: the agent wants to read notes.md and locate something inside it. Via the CLI that is simply:

# read a markdown file
$ cat notes.md

# find lines containing a term, with line numbers
$ grep -n "deadline" notes.md

# the last ten commits, one line each
$ git log --oneline -10

Two properties make the CLI attractive for agents:

Token efficiency. A shell command is a handful of tokens. The agent doesn't pay to load a schema — it just types. This matters enormously at scale.
Composability. Pipes and chaining let the agent assemble small tools into a larger result, exactly as a human engineer would.

The trade-offs are equally real. A CLI tool typically runs with the full privileges of the host session unless you deliberately sandbox it, output is unstructured text the model must parse, and discovery stops at --help. CLI sandboxing is a mature discipline — containers, seccomp, AppArmor — but it is on you to apply it. [2]

Why the model "likes" the CLI

From the LLM's point of view, both a CLI tool and an MCP tool are just a name, a description, and a schema injected into context. The CLI wins on familiarity and brevity for well-known local tooling; it is, in effect, one very high-privilege tool the model already knows by heart. [8]

§ 05 — The integration layer

MCP — the USB-C of AI tools

The Model Context Protocol is Anthropic's open standard, introduced November 2024, for connecting LLM applications to external tools and data in a uniform way. Martin Keen's analogy is the one that stuck across the industry: just as USB-C standardized a tangle of device connectors into a single port, MCP standardizes the connection between AI applications and the outside world. [1][6]

How it's built

MCP uses a client–server architecture communicating over JSON-RPC. Three roles matter:

Host (with client) ⇄ MCP server → the real systems. The server speaks MCP to the agent and native APIs to the backend.

Host — the AI application the user interacts with (a chat client, an IDE, an agent runtime).
Client — the connector inside the host that speaks MCP to a given server.
Server — the process that exposes capabilities and, behind the scenes, talks to the real system (a database, a filesystem, a SaaS API).

Each server can expose three primitives: tools (actions the agent can invoke), resources (data the agent can read, like files or records), and prompts (reusable templates that structure an interaction). Transports include stdio for local servers and HTTP-based streaming for remote ones. [9][12]

The feature that changes everything: dynamic discovery

Unlike a static API, an MCP client can ask a server at runtime what it offers via the tools/list method. The agent doesn't need the toolset hardcoded; it learns the available tools, their typed inputs, and their descriptions on connection, then decides what to call. This is the property Keen highlights as the real unlock: dynamic discovery plus a uniform interface plus tool execution, in one protocol. [1][6]

// the agent asks the server what it can do
→ { "method": "tools/list" }

// the server answers with typed, described tools
← { "tools": [
    { "name": "search_invoices",
      "description": "Find invoices by customer or date",
      "inputSchema": { "customer": "string", "since": "date" } }
  ] }

A minimal server is genuinely small. Using Python's FastMCP, a tool is just a decorated function:

from mcp.server.fastmcp import FastMCP
mcp = FastMCP("invoices")

@mcp.tool()
def search_invoices(customer: str, since: str) -> list:
    """Find invoices by customer or date."""
    return db.query(customer, since)   # calls your real API/DB

The cost of all this structure is context. Every tool's schema and description must be loaded into the model's window, and a busy server with dozens of tools can consume a great deal of context before a single action runs — the "schema tax." That tension is the entire subject of the CLI-vs-MCP debate. [7][8]

Write once, reuse everywhere

Because MCP is a standard, one well-built server works across any MCP-aware host — Claude, an IDE, or frameworks like LangChain and CrewAI — without code changes. That portability is the point: stop writing N×M custom integrations. [4]

§ 06 — The orchestration layer

ADK — the workshop for agents

Where MCP is about connecting an agent to tools, an Agent Development Kit is about building the agent in the first place — and increasingly about coordinating several of them. It is a framework, not a protocol: scaffolding for reasoning, planning, memory, tool use, and multi-agent orchestration. [13][14]

Two things share the name "ADK"

The version most discussed alongside MCP is Google's Agent Development Kit (open-sourced 2025, Python & Java). IBM's watsonx Orchestrate ADK is a separate product for building and importing enterprise agents into IBM's orchestration engine. They share a category, not a codebase — pin this down before a design discussion. [15]

ADK and MCP are partners, not rivals

The cleanest way the two fit together: an ADK agent acts as an MCP client. In Google's ADK this is done through an MCPToolset that connects to an MCP server, calls tools/list to discover what's available, and hands those tools to the agent as if they were native:

from google.adk.agents import LlmAgent
from google.adk.tools.mcp_tool import MCPToolset, StdioServerParameters

agent = LlmAgent(
    model="gemini-2.0-flash",
    tools=[ MCPToolset(                 # discovers the server's tools
        connection_params=StdioServerParameters(
            command="python", args=["invoice_server.py"]))
    ])

This is the heart of the IBM MCP vs ADK video: the framing is deliberately not "versus." Cedric Clyburn's point is that they solve different problems — MCP handles the tool/data connection, ADK handles how the agent is built and how multiple agents are orchestrated — and you frequently use both. [10][12]

§ 07 — The knowledge layer

Skills — teaching the agent how

There's a fifth piece worth knowing, and it cuts across the others. In a separate Think talk, Martin Keen makes the point that an LLM "knows a lot of facts" but doesn't necessarily know how work actually gets done. A Skill — typically a structured instruction file — doesn't grant new capabilities; it teaches the model how to use capabilities it already has. [9][20]

Keen frames an agent's competence as four kinds of knowledge, which map neatly onto the layers in this guide:

Innate

Model Context

What the LLM already knows from training — language, reasoning, broad world facts.

Tool access · MCP

Tool Access

The ability to call external services and APIs — exactly what MCP standardizes.

Facts · RAG

Factual Knowledge

Retrieval-Augmented Generation: pulling relevant, current facts from a knowledge base at query time.

Procedure · Skills

Procedural Knowledge

The "how-to" — step-by-step procedure encoded in skill files so the agent performs a task reliably.

Put simply: RAG gives the agent facts, MCP gives it reach, and Skills give it procedure. The orchestration framework (ADK) is where you assemble all three into a working agent.

§ 08 — The collaboration layer

A2A & the protocol zoo

Once you have more than one agent, they need a way to talk to each other. That's A2A (Agent2Agent), an open protocol introduced by Google in April 2025 and now stewarded by the Linux Foundation. Where MCP standardizes agent-to-tools communication, A2A standardizes agent-to-agent communication. [17][18]

A2A follows a client–server model and leans on plain HTTP and JSON. Its core ideas:

Agent Card — a small published profile (name, description, endpoint, capabilities, auth) that lets agents discover one another. Think of it as an agent's résumé or business card.
Task — a unit of work with an ID that moves through a lifecycle (submitted → working → input-required → completed / failed), supporting long-running collaboration.
Message — a single turn in the conversation between agents, carrying instructions, replies, or status updates.

It is genuinely an early, crowded field — a "protocol zoo." IBM's own ACP (Agent Communication Protocol), born from the BeeAI project and also now under the Linux Foundation, targets the same agent-to-agent goal with a lighter, REST-based design. Others (ANP, FIPA-ACL) circle nearby. None has fully won; expect breaking changes as the space matures. [18][19]

The whole stack in one line

ADK builds the agents → A2A lets the agents talk to each other → MCP lets each agent reach tools & data → Skills tell it how → RAG gives it facts → and underneath it all sit ordinary APIs and CLIs.

§ 09 — Matchup

MCP vs API

The two are more alike than they first appear: both follow a client–server model, and both provide an abstraction layer that hides a system's internals. The difference is who they were designed for. [21]

Dimension	API	MCP
Designed for	Developers writing code ahead of time	LLM agents reasoning at runtime
Discovery	Read the docs; hardcode the calls	Dynamic — `tools/list` at connect time
Interface	One bespoke contract per service	One uniform protocol across all servers
Integration cost	N×M custom glue	Write a server once, reuse everywhere
Relationship	Not exclusive — an MCP server typically calls the underlying API on the agent's behalf.

Takeaway: MCP doesn't kill the API; it makes the API consumable by an agent. The video's framing — "simplifying AI agent integration with external data" — is precisely that: turning a pile of incompatible API contracts into one discoverable, agent-native surface.

§ 10 — Matchup

CLI vs MCP

The liveliest debate of the set, and the honest answer is that they sit at two ends of a spectrum of tool granularity rather than being true competitors. The decision turns on three axes: token cost, structure, and where the work happens. [8]

Dimension	CLI	MCP
Token cost	Very low — a few tokens per command	Higher — schemas loaded up front; benchmarks cite 4–32× more on simple ops
Output	Unstructured text to parse	Typed, structured results
Model familiarity	Very high — trained on vast CLI corpora	Lower — schemas the model has seen less often
Discovery	`--help`, man pages	Native, dynamic discovery
Auth & isolation	Host session privileges unless sandboxed	Server-side credentials; scoped tokens
Best regime	Familiar local tooling — git, files, build	Remote/unfamiliar services, multi-agent reuse, governance

A 2026 benchmark across multiple models and APIs found CLI agents used fewer tokens per simple operation for well-known local tooling — but the advantage flipped the moment a request crossed a network boundary or hit an unfamiliar remote API, where native MCP integration gave the best completion rates. [8]

The pragmatic split many teams use

CLI for developer-facing coding agents on local repos; MCP for cross-functional, governed integrations (Slack, Jira, CRM) where multiple agents share tools and you need auth and audit trails. Route both through one governance layer so security policy doesn't fragment. [2][4]

§ 11 — Matchup

MCP vs ADK

The easiest to resolve because they barely overlap. One is a protocol for tool connectivity; the other is a framework for building and orchestrating agents. The IBM video's whole thesis is that they're a "collaborative symphony," not competitors. [13]

Dimension	MCP	ADK
Category	Open protocol / standard	Framework / SDK
Job	Connect one agent to tools & data	Build the agent; orchestrate many
Owner	Anthropic (open; broad adoption)	Google ADK · IBM watsonx Orchestrate ADK
How they meet	An ADK agent acts as an MCP client (e.g. via `MCPToolset`) to consume MCP servers.
The next layer up	A2A handles agent-to-agent collaboration above tool access.

§ 12 — Worked example

One task, four ways

Nothing makes the layers click like watching the same job done at each level. Task: "Pull a customer's recent invoices and summarize them." Here's how each layer expresses it.

API · raw HTTP, you write the glue

$ curl -H "Authorization: Bearer $TOKEN" \
       "https://erp.example.com/v2/invoices?customer=ACME&since=2026-01"
# → you parse the JSON, handle pagination, retries, and errors yourself

CLI · the agent drives the terminal

$ curl -s ".../invoices?customer=ACME&since=2026-01" | jq '.[] | {id, total}'
# cheap on tokens, but unstructured text the model must interpret

MCP · discover, then call a typed tool

# agent discovered search_invoices via tools/list, then:
→ { "method":"tools/call", "name":"search_invoices",
    "arguments":{ "customer":"ACME", "since":"2026-01" } }
← { "content":[ {invoice objects, typed} ] }   # server handled auth + API

ADK · an agent that owns the whole job

agent = LlmAgent(model="gemini-2.0-flash",
    instruction="Summarize a customer's recent invoices.",
    tools=[MCPToolset(...invoice_server...)])
# ADK runs the loop: plan → call MCP tool → summarize → (optionally
# hand off to a "reporting" sub-agent over A2A)

Same outcome, four altitudes. The API is the engine; the CLI is the agent turning the crank by hand; MCP is a clean dashboard the agent reads at runtime; ADK is the driver who plans the trip and can call in other drivers.

§ 13 — Synthesis

The grand comparison table

	API	CLI	MCP	ADK
What it is	Service contract	Shell commands	Tool protocol	Agent framework
Layer	Transport	Execution	Integration	Orchestration
Answers	How systems talk	How the agent runs tools	How the agent finds & calls tools	How you build the agent(s)
Discovery	None (docs)	`--help`	Dynamic	Uses MCP/A2A
Token cost	n/a	Lowest	Higher (schema)	Framework-level
Structure	Defined	Unstructured text	Typed	Typed
Best for	System-to-system	Local dev tooling	Remote/shared tools	Building & coordinating agents
Origin	Decades old	1970s→now	Anthropic 2024	Google/IBM 2025

§ 14 — Context

A short timeline

1970s →

The CLI. The Unix shell and its toolset (cat, grep, pipes) — still the default execution surface fifty years on.

2000s →

REST APIs. HTTP/JSON web APIs become the universal way services integrate. The bedrock the agent era is built on.

Nov 2024

MCP. Anthropic introduces the Model Context Protocol; rapid adoption by OpenAI, Google, and others follows.

Apr 2025

ADK & A2A. Google open-sources its Agent Development Kit and unveils the Agent2Agent protocol within days of each other.

May 2025

ACP. IBM's BeeAI project debuts the Agent Communication Protocol — a REST-based agent-to-agent alternative.

Late 2025

Open governance. MCP, A2A, and ACP converge toward the Linux Foundation, signaling the space is consolidating around shared standards.

§ 15 — Decision

How an agent actually chooses

Strip away the branding and, to the model, every option is the same kind of object: a name, a description, and an input schema in its context, plus a runtime that executes whatever the model emits. The "choice" is the model predicting which tool best fits the request given those descriptions. You steer it mostly by how you write the tool descriptions — and by which tools you put in front of it at all. [8]

Is the work local and familiar?

Editing files, running git, building, parsing logs on the host → reach for the CLI. Cheapest tokens, highest fluency.

Does it cross a network or hit an unfamiliar service?

A SaaS app, a remote database, an internal system → prefer MCP. Structured, discoverable, far more reliable than improvising API calls.

Will several agents (or tools) share this capability?

One MCP server, reused everywhere, beats re-wiring the same tool into each agent. MCP earns its schema cost here.

Do you need auth isolation, scoping, and audit?

Server-side credentials and scoped tokens favor MCP; or sandbox the CLI deliberately. Neither is secure by default.

Are you building the agent itself — or several working together?

Not a tool choice at all. Reach for an ADK, and let it consume MCP and A2A beneath you.

§ 16 — Field notes

Practical engineering notes

Mind the schema tax. Stacking GitHub + database + Microsoft Graph + Jira MCP servers can burn tens of thousands of tokens before any action runs. Load only the servers a task needs; lazy-load the rest.
Prototype with CLI, harden with MCP. Build a new capability as a CLI tool you can run and inspect by hand, then promote it to an MCP server once it must run reliably, at scale, or across agents. [4]
Never hardcode credentials, in any layer. CLI auth via env vars or config; API via secrets-managed keys/OAuth; MCP auth configured server-side and abstracted from the agent. [5]
Security is a config decision, not a default. MCP gives credential isolation by default but its OAuth 2.1 spec (2025) has uneven adoption; CLI grants full host privileges unless sandboxed. Put both behind one gateway for auth, rate limiting, and logging. [2]
Tool descriptions are the routing logic. Since the model picks tools from their descriptions, careful, unambiguous specs do more for reliability than almost anything else. [8]
Don't reach for MCP just because it's new. Reserve it for what it's genuinely good at — remote/unfamiliar services, multi-tenant access control, shared discovery across an org. [7]

§ 17 — Risk

Security & the OWASP angle

The moment an agent can run commands and call tools, its attack surface grows. In IBM's OWASP Top 10 for LLMs talk, Jeff Crume walks the updated list of LLM vulnerabilities — and several land squarely on the layers in this guide. [16]

OWASP risk	Where it bites in an agent stack
Prompt injection	Most prevalent threat. Indirect injection is the agent-specific danger: malicious text inside a tool result, fetched web page, or API response hijacks the agent's next action.
Excessive agency	The defining agent risk — too much autonomy, too many permissions, too few guardrails. A CLI with full host rights or an over-scoped MCP token is excessive agency waiting to happen.
Sensitive info disclosure	Secrets leaking through tool outputs or summaries. Validate and sanitize what flows back out of a tool call.
Improper output handling	Trusting an LLM's output downstream unchecked — it can emit code, markup, or SQL that executes elsewhere.
Supply chain	A malicious or compromised third-party MCP server or plugin is a direct path in. Vet what you connect.

Crume's mitigations are the familiar security hygiene, applied to LLMs: validate inputs and outputs, verify the provenance of models and data, scan and red-team regularly, patch, and log everything for incident response. The agentic twist: scope every tool to least privilege, and treat anything an agent reads from the outside world as untrusted input. [16]

Security is a sensitive area — the notes above are orientation, not an audit. Threat-model your own deployment against current OWASP guidance before shipping.

§ 18 — Clearing the air

Misconceptions & FAQ

Is MCP replacing APIs?

No. MCP usually sits on top of APIs and calls them on the agent's behalf. APIs remain the underlying transport; MCP just makes them discoverable and uniform for an agent.

Is the CLI obsolete now that MCP exists?

Not at all. For familiar local tooling — git, files, builds — the CLI is cheaper on tokens and the model is more fluent with it. The advantage flips toward MCP when work crosses a network or touches unfamiliar services.

Do I need an ADK to use MCP?

No. Any MCP-aware host (a chat client, an IDE) can use MCP servers. An ADK is only needed when you're building the agent yourself or orchestrating several — and even then, the ADK simply acts as an MCP client.

MCP vs A2A — what's the difference?

MCP standardizes agent-to-tools communication; A2A standardizes agent-to-agent communication. They're complementary layers — MCP makes an agent capable, A2A makes agents collaborative.

Which of these is the most secure?

None is secure by default. MCP offers credential isolation and scoped tokens; CLI runs with host privileges unless sandboxed. Security comes from deliberate configuration — least privilege, a governance gateway, input/output validation — not from the choice of layer.

Is there one "ADK"?

No — Google's Agent Development Kit and IBM's watsonx Orchestrate ADK are different products that share a name and a category. Confirm which one a conversation means.

§ 19 — Source talks

The IBM videos — watch here

The four Think series talks behind this guide, embedded in narrative order. Each maps onto a layer above.

1 · MCP vs API — Simplifying AI Agent Integration with External Data

IBM Technology · Martin Keen · ~13 min · the foundational entry

The USB-C analogy: one standard port replacing a tangle of connectors. Both MCP and APIs are client–server abstraction layers, but MCP is purpose-built for LLMs and adds dynamic discovery, a uniform interface, and tool execution.

2 · CLI vs MCP — How AI Agents Choose the Right Tool for the Job

IBM Technology · Martin Keen · ~14 min · the token-economy debate

A file-operations example — cat notes.md, then grep — sets the CLI's brevity and the model's deep familiarity against MCP's structure, discovery, and built-in auth. Pick by granularity, not by hype.

3 · MCP vs ADK — How Modern AI Agents Connect and Work Together

IBM Technology · Cedric Clyburn · ~14 min · the orchestration view

Separates protocol from framework: MCP handles tool/data connectivity, ADK structures how agents are built and orchestrated. Complementary — an ADK agent commonly acts as an MCP client — with A2A waiting in the wings.

4 · OWASP's Top 10 Ways to Attack LLMs — AI Vulnerabilities Exposed

IBM Technology · Jeff Crume · ~14 min · the security backdrop

Why the security section matters: once an agent can run commands and call tools, every layer becomes a place to get the safety configuration wrong. Prompt injection and excessive agency lead the list.

If an embed doesn't load (offline, or a strict viewer), each title links to the same video in the references.

§ 20 — Reference

Glossary

JSON-RPC: The lightweight request/response message format MCP uses to carry tool calls and results.
Host / Client / Server: MCP's three roles: the AI app (host) embeds a client that speaks to a server exposing capabilities.
Tool / Resource / Prompt: MCP's three server primitives: an action to invoke, data to read, and a reusable template.
tools/list: The MCP method an agent calls to discover, at runtime, what a server offers.
stdio · HTTP/SSE: MCP transports: standard I/O for local servers; HTTP streaming for remote ones.
Schema tax: The context (tokens) spent loading tool definitions before any action runs — MCP's main cost.
MCPToolset: The ADK class that connects an agent to an MCP server and surfaces its tools.
Agent Card: An A2A profile advertising an agent's identity, endpoint, and capabilities so others can discover it.
Task (A2A): A unit of agent-to-agent work with an ID and a lifecycle (submitted → working → completed/failed).
RAG: Retrieval-Augmented Generation — fetching relevant facts from a knowledge base at query time.
Skill: Encoded procedural know-how that teaches an agent how to perform a task with capabilities it already has.
A2A / ACP: Agent-to-agent protocols (Google / IBM-BeeAI) for letting independent agents collaborate.
Excessive agency: OWASP risk: an agent granted too much autonomy or permission relative to its safeguards.

§ 21 — Sources

References

CLI vs MCP: How AI Agents Choose the Right Tool for the Job. IBM Technology (Martin Keen), 2026. youtube.com/watch?v=g9JIUM0MHgQ
MCP vs CLI for AI Agents: Enterprise Comparison Guide. Tyk, Apr 2026. tyk.io/learning-center/mcp-vs-cli-for-ai-agents…
CLI vs MCP: What Tools AI Agents Use to Get the Job Done. Frank's World of Data Science, May 2026. franksworld.com/2026/05/04/cli-vs-mcp…
MCP Servers vs CLI Tools for AI Agents: When to Use Each. MindStudio, 2026. mindstudio.ai/blog/mcp-servers-vs-cli-tools-for-ai-agents
CLI vs MCP vs API for AI Agents: Which Integration Method? MindStudio, 2026. mindstudio.ai/blog/cli-vs-mcp-vs-api-ai-agents
MCP vs API: Simplifying AI Agent Integration with External Data. IBM Technology (Martin Keen), Jun 2025. youtube.com/watch?v=7j1t3UZA1TY
Why CLI Tools Are Beating MCP for AI Agents. Jannik Reinhard, Feb 2026. jannikreinhard.com/2026/02/22/…
CLI vs MCP: How AI Agents Actually Decide Which Tool to Call. Softmax Data, 2026 (cites Smithery & Descope benchmarks). softmaxdata.com/blog/cli-vs-mcp…
Skills, CLI, and MCP — Picking the Right Tool Layer for Your AI Agent. D. Dewhurst, Mar 2026. ddewhurst.com/blog/skills-cli-and-mcp…
MCP vs ADK: How Modern AI Agents Connect and Work Together. IBM Technology (Cedric Clyburn), 2026. youtube.com/watch?v=BedAaB1RKgE
Building AI Agents with MCP, ADK, and A2A: A Comprehensive Guide. R. Bin Safi, Medium, Nov 2025. medium.com/@rbinsafi/building-ai-agents-with-mcp-adk-and-a2a…
ADK Meets MCP: Bridging Worlds of AI Agents. Kaz Sato, Google Cloud Community, 2025. medium.com/google-cloud/adk-meets-mcp…
Connecting the Dots: MCP vs ADK in Modern AI Agent Development. Frank's World of Data Science, May 2026. franksworld.com/2026/05/19/connecting-the-dots…
A2A, MCP, and ADK — Clarifying Their Roles in the AI Ecosystem. Google Cloud Community, 2025. medium.com/google-cloud/a2a-mcp-and-adk…
Build AI Agents with IBM watsonx Orchestrate ADK and Kiro on AWS. AWS / IBM & Red Hat, Mar 2026. aws.amazon.com/blogs/ibm-redhat/build-ai-agents…
OWASP's Top 10 Ways to Attack LLMs: AI Vulnerabilities Exposed. IBM Technology (Jeff Crume), 2026. youtube.com/watch?v=gUNXZMcd2jU
What is the A2A (Agent2Agent) Protocol? IBM Think. ibm.com/think/topics/agent2agent-protocol
What Are AI Agent Protocols? IBM Think, 2026. ibm.com/think/topics/ai-agent-protocols
What is the Agent Communication Protocol (ACP)? IBM Think. ibm.com/think/topics/agent-communication-protocol
AI Agents Need Skills: Martin Keen on LLM Tooling. StartupHub.ai, Apr 2026. startuphub.ai/…/ai-agents-need-skills-martin-keen…
MCP vs API: Simplifying AI Agent Integration (write-up). Frank's World of Data Science, May 2025. franksworld.com/2025/05/05/mcp-vs-api…