AI Agents
MCP for Azure AI agents: when and how to use it
Understand Model Context Protocol, its role in agent tooling, and the decisions that matter in Azure deployments.
Documentation checked: verified against the official references below on October 3, 2026. Product names, preview status, and certification objectives can change.
What MCP changes
Model Context Protocol provides a standard interface through which AI applications can discover and use external tools and contextual data. The protocol reduces one-off client integrations, but it does not make a tool trustworthy, safe, or appropriate by itself.
- A client or agent connects to an MCP server
- The server advertises available capabilities
- The model can request a tool call
- The application governs approval and execution
- The tool result returns as untrusted context
Where it fits in Microsoft Foundry
Foundry Agent Service can connect agents to remote MCP endpoints. Current Microsoft guidance supports project connections for authentication, tool allowlists, per-call approval behavior, and both public and private endpoint patterns.
- Use a unique server label for each connection
- Restrict access with allowed_tools instead of exposing everything
- Keep approval enabled for consequential operations
- Use project connections rather than placing credentials in prompts
- Test connectivity and behavior before production use
Choose MCP for interoperability
MCP is valuable when multiple agents or clients should reuse a maintained capability, when a tool catalog evolves independently, or when a platform team needs centralized versioning and policy enforcement.
- Shared enterprise tool catalogs
- Reusable developer and operations integrations
- Independently deployed tool services
- Governed Foundry Toolboxes
- Cross-client integration with the same server contract
Use a direct API when it is simpler
A direct function call may be easier to secure, test, and operate when one application calls one stable internal API. Do not add a protocol layer merely because MCP is popular.
- One caller and one stable operation
- Tight latency requirements
- Existing typed SDK with mature authorization
- No need for dynamic discovery or cross-client reuse
Treat the server as a trust boundary
Remote server descriptions, annotations, tool outputs, and errors can contain misleading or malicious content. A model seeing a tool does not mean it should be allowed to call it.
- Review who operates the server and where data is processed
- Authenticate the caller and authorize each operation
- Validate every argument against a strict schema
- Constrain outbound network access
- Log tool identity, decision, outcome, and approval without recording unnecessary secrets
Design approval around consequences
Read-only lookup and irreversible action should not share the same approval policy. Classify tools by consequence and require explicit human approval for actions that create, modify, send, purchase, grant access, or delete.
- Read: low-risk lookup with bounded output
- Draft: generate a proposed change without applying it
- Write: modify a reversible record with confirmation
- Consequential: require clear review of tool name and arguments
- Destructive: add stronger authorization and recovery controls
Public and private endpoint decisions
A public endpoint can simplify connectivity but increases exposure. A private endpoint reduces public reachability but adds network, DNS, hosting, and operational work. Select the pattern from the threat model and data classification rather than convenience alone.
- Verify supported authentication for the chosen endpoint
- Use dedicated network boundaries for private hosting
- Apply least-privilege role assignments
- Plan health checks, timeouts, retries, and version rollout
Test the full tool lifecycle
A successful connection is only the first test. Validate discovery, selection, input generation, approval, execution, output use, errors, timeouts, unavailable dependencies, and attempts to manipulate the agent through tool content.
- Correct tool selected for the task
- Arguments are valid and authorized
- Denied approval stops execution
- Failures do not trigger unsafe retries
- Results are interpreted without following embedded instructions
A practical first implementation
Start with one read-only tool in a non-production environment. Restrict the allowlist, retain approval, use a test identity with minimal access, and create a small evaluation set before adding more capabilities.
- Five expected successful requests
- Five requests the tool must reject
- Two unavailable-service scenarios
- Two malicious or misleading tool-result scenarios
- A documented cleanup and credential-rotation path
Official sources
Use these primary references to verify product capabilities, exam objectives, and implementation details.
Put this into practice
Apply the tool boundaries and approval model from this guide to the agent guardrails checklist.
Open resource