2.2. Adding Tools to Agents
💡 First Principle: Tools are how an agent reaches past the conversation and changes the world — and the four tool types are really one decision tree about what already exists. A maintained connector exists? Use it. Only an API exists? Wrap or import it. The API should evolve without republishing? MCP. Nothing but a UI exists? Computer use. The exam tests whether you pick the least exotic option that satisfies the scenario.
Choosing wrong is expensive in opposite directions: rebuilding a stable, certified connector as a custom integration wastes engineering, while pointing computer use at a system with a perfectly good API buys fragility and per-step billing for nothing.
| Tool type | What must exist | Change management | When it's the answer |
|---|---|---|---|
| Connector (prebuilt/custom) | A connector, or an OpenAPI definition you wrap | Republish on change | Stable API, governed access via DLP |
| REST API (direct add) | An API spec you can import | Republish on change | API exists, no connector yet, single-agent use |
| MCP tools | An MCP server | Server updates propagate live | Evolving toolset, shared across many agents |
| Computer use | Only a UI (web or desktop) | Instructions adapt to UI drift | No API at all; UI automation as last resort |
⚠️ Common Misconception: MCP tools and custom connectors are interchangeable. The difference is when the capability list is fixed: a custom connector freezes its operations at publish time; an MCP server advertises its tools at run time, so server-side additions reach every connected agent with no republishing.
