Claude in Microsoft Foundry: How to Connect Agents to Tools and MCP

AI agents become useful when they can do more than generate text. A production agent often needs to retrieve information, call business APIs, access databases, work with documents, or invoke specialized tools.

This creates an architecture problem: how should an AI model connect to those capabilities without tightly coupling every tool to the model itself?

Microsoft Foundry provides an environment for building and working with AI applications, while Model Context Protocol (MCP) provides a standardized way for AI applications to discover and interact with tools and resources.

Claude models available through Microsoft Foundry can therefore be used as part of an agent architecture where the model reasons about a task and tools provide the capabilities needed to complete it.

This article explains the architecture behind Claude-based agents, how MCP fits into the design, and how a .NET application can structure tool access safely.

Why Tools Matter for AI Agents

A language model is good at reasoning over information available in its context, but many real applications require actions outside that context.

Consider an internal support agent:

User
 |
 v
AI Agent
 |
 +----> Search Knowledge Base
 |
 +----> Check Order Status
 |
 +----> Create Support Ticket
 |
 +----> Retrieve Account Information

Without tools, the model can explain how to perform these operations, but it cannot necessarily perform them.

Tools provide an execution layer.

A tool might expose a simple operation such as:

public sealed record OrderStatus(
    string OrderId,
    string Status);

The agent can decide that it needs order information, invoke the appropriate tool, receive the result, and continue its reasoning.

The important architectural distinction is:

Model = reasoning
Tool = capability
Application = policy and execution

The model should not become the security boundary for the tool.

What Is Microsoft Foundry in This Architecture?

Microsoft Foundry can be used as a platform for developing AI applications and working with models and agent-oriented workloads.

In an application architecture, it can sit behind your application or orchestration layer:

+---------------------+
|      User           |
+----------+----------+
           |
           v
+---------------------+
|    Application      |
|    Orchestrator     |
+----------+----------+
           |
           v
+---------------------+
|  Model / Agent      |
|  Claude             |
+----------+----------+
           |
           v
+---------------------+
|     Tool Layer      |
+---------------------+

The application remains responsible for authorization, business rules, data access, and operational controls.

This separation is important for production systems.

What Is MCP?

Model Context Protocol, commonly called MCP, defines a standardized approach for connecting AI applications with external tools and resources.

Instead of creating a completely different integration mechanism for every model and tool combination, an MCP-based architecture can expose capabilities through a consistent protocol.

Conceptually:

+-------------+
| AI Agent    |
+------+------+
       |
       | MCP
       |
+------+------+
| MCP Server  |
+------+------+
       |
       +----> Database
       |
       +----> API
       |
       +----> Internal Service

The MCP server becomes an integration boundary.

For example, an internal order-management MCP server might expose:

get_order_status
search_orders
get_customer

The AI application can discover the available tools and use them when appropriate.

Claude + MCP + Foundry

A useful architecture combines these pieces:

                         +----------------+
                         |     User       |
                         +-------+--------+
                                 |
                                 v
                         +----------------+
                         | Application    |
                         | Orchestrator   |
                         +-------+--------+
                                 |
                                 v
                         +----------------+
                         | Claude Model   |
                         | in Foundry     |
                         +-------+--------+
                                 |
                                 | Tool request
                                 v
                         +----------------+
                         | MCP Client     |
                         +-------+--------+
                                 |
                                 v
                         +----------------+
                         | MCP Server     |
                         +-------+--------+
                                 |
                  +--------------+--------------+
                  |              |              |
                  v              v              v
               Orders         Search        Internal API

The model decides when a tool is useful, while the application and MCP infrastructure control how that tool is invoked.

Designing an MCP Tool

A tool should represent a meaningful business operation.

For example:

get_order_status

is generally easier for an agent to understand than a generic operation such as:

execute_database_query

A well-designed tool should have:

A clear name
A concise description
Explicit input parameters
A predictable response
Well-defined failure behavior
Appropriate authorization

For example, a request might conceptually look like:

{
  "orderId": "ORD-10025"
}

The tool should validate the identifier before accessing the underlying system.

Keep Business Logic Outside the Model

Suppose an agent asks for an order status.

Do not rely on the model to determine whether the current user is authorized to see that order.

The architecture should instead be:

User
 |
 v
Application Authorization
 |
 v
Agent
 |
 v
MCP Tool
 |
 v
Business Service
 |
 v
Database

Authorization should be enforced by the application or service layer.

This prevents a model from becoming the authority over sensitive business data.

A Simple .NET Tool Layer

A .NET application can keep tool execution behind an interface.

public interface IOrderService
{
    Task<OrderStatus?> GetStatusAsync(
        string orderId,
        CancellationToken cancellationToken);
}

The implementation can access the appropriate data source:

public sealed class OrderService : IOrderService
{
    public async Task<OrderStatus?> GetStatusAsync(
        string orderId,
        CancellationToken cancellationToken)
    {
        // Validate the request.
        // Check authorization.
        // Retrieve the order.
        // Return a controlled result.

        return await LoadOrderStatusAsync(
            orderId,
            cancellationToken);
    }

    private Task<OrderStatus?> LoadOrderStatusAsync(
        string orderId,
        CancellationToken cancellationToken)
    {
        // Data-access implementation.
        throw new NotImplementedException();
    }
}

The important point is that the AI integration should not bypass the existing business layer.

If the application already has authorization, validation, logging, and auditing, the agent should use those same controls.

Tool Descriptions Matter

An AI agent needs enough information to decide when a tool should be used.

For example, a tool description could communicate:

Retrieves the current status of an order.

Use this tool when the user asks about an existing order.
Do not use it to create or modify orders.
Requires an order identifier.

Clear descriptions reduce ambiguity.

Avoid descriptions such as:

Handles orders.

That does not tell the agent when the operation is appropriate.

A good tool description should explain the capability, intended use, important restrictions, and required input.

Limit the Data Returned by Tools

A tool should return only the information required for the task.

Suppose an order record contains:

Order ID
Customer ID
Status
Shipping Address
Payment Information
Internal Notes

If the user only asks for order status, the tool does not need to return every field.

Prefer:

{
  "orderId": "ORD-10025",
  "status": "Shipped"
}

over returning the complete database record.

This reduces unnecessary data exposure and keeps the model's context focused.

Handle Tool Errors Explicitly

Tool calls can fail.

Examples include:

Invalid input
Authorization failure
Service unavailable
Timeout
Missing record
Rate limiting

The tool layer should distinguish these cases.

For example:

public sealed record ToolResult<T>(
    bool Success,
    T? Data,
    string? ErrorCode,
    string? ErrorMessage);

An agent can then receive a controlled failure instead of an infrastructure exception containing internal implementation details.

Do not expose stack traces, connection strings, internal hostnames, or other sensitive infrastructure information to the model unless there is a specific reason to do so.

Protect Tool Calls From Abuse

An AI agent can potentially invoke tools repeatedly.

Consider a tool that queries an expensive external API.

Without controls, an agent could generate many requests during a single conversation.

Add controls such as:

Rate limits
Timeouts
Maximum tool calls
Input validation
Authorization
Audit logging
Cost controls

For sensitive operations, consider requiring explicit user confirmation before execution.

For example:

Read customer profile → Automatic
Create support ticket → Automatic or policy-based
Delete customer data → Explicit confirmation
Issue refund → Explicit authorization

The exact policy depends on the business process.

Avoid Giving Agents Generic Database Access

One of the most important design decisions is to avoid exposing a generic SQL execution tool unless the use case genuinely requires it.

This:

execute_sql(query)

provides extremely broad capability.

A narrower interface is easier to control:

get_customer
get_order_status
search_products

The narrower approach provides clearer boundaries and makes authorization easier to reason about.

MCP Security Considerations

MCP makes tool integration more structured, but the protocol does not eliminate the need for application security.

Consider:

Authentication

Verify which application or user is making the request.

Authorization

Determine which tools the caller is allowed to use.

Input Validation

Validate all parameters before execution.

Output Filtering

Return only information required for the task.

Auditing

Record important tool calls.

Rate Limiting

Prevent uncontrolled repeated operations.

Secret Management

Keep credentials outside prompts and model-generated content.

These controls should exist regardless of which model is being used.

Common Mistakes

Treating the Model as a Security Boundary

The model should not decide whether a user is authorized to access a resource.

Enforce authorization in application code.

Exposing Too Many Tools

Giving an agent dozens of overlapping tools can make tool selection more difficult.

Start with the smallest useful toolset.

Creating Generic Tools

Generic database or shell tools can provide more capability than the agent actually needs.

Prefer narrowly scoped business operations.

Returning Excessive Data

Tool responses should contain the information needed for the task, not entire database records.

Ignoring Tool Failures

Agents need predictable failure responses.

Return controlled errors rather than leaking infrastructure details.

Skipping Auditing

For business-critical operations, record who initiated the operation, what tool was called, and the outcome.

Advantages and Disadvantages

Advantages

Using Claude with a standardized tool layer can provide:

Clear separation between reasoning and execution
Reusable integrations
Structured tool discovery
Easier integration with existing services
Better control over business operations
A consistent architecture for agent applications

Disadvantages

The architecture also introduces:

Additional integration components
Tool-definition and maintenance overhead
More security boundaries to manage
Potential latency from multiple tool calls
More complex debugging
The need for careful authorization and auditing

MCP should therefore be treated as an integration mechanism, not as a replacement for application architecture.

A Practical Implementation Strategy

For a production application, start with a small number of well-defined tools.

Step 1: Identify Real Business Operations

List the operations the agent actually needs.

Step 2: Create Narrow Tool Contracts

Avoid generic access to databases or operating-system commands.

Step 3: Reuse Existing Business Services

Keep authorization and business rules in the service layer.

Step 4: Add MCP Integration

Expose only the approved operations.

Step 5: Test Tool Selection

Give the agent realistic requests and verify that it selects the correct tool.

Step 6: Test Unauthorized Requests

Confirm that the tool layer rejects operations the user should not perform.

Step 7: Add Observability

Track tool calls, failures, latency, and important business operations.

Step 8: Expand Gradually

Add new tools only when there is a clear use case.

Summary

Claude, Microsoft Foundry, and MCP can work together as part of a modern agent architecture where the model handles reasoning and external tools provide real capabilities.

The safest implementations use narrowly scoped tools, preserve existing authorization and business logic, validate every request, minimize returned data, control tool usage, and maintain strong observability.

MCP can simplify the connection between agents and tools, but secure agent development still depends on the application architecture surrounding the model.

This creates an architecture problem: how should an AI model connect to those capabilities without tightly coupling every tool to the model itself?

Claude models available through Microsoft Foundry can therefore be used as part of an agent architecture where the model reasons about a task and tools provide the capabilities needed to complete it.

This article explains the architecture behind Claude-based agents, how MCP fits into the design, and how a .NET application can structure tool access safely.

Why Tools Matter for AI Agents

A language model is good at reasoning over information available in its context, but many real applications require actions outside that context.

Consider an internal support agent:

User
 |
 v
AI Agent
 |
 +----> Search Knowledge Base
 |
 +----> Check Order Status
 |
 +----> Create Support Ticket
 |
 +----> Retrieve Account Information

Without tools, the model can explain how to perform these operations, but it cannot necessarily perform them.

Tools provide an execution layer.

A tool might expose a simple operation such as:

public sealed record OrderStatus(
    string OrderId,
    string Status);

The agent can decide that it needs order information, invoke the appropriate tool, receive the result, and continue its reasoning.

The important architectural distinction is:

Model = reasoning
Tool = capability
Application = policy and execution

The model should not become the security boundary for the tool.

What Is Microsoft Foundry in This Architecture?

Microsoft Foundry can be used as a platform for developing AI applications and working with models and agent-oriented workloads.

In an application architecture, it can sit behind your application or orchestration layer:

+---------------------+
|      User           |
+----------+----------+
           |
           v
+---------------------+
|    Application      |
|    Orchestrator     |
+----------+----------+
           |
           v
+---------------------+
|  Model / Agent      |
|  Claude             |
+----------+----------+
           |
           v
+---------------------+
|     Tool Layer      |
+---------------------+

The application remains responsible for authorization, business rules, data access, and operational controls.

This separation is important for production systems.

What Is MCP?

Model Context Protocol, commonly called MCP, defines a standardized approach for connecting AI applications with external tools and resources.

Instead of creating a completely different integration mechanism for every model and tool combination, an MCP-based architecture can expose capabilities through a consistent protocol.

Conceptually:

+-------------+
| AI Agent    |
+------+------+
       |
       | MCP
       |
+------+------+
| MCP Server  |
+------+------+
       |
       +----> Database
       |
       +----> API
       |
       +----> Internal Service

The MCP server becomes an integration boundary.

For example, an internal order-management MCP server might expose:

get_order_status
search_orders
get_customer

The AI application can discover the available tools and use them when appropriate.

Claude + MCP + Foundry

A useful architecture combines these pieces:

                         +----------------+
                         |     User       |
                         +-------+--------+
                                 |
                                 v
                         +----------------+
                         | Application    |
                         | Orchestrator   |
                         +-------+--------+
                                 |
                                 v
                         +----------------+
                         | Claude Model   |
                         | in Foundry     |
                         +-------+--------+
                                 |
                                 | Tool request
                                 v
                         +----------------+
                         | MCP Client     |
                         +-------+--------+
                                 |
                                 v
                         +----------------+
                         | MCP Server     |
                         +-------+--------+
                                 |
                  +--------------+--------------+
                  |              |              |
                  v              v              v
               Orders         Search        Internal API

The model decides when a tool is useful, while the application and MCP infrastructure control how that tool is invoked.

Designing an MCP Tool

A tool should represent a meaningful business operation.

For example:

get_order_status

is generally easier for an agent to understand than a generic operation such as:

execute_database_query

A well-designed tool should have:

A clear name
A concise description
Explicit input parameters
A predictable response
Well-defined failure behavior
Appropriate authorization

For example, a request might conceptually look like:

{
  "orderId": "ORD-10025"
}

The tool should validate the identifier before accessing the underlying system.

Keep Business Logic Outside the Model

Suppose an agent asks for an order status.

Do not rely on the model to determine whether the current user is authorized to see that order.

The architecture should instead be:

User
 |
 v
Application Authorization
 |
 v
Agent
 |
 v
MCP Tool
 |
 v
Business Service
 |
 v
Database

Authorization should be enforced by the application or service layer.

This prevents a model from becoming the authority over sensitive business data.

A Simple .NET Tool Layer

A .NET application can keep tool execution behind an interface.

public interface IOrderService
{
    Task<OrderStatus?> GetStatusAsync(
        string orderId,
        CancellationToken cancellationToken);
}

The implementation can access the appropriate data source:

public sealed class OrderService : IOrderService
{
    public async Task<OrderStatus?> GetStatusAsync(
        string orderId,
        CancellationToken cancellationToken)
    {
        // Validate the request.
        // Check authorization.
        // Retrieve the order.
        // Return a controlled result.

        return await LoadOrderStatusAsync(
            orderId,
            cancellationToken);
    }

    private Task<OrderStatus?> LoadOrderStatusAsync(
        string orderId,
        CancellationToken cancellationToken)
    {
        // Data-access implementation.
        throw new NotImplementedException();
    }
}

The important point is that the AI integration should not bypass the existing business layer.

If the application already has authorization, validation, logging, and auditing, the agent should use those same controls.

Tool Descriptions Matter

An AI agent needs enough information to decide when a tool should be used.

For example, a tool description could communicate:

Retrieves the current status of an order.

Use this tool when the user asks about an existing order.
Do not use it to create or modify orders.
Requires an order identifier.

Clear descriptions reduce ambiguity.

Avoid descriptions such as:

Handles orders.

That does not tell the agent when the operation is appropriate.

A good tool description should explain the capability, intended use, important restrictions, and required input.

Limit the Data Returned by Tools

A tool should return only the information required for the task.

Suppose an order record contains:

Order ID
Customer ID
Status
Shipping Address
Payment Information
Internal Notes

If the user only asks for order status, the tool does not need to return every field.

Prefer:

{
  "orderId": "ORD-10025",
  "status": "Shipped"
}

over returning the complete database record.

This reduces unnecessary data exposure and keeps the model's context focused.

Handle Tool Errors Explicitly

Tool calls can fail.

Examples include:

Invalid input
Authorization failure
Service unavailable
Timeout
Missing record
Rate limiting

The tool layer should distinguish these cases.

For example:

public sealed record ToolResult<T>(
    bool Success,
    T? Data,
    string? ErrorCode,
    string? ErrorMessage);

An agent can then receive a controlled failure instead of an infrastructure exception containing internal implementation details.

Do not expose stack traces, connection strings, internal hostnames, or other sensitive infrastructure information to the model unless there is a specific reason to do so.

Protect Tool Calls From Abuse

An AI agent can potentially invoke tools repeatedly.

Consider a tool that queries an expensive external API.

Without controls, an agent could generate many requests during a single conversation.

Add controls such as:

Rate limits
Timeouts
Maximum tool calls
Input validation
Authorization
Audit logging
Cost controls

For sensitive operations, consider requiring explicit user confirmation before execution.

For example:

Read customer profile → Automatic
Create support ticket → Automatic or policy-based
Delete customer data → Explicit confirmation
Issue refund → Explicit authorization

The exact policy depends on the business process.

Avoid Giving Agents Generic Database Access

One of the most important design decisions is to avoid exposing a generic SQL execution tool unless the use case genuinely requires it.

This:

execute_sql(query)

provides extremely broad capability.

A narrower interface is easier to control:

get_customer
get_order_status
search_products

The narrower approach provides clearer boundaries and makes authorization easier to reason about.

MCP Security Considerations

MCP makes tool integration more structured, but the protocol does not eliminate the need for application security.

Consider:

Authentication

Verify which application or user is making the request.

Authorization

Determine which tools the caller is allowed to use.

Input Validation

Validate all parameters before execution.

Output Filtering

Return only information required for the task.

Auditing

Record important tool calls.

Rate Limiting

Prevent uncontrolled repeated operations.

Secret Management

Keep credentials outside prompts and model-generated content.

These controls should exist regardless of which model is being used.

Common Mistakes

Treating the Model as a Security Boundary

The model should not decide whether a user is authorized to access a resource.

Enforce authorization in application code.

Exposing Too Many Tools

Giving an agent dozens of overlapping tools can make tool selection more difficult.

Start with the smallest useful toolset.

Creating Generic Tools

Generic database or shell tools can provide more capability than the agent actually needs.

Prefer narrowly scoped business operations.

Returning Excessive Data

Tool responses should contain the information needed for the task, not entire database records.

Ignoring Tool Failures

Agents need predictable failure responses.

Return controlled errors rather than leaking infrastructure details.

Skipping Auditing

For business-critical operations, record who initiated the operation, what tool was called, and the outcome.

Advantages and Disadvantages

Advantages

Using Claude with a standardized tool layer can provide:

Clear separation between reasoning and execution
Reusable integrations
Structured tool discovery
Easier integration with existing services
Better control over business operations
A consistent architecture for agent applications

Disadvantages

The architecture also introduces:

Additional integration components
Tool-definition and maintenance overhead
More security boundaries to manage
Potential latency from multiple tool calls
More complex debugging
The need for careful authorization and auditing

MCP should therefore be treated as an integration mechanism, not as a replacement for application architecture.

A Practical Implementation Strategy

For a production application, start with a small number of well-defined tools.

Step 1: Identify Real Business Operations

List the operations the agent actually needs.

Step 2: Create Narrow Tool Contracts

Avoid generic access to databases or operating-system commands.

Step 3: Reuse Existing Business Services

Keep authorization and business rules in the service layer.

Step 4: Add MCP Integration

Expose only the approved operations.

Step 5: Test Tool Selection

Give the agent realistic requests and verify that it selects the correct tool.

Step 6: Test Unauthorized Requests

Confirm that the tool layer rejects operations the user should not perform.

Step 7: Add Observability

Track tool calls, failures, latency, and important business operations.

Step 8: Expand Gradually

Add new tools only when there is a clear use case.

Summary

Claude, Microsoft Foundry, and MCP can work together as part of a modern agent architecture where the model handles reasoning and external tools provide real capabilities.

MCP can simplify the connection between agents and tools, but secure agent development still depends on the application architecture surrounding the model.