A working reference for five words that get used interchangeably and are not the same thing: tools, agents, connectors, MCP, and APIs. They are not competitors — they are different layers of one stack, which is exactly why they get conflated. Getting the layers straight is what makes the hard questions (security, cost, reliability) tractable.

This is a living reference. We expect to extend it as the field moves, particularly as AI leaves the chat box and starts acting in the physical world (see Physical AI below), where the same connectivity concepts stop being convenient and become load-bearing.

A frame we keep coming back to: an agent is inference in a loop; the new engineering is the control layer — orchestration, tools, security, identity — and the honest unit of measure is cost and latency per completed task, not per token.

The stack, bottom to top

None of these replaces the layer beneath it. An agent still calls a model over an API; a connector is still tools; MCP is still just how tools get wired in.

API           the raw model I/O (stateless request -> response)
  Tool        a capability offered to the model, as a schema
    MCP        a standard way to serve and discover tools/data
      Connector     a managed, authenticated MCP integration to a real service
        Agent       the loop that drives all of the above toward a task

What each one actually is

Term What it really is The thing people miss
API The interface to a model. You send messages, configuration, and tool definitions; you get back text and/or tool-call requests. In the basic case it is stateless and executes nothing: memory and tool execution are the caller's job. Providers now blur this: some APIs keep conversation state server-side, and some run tools for you (server-side web search, code execution, or an API-side MCP connector that calls a remote MCP server). Know which tools run on your side and which run on theirs, because that decides who sees the data and who enforces the limits.
Tool A function the model is allowed to call, declared as a schema (name, description, input shape). The model proposes, your code disposes. The model emits a structured "call X with these args"; your code runs it and returns the result. The model runs nothing itself. (For a provider-run server tool the provider's platform does the executing, but the model still only proposes.)
Agent Inference in a loop: model → tool call → execute → feed result back → model → … until a stop condition. The agent is the loop plus control layer, not the model. "Autonomy" is just how many steps run before a human is in the way.
MCP Model Context Protocol — an open standard (introduced by Anthropic in November 2024; donated in December 2025 to the Agentic AI Foundation, a Linux Foundation fund) for how a host connects to tools and data. A server exposes tools, resources and prompts; any client can plug in. Local servers talk over stdio; remote ones over Streamable HTTP, with OAuth 2.1 for authorization. It is a standard plug, not a model. It decouples who builds the tool from who builds the agent. It does not replace the API: the model still sees MCP tools as ordinary tool definitions.
Connector A packaged, usually hosted, integration to a specific service (mail, drive, chat, issue tracker). In practice often an MCP server someone else runs, with authentication handled for you. "Connector" is a product word and vendors use it differently; in several products it is literally a remote MCP server. It is a ready-made authenticated bridge so you do not build the integration.

The gotchas

Naming and concepts

  • "Agent" is overloaded. One model plus one tool call is not an agent. The engineering is in the loop and the control layer.
  • MCP does not replace an API, and a "connector" is usually not a different thing from MCP — it is MCP plus auth plus hosting, wearing a product name.
  • Tools are declarations, not permissions. The model can ask to call anything you declare; what it can actually do is entirely your enforcement. "The model called it" and "the model was able to" are different sentences.

Security and identity

  • Prompt injection through tool results. Untrusted content a tool returns — a web page, an email, a file — can carry instructions the model then follows. Tool output is data; the model may treat it as commands. Prompt injection is ranked first (LLM01) in the OWASP Top 10 for LLM Applications. Treat every tool result as untrusted input.
  • Confused deputy and token scope. A connector acts as some identity. Over-scoped credentials mean the agent can do anything that identity can. Always ask: whose identity does this agent act under, and what is the blast radius?
  • Untrusted servers. An MCP server describes its own tools; a malicious or compromised one can poison tool descriptions or exfiltrate arguments. Vet and pin servers; do not auto-trust a registry.
  • Token custody. A connector that holds your credentials is a single valuable target. Know where the tokens live and keep them off shared surfaces.
  • Authority laundering across agents. One agent doing what another was denied bypasses the permission decision. Permission boundaries have to be per-actor and enforced, not advisory.

Reliability and correctness

  • Statelessness makes context your problem. Every turn re-sends a growing history; it bloats, truncates, and drifts. Memory and compaction are engineering, not a model feature.
  • The loop can run away. A failing or garbage tool result can drive retries or oscillation. Step caps, timeouts, retries, circuit breakers, and a real stop condition are not optional — without them, cost is unbounded.
  • Non-determinism. The same task can take a different tool sequence run to run, which makes agents genuinely hard to test.
  • Tool descriptions are prompt engineering. Renaming a tool or editing its description changes when the model picks it. Version schemas like prompts.
  • Too many tools degrades selection. Accuracy at choosing the right tool tends to fall off as the set grows into the dozens (the exact point depends on the model and how similar the tools are; test it on yours); you need namespacing or routing. (A common mitigation is to hide most tools behind a search-and-load step rather than exposing all of them at once.)

Cost and latency

  • Cost and latency multiply by loop steps. Each step is a full model call. The honest unit is cost per completed task, not per token.
  • Tool round-trips add wall-clock time — network plus tool execution — and the model is not generating while it waits. On a dedicated deployment that is idle accelerator time. On a shared serving fleet the GPU serves other requests, but the waiting session either holds its KV cache in GPU memory or loses it and pays to re-prefill when the tool result arrives. Agents make that pattern the common case, not the exception.
  • Re-sent context inflates prompt tokens every turn, which is why prompt caching stops being a nicety and becomes load-bearing. Caching cuts the prefill compute and the price of the repeated prefix; it does not shrink the context window those tokens occupy.

Operational

  • The protocol is young and moving. The MCP spec and SDKs churn; the original HTTP+SSE transport was replaced by Streamable HTTP in the 2025-03-26 spec revision, which also moved authorization to OAuth 2.1. Budget for breakage.
  • Remote connectors are a new runtime dependency that can return an auth error, time out, or disappear. Your agent's reliability is now bounded by every connector's uptime and token validity.
  • Observability or bust. Without a trace of the whole loop — which tool, what arguments, what result, what the model did next — debugging an agent is guesswork. Instrument the loop before you scale it.

Physical AI

The reason to track these concepts, and not just file them, is that AI is moving out of the chat box and into machines that sense and actuate the real world — robots, drones, vehicles, industrial control, instrumented sensors. The stack above is unchanged. The stakes are not.

  • Latency becomes safety. A quarter-second of think-plus-tool latency is fine in a chat answer. Low-level motor and balance control runs in loops of roughly a millisecond to tens of milliseconds (estimate; it varies by machine), far faster than a large model can answer. So practical systems are layered: a model plans or picks the next skill at a slow rate, fast conventional controllers execute it, and the "waiting on a tool" pattern becomes "what does the machine do while the planner thinks?"
  • The model proposes; a deterministic safety layer disposes. The physical version of "tools are declarations, not permissions": speed and force limits, geofences and the emergency stop are enforced below the model, by components that do not take instructions from it. Functional-safety practice for machinery and robots (for example IEC 61508 and ISO 10218) already expects safety functions to be independent of the control software.
  • Security becomes physical action. A prompt injection that made a chat agent send a bad email can make an embodied agent perform a bad motion. Tool output is still untrusted data; now the downstream of trusting it is kinetic.
  • Identity becomes authority to actuate. The question shifts from "what can this agent read or post" to "what is this agent allowed to move, and under whose authority." Blast radius is measured in the physical world.
  • Reliability has kinetic consequences. A runaway or oscillating loop is a cost problem on a server and a hazard on a machine. Stop conditions, caps, and fallbacks become hard safety requirements.
  • Connectivity cannot assume always-on. Physical deployments live with intermittent, bandwidth-limited, or high-latency links. That forces a real decision about where inference runs (edge versus cloud), which tools are reachable offline, and what the machine does when a remote connector is simply unavailable.

The through-line: for physical AI, the connectivity architecture — where inference runs, how tools are reached, and what the agent is authorized to actuate — is not a detail under the model. It is the load-bearing design decision.

The one-line takeaway

Tools, MCP, and connectors are the capability surface. The agent loop is the control surface. Almost every hard problem — security, cost, reliability, and, for physical AI, safety — lives in the control surface, not in the model. That is the part worth owning.

Sources