2.2.4. REST APIs as Tools
💡 First Principle: The REST API tool path collapses the distance between "we have an API spec" and "the agent can call it" — you import the OpenAPI description directly into the agent, configure authentication, and the operations become tools without a connector standing in between.
This is the pragmatic middle of the tool spectrum. Compared to building a custom connector, importing an API is faster and lives with the agent — well-suited to an integration only this agent needs. Compared to MCP, there's no server to build or maintain, at the cost of static operations that update only when you re-import the changed spec. During import you choose which operations to expose, supply per-operation descriptions the orchestrator will route on, and configure how the API authenticates (such as API keys or OAuth-based flows).
The quality of the OpenAPI description does the heavy lifting. Operation summaries become the raw material for tool descriptions; parameter schemas tell the orchestrator what inputs to collect from the user or from context. A vague spec produces a tool the orchestrator can't route to — the same failure mode as a badly described topic, surfacing one layer down.
When the same API should serve many agents (or apps and flows too), promote it: wrap it as a custom connector for governance and reuse, or expose it via MCP if its surface evolves quickly. The exam expects you to feel that promotion pressure in scenarios that mention multiple consuming teams.
⚠️ Exam Trap: Distinguish scope — REST-API-as-tool binds an API to one agent; a custom connector publishes it for the environment; an MCP server shares it dynamically across any connected client. Scenarios about "reuse across agents/teams" are eliminating the direct-import answer.
Reflection Question: A data science team hands you the OpenAPI spec for a scoring service that only your triage agent will call. Which tool path fits today, and which two signals in a future scenario would tell you it's time to promote it?
