Same agent, two clouds: connecting the agent to your systems

Tools are where an agent becomes useful, and also where it becomes dangerous. A model that only talks can be wrong. A model that calls your order system can be wrong at scale.

Part one of this series compared where the agent runs. This part covers how it reaches your systems. The support agent from ATC-001 has exactly two tools: search the company’s documents, and look up an order. Here’s how each cloud wires them up, and where each one puts the checks.

Both clouds settled on MCP

Not long ago, most agent frameworks had their own tool format. Now both AWS and Azure use the Model Context Protocol as the common interface. They turn your existing APIs into MCP tools, host MCP servers for you, and give the agent one MCP endpoint instead of a dozen integrations.

That makes the interesting question where the gate is. Every tool call should pass the same four checks, in this order:

You can build these checks into the agent’s own code, but it’s the wrong place. The agent is the part you trust least: it’s driven by a model and steered by whatever text it reads. The checks belong in a gateway the agent can’t talk its way around. Both clouds now offer one; they just draw the boundaries differently.

AWS: one gateway for everything

AgentCore Gateway is a single front door for all of an agent’s tools. You register targets, and the gateway presents them to the agent as one MCP server. Targets can be:

• an OpenAPI or Smithy description of a REST API
• a Lambda function
• an existing MCP server
• an API Gateway stage
• one-click connectors for Salesforce, Slack, Jira, Asana and Zendesk

The gateway can also pass traffic straight through to other agents on AgentCore Runtime, including A2A traffic. Those agents don’t appear as MCP tools.

Two features stand out.

Semantic tool search. Turn it on when you create the gateway, and the agent gets a search tool for finding the right tool by describing the task. With five tools this doesn’t matter. With two hundred it decides whether the agent can work at all, because sending every tool definition on every call fills the context window and the bill.

Policy outside the agent. AgentCore Policy, generally available since March, checks every tool call against rules before the call runs. The rules are written in Cedar, AWS’s open-source policy language. You can also write them in plain English and have them converted to Cedar, checked against the tool’s schema, and analyzed for rules that are too broad or that can never match. Policies can also track a session, for rules like “no more than three refunds per conversation”. Since June, the same layer can run Bedrock Guardrails on the inputs of every gateway call and the outputs of the actions it authorizes. Every decision is logged.

Credentials come from AgentCore Identity. The gateway accepts the agent’s OAuth token on the way in. On the way out, it uses whatever each target needs: IAM for Lambda; for REST APIs and MCP servers, API keys or OAuth (including flows that act on behalf of a signed-in user). Tokens and keys live in the Identity token vault, not in the agent’s code.

Azure: a toolbox for the agent, API Management for your APIs

Azure splits the same job across two products. Which one you use depends on whether the tool is an AI tool or an API you already run.

Foundry toolboxes group the tools one agent needs behind a single MCP endpoint, with managed authentication and versioning. You create a toolbox, test it, then promote it. A toolbox can hold MCP servers, OpenAPI tools, A2A connections to other agents, and most of Foundry’s built-in tools. Microsoft’s Foundry blog lists toolboxes as generally available as of this summer. A few tool types can’t go in a toolbox yet, including Bing grounding, computer use, SharePoint and the Azure Functions tool. Check the current list before you design around it.

Azure API Management is the other half. If your APIs already sit behind API Management, it can expose any managed REST API as an MCP server: each API operation becomes a tool. It can also sit in front of existing MCP servers and pass them through. All the usual API Management policies then apply to agent traffic: validating Entra tokens, rate limits, quotas, IP filtering and caching. There are limits:

• MCP servers in API Management expose tools only, not MCP resources or prompts.
• The Consumption tier isn’t among the supported tiers, and workspaces aren’t supported.

To write a new tool as code, the Azure Functions MCP extension turns a function into an MCP tool. Built-in Entra and OAuth authorization for it is in preview. If the tool has to call another API as the user, you implement the on-behalf-of flow yourself. You pay only the normal Functions plan.

Credentials come from Entra Agent ID, covered in part one. The agent presents its own identity token to the MCP endpoint, or a token that also carries the signed-in user’s identity when it acts on someone’s behalf. Further downstream, API Management or the function can use managed identities, so no secret has to sit in the agent.

The one gap today is policy that understands tool calls. Foundry guardrails can intervene on tool calls and tool responses, but that is still in preview. API Management policies are mature, but they see HTTP requests, not intentions like “issue a refund”. For rules about what an agent may do, Azure is a step behind AWS this year.

Side by side

AWS

Azure

• One endpoint for the agent

  AWS: AgentCore Gateway All targets behind one MCP server.

  Azure: Foundry toolbox A versioned tool set behind one MCP endpoint.

• Existing REST API as tools

  AWS: Gateway OpenAPI or API Gateway target Operations become MCP tools.

  Azure: API Management MCP server Operations become MCP tools. Not on the Consumption tier.

• New tool as code

  AWS: Lambda target IAM auth from the gateway.

  Azure: Functions MCP extension Built-in Entra and OAuth auth in preview.

• SaaS connectors

  AWS: One-click targets Salesforce, Slack, Jira, Asana, Zendesk.

  Azure: Built-in tools and Logic Apps SharePoint and Fabric built in (preview). Logic Apps agent workflows can use 1,400+ connectors.

• Finding a tool among many

  AWS: Semantic tool search A search tool built into the gateway.

  Azure: Tool search Preview.

• Rules about what the agent may do

  AWS: AgentCore Policy Cedar, per call and per session. GA.

  Azure: Guardrails on tool calls Preview. API Management policies cover HTTP-level rules.

• Credentials to the tool

  AWS: Identity token vault OAuth, API keys, user-delegated tokens.

  Azure: Managed identity, Entra Agent ID App-only or on behalf of the user.

The support agent’s two tools, on each cloud

Order lookup on AWS. Describe the orders API with an OpenAPI file, add it to a gateway as a target, and store its API key in the Identity token vault. Then write one Cedar policy that permits only the read operation, getOrder, so nothing else in that API is reachable even if the agent asks. For document search, the agent can call a Bedrock knowledge base directly, as in ATC-001, or through the gateway if you want every call logged in one place.

Order lookup on Azure. Import the same OpenAPI file into API Management and expose it as an MCP server. Add a policy that validates the agent’s Entra token and rate-limits it, and publish only the read operation as a tool. Put that MCP server in a toolbox together with file search over the company’s documents, and point the agent at the toolbox.

Both take about an afternoon. In both cases, the safety comes from the same decision: the agent can only read. It drafts replies, and a person sends them. Write access comes later, one operation at a time, each with its own rule.

What it costs

The pricing models differ more than the products do.

AWS bills per call. Gateway calls cost $0.005 per thousand, tool searches $0.025 per thousand, and indexing costs $0.02 per hundred tools a month. Policy adds $0.000025 per authorization. For the support agent’s 3,000 conversations a month with a handful of tool calls each, that comes to well under a dollar.

Azure bills by tier. API Management’s MCP support comes with the tier you run, and the Functions extension comes with the Functions plan. If you already run API Management for your APIs, agent tools add little. If you don’t, compare the tiers carefully: the classic tiers that support MCP are a fixed monthly cost likely to exceed everything else this agent uses, and Microsoft has announced a new AI Gateway tier whose pricing isn’t published yet. Until that settles, a small MCP tool on Azure Functions, connected to the agent directly, is the cheaper start.

Which way to go

• Your APIs already sit behind API Management: stay on Azure’s path. You reuse the policies, keys, monitoring and team you already have.
• Your APIs run on API Gateway and Lambda, or you need enforceable rules about what an agent may do today: AgentCore Gateway with Policy is the more complete answer right now.
• Either way, start the same way. One tool endpoint per agent. Read-only tools first. Every call logged. Credentials in the platform’s vault, never in a prompt or an environment variable the agent can read.

Next in the series: multi-agent workflows, meaning what happens when one agent isn’t enough, and how each cloud coordinates several.

---

Status and prices as of October 2026; preview features may change. Primary sources: AgentCore Gateway, Gateway targets, Gateway outbound auth, semantic tool search, AgentCore Policy, Policy with Guardrails, AgentCore pricing, Foundry toolboxes, What’s new in Foundry, July–August 2026, API Management MCP servers, Expose a REST API as MCP, Azure Functions MCP bindings, Foundry guardrails, Foundry agent identity.