III · Tool Use & EnvironmentMature★★

Agent Adapter

also known as Agent-Tool Bridge, Tool-Schema Adapter

An interface layer connecting an agent's tool-calling protocol to heterogeneous external tools, normalizing their schemas into one the agent expects.

Context

A team builds an agent that should use tools from multiple ecosystems (REST APIs, gRPC services, MCP servers, language-specific libraries, CLIs). Each tool has its own calling convention. Without adapters, the agent must know every convention.

Problem

Heterogeneous tools force the agent to handle multiple calling conventions or restrict to one ecosystem. Without an adapter pattern, integration with each new tool ecosystem is bespoke. Differs from tool-discovery (finding tools) and tool-loadout (curating) — adapter normalizes the *interface* to the tools the agent has already found and selected.

Forces

  • Adapter layer adds latency on every tool call.
  • Adapter must keep up with tool schema changes.
  • Designing the agent-facing canonical schema is upfront work.

Example

An agent uses {REST CRM, gRPC search service, MCP knowledge-base, Python pandas library, bash git CLI}. Five ecosystems, one canonical agent schema {tool_name, args, expected_output_type}. Five adapters translate the canonical call into the appropriate native invocation. Agent code does not know REST from gRPC from MCP.

Diagram

Solution

Therefore:

Define a canonical agent-facing tool schema (input fields, output schema, error model). Per external tool ecosystem (REST, gRPC, MCP, library, CLI), implement an adapter that translates {canonical request → native call} and {native response → canonical response}. Agent calls canonical interface only. Pair with mcp, tool-discovery, tool-loadout, agent-computer-interface.

What this pattern forbids. The agent calls only the canonical interface; native calls are forbidden from agent code; adapters live in a separate layer.

And the patterns that stand alongside it, or against it —

  • alternative-toModel Context Protocol★★— Standardise how agents discover and call tools so that a tool written once is usable by any conformant agent.
  • complementsTool Discovery★— Let the agent discover available tools at runtime rather than hardcoding the tool list at agent build time.
  • complementsTool Loadout★★— Select a small task-relevant subset of available tools per request rather than exposing the full registry to the model.
  • complementsAgent-Computer Interface★— Design the tool surface for an LLM agent specifically, with affordances different from human-facing CLIs.
  • complementsTool/Agent Registry★— Maintain a single queryable catalogue of both available tools and available agents, with metadata (capability, cost, latency, quality) the agent can use to pick the right one for a task.
  • complementsPerformative Message★★— Inter-agent messages are typed by communicative intent (request, inform, propose, accept, refuse, query) rather than by free-form prose, so receivers can dispatch on act type.
  • complementsBusiness + LLM Microservice Split★★— Split an LLM application into a CPU-bound business microservice (retrieval, prompt assembly, orchestration) and a GPU-bound LLM microservice (only model.generate behind REST), so each tier scales on its own hardware budget.
  • complementsCrawler Dispatcher★★— Route each incoming URL to a domain-specific crawler through a central dispatcher mapping URL patterns to registered crawler classes.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance