Microsoft Foundry Claude Agents: Testing Web Search, Web Fetch, and Tool Use

A model endpoint can answer questions, generate code, summarize documents, and classify text. But production AI agents need to do more. They need to retrieve current information, access external systems, select the right tool, and return predictable output.

Microsoft Foundry is moving Claude deployments in that direction.

Microsoft announced five new Claude capabilities in Foundry: structured outputs, web search, web fetch, MCP connector, and tool search. These capabilities are available for Claude models hosted on Azure in Microsoft Foundry, bringing more agent-oriented functionality directly into the managed platform.

For developers, the interesting part is not simply that Claude can call more tools. The more important question is how these capabilities change the architecture of a production agent.

This article looks at the role of each capability, how to test them, where they fit in a .NET application, and what developers should consider before putting a tool-enabled Claude agent into production.

From Model Calls to Agent Workflows

A traditional LLM application often follows a relatively simple flow:

User
  |
  v
Application
  |
  v
Claude Model
  |
  v
Response

An agent introduces additional steps:

User
  |
  v
Agent
  |
  +---- Search the web
  |
  +---- Fetch a page
  |
  +---- Call an MCP server
  |
  +---- Search available tools
  |
  +---- Produce structured output
  |
  v
Final Response

The model is no longer limited to information included in the prompt.

Microsoft describes the newly available capabilities as building blocks for moving from a single model call toward production agent workflows.

That distinction matters because tool use introduces new engineering concerns: permissions, latency, failures, untrusted external data, observability, and cost.

What the Five New Capabilities Provide

The five capabilities address different parts of the agent architecture.

Capability	Primary Purpose	Example
Structured outputs	Predictable response format	Return an order-analysis JSON object
Web search	Find current public information	Search current documentation
Web fetch	Retrieve content from a specific page	Read a known documentation page
MCP connector	Connect to external MCP services	Query an internal business system
Tool search	Discover relevant tools dynamically	Select one tool from a large catalog

These capabilities should not be treated as interchangeable.

A web search tool answers the question, "What relevant information exists?"

A web fetch operation answers, "What does this particular resource contain?"

Tool search answers, "Which available capability should I use?"

MCP provides a standardized connection mechanism for external tools and services.

Structured output solves a different problem entirely: "How should the agent's result be represented so my application can consume it safely?"

Web Search for Current Information

Web search is useful when the agent needs information that can change after the model's training data.

Microsoft Foundry's web search tooling can ground an agent's response with current public web information and return source citations. The underlying web grounding uses Bing services.

A conceptual workflow is:

User Question
      |
      v
Claude Agent
      |
      v
Determine Information Gap
      |
      v
Web Search
      |
      v
Search Results
      |
      v
Claude
      |
      v
Grounded Response + Sources

For example, a developer could build an agent that answers questions about the latest framework documentation.

The application does not need to download every webpage itself. The hosted search capability can perform the search and return information for the agent to use.

Microsoft's current documentation also shows web search support across Python, C#, JavaScript, Java, and REST scenarios.

Web Fetch for Known Sources

Search and fetch solve different problems.

Suppose an agent searches for documentation and identifies the exact page it needs.

The next step can be fetching that specific resource.

Conceptually:

Search
  |
  +---- Result A
  +---- Result B
  +---- Result C
          |
          v
     Select relevant URL
          |
          v
       Web Fetch
          |
          v
    Page content
          |
          v
     Agent reasoning

This is useful for workflows where the agent needs to inspect a known web resource instead of relying only on search-result snippets.

However, web content should be treated as untrusted input.

Microsoft's web-search guidance explicitly recommends validating and sanitizing web-search results before using them in downstream systems and avoiding secrets or sensitive personal data in prompts that may be sent to external services.

MCP Connector: Connecting External Tools

The Model Context Protocol provides a standardized way for AI applications to interact with external tools and resources.

An MCP-enabled agent can potentially interact with systems such as:

Claude Agent
    |
    +---- MCP Server
             |
             +---- Issue tracker
             +---- Documentation
             +---- Internal APIs
             +---- Business systems

This creates a significant architectural advantage: the agent does not have to contain custom integration logic for every external system.

But it also increases the security boundary.

An MCP connection should be treated like an application integration, not simply as another prompt feature.

The team should understand:

What tools are exposed?
What data can be read?
What actions can be performed?
What authentication is required?
What happens if the MCP server is unavailable?
Are tool calls logged?
Can the agent modify production data?

Tool Search for Large Tool Catalogs

A common problem appears when an agent has access to many tools.

Suppose an enterprise agent has:

100+ tools
   |
   +-- CRM
   +-- Finance
   +-- HR
   +-- Engineering
   +-- Documentation
   +-- Operations
   +-- Analytics

Giving the model the complete definition of every tool can increase context usage and make tool selection harder.

Tool search provides a mechanism for discovering relevant tools when they are needed.

The conceptual difference is:

Static Tools

Agent
 |
 +-- Tool A
 +-- Tool B
 +-- Tool C
 +-- Tool D
 +-- ...100 more


Tool Discovery

Agent
 |
 v
Search Tool Catalog
 |
 v
Relevant Tools
 |
 +-- Tool C
 +-- Tool K
 |
 v
Execute

This is particularly interesting for enterprise environments because tool catalogs can grow considerably as more internal services become agent-accessible.

Structured Outputs for Reliable Application Integration

Agent responses are often consumed by another piece of software.

Parsing arbitrary natural-language text is fragile.

Structured output allows the application to request a predictable schema.

For example, an order-analysis workflow might expect:

{
  "orderId": "ORD-10025",
  "riskLevel": "medium",
  "requiresReview": true,
  "reasons": [
    "Unusual order value",
    "Address verification required"
  ]
}

The application can then deserialize the response into a strongly typed object.

In C#, that could look like:

public sealed class OrderRiskResult
{
    public string OrderId { get; set; } = string.Empty;
    public string RiskLevel { get; set; } = string.Empty;
    public bool RequiresReview { get; set; }
    public List<string> Reasons { get; set; } = [];
}

The important architectural point is that structured output should be used where the result becomes application data.

Do not force every conversational response into a rigid schema when a normal natural-language response is more appropriate.

A Practical Agent Architecture

A production-oriented application could combine these capabilities like this:

                   ┌───────────────────┐
                   │   ASP.NET Core    │
                   │       API         │
                   └─────────┬─────────┘
                             |
                             v
                   ┌───────────────────┐
                   │   Claude Agent    │
                   └─────────┬─────────┘
                             |
          ┌──────────────────┼──────────────────┐
          |                  |                  |
          v                  v                  v
     Web Search          Tool Search        MCP Connector
          |                  |                  |
          v                  v                  v
      Public Web       Tool Catalog       External System
          |
          v
      Web Fetch

                             |
                             v
                    Structured Output
                             |
                             v
                      ASP.NET Core

The application should remain responsible for business rules, authorization, validation, and critical state changes.

The agent should not become the only enforcement layer.

Testing Tool Selection

Tool use should be tested separately from answer quality.

Create a test set such as:

Test Case	Expected Tool
Current technology announcement	Web search
Read specific documentation URL	Web fetch
Query internal project system	MCP
Find capability from large tool catalog	Tool search
Return machine-readable result	Structured output

Then measure:

Correct tool selection
Incorrect tool selection
Tool-call latency
Failed calls
Number of tool calls
Final response quality
Citation quality
Recovery behavior

A useful test record could look like:

test_case,expected_tool,selected_tool,success,latency_ms,retries
current_docs,web_search,web_search,true,850,0
known_page,web_fetch,web_fetch,true,620,0
project_lookup,mcp,mcp,true,410,0
tool_discovery,tool_search,tool_search,true,730,0

These values are illustrative rather than benchmark results.

The important thing is to establish measurements from your own workload.

Testing Web Search Failures

External web access can fail.

Possible conditions include:

Search timeout
Rate limiting
Empty results
Irrelevant results
Blocked domains
Service outages
Incorrect or stale information

A robust application should not assume that search always succeeds.

For example:

public async Task<string> GetResearchResultAsync(
    string question,
    CancellationToken cancellationToken)
{
    try
    {
        // Invoke the configured agent workflow here.
        return await RunAgentAsync(question, cancellationToken);
    }
    catch (OperationCanceledException)
    {
        throw;
    }
    catch (Exception ex)
    {
        // Log the failure and return a controlled fallback.
        _logger.LogError(ex, "Agent research failed.");

        return "The requested research service is temporarily unavailable.";
    }
}

The exact exception handling depends on the SDK and application architecture, but the principle is important: external tools are dependencies and must be handled as such.

Microsoft's documentation also lists rate limiting and deployment availability among issues developers may encounter with web search.

Security Considerations

Tool-enabled agents create a larger attack surface than ordinary chat applications.

Treat External Content as Untrusted

A webpage can contain instructions designed to influence an agent.

The fact that content came from a search result does not make it trustworthy.

Protect Secrets

Do not place API keys, passwords, connection strings, or other sensitive information into prompts sent to external services.

Microsoft specifically warns against sending secrets or sensitive personal data when using web search.

Apply Least Privilege

An MCP tool that only needs read access should not receive write permissions.

Validate Agent Output

Structured output improves consistency, but application-level validation is still necessary before critical operations.

Keep Authorization Outside the Model

For example:

User
 |
 v
ASP.NET Authorization
 |
 v
Agent
 |
 v
MCP Tool

Do not depend on the model deciding whether a user is authorized to perform a sensitive operation.

Common Mistakes

Treating Web Search as a Database

Search results are not equivalent to authoritative application data.

Use internal systems of record when correctness and consistency matter.

Giving an Agent Too Many Tools

More tools do not automatically make an agent better.

Large tool catalogs should be organized and tested for discovery and selection.

Allowing Direct Production Writes

A tool-enabled agent should not automatically receive unrestricted production write access.

Use controlled APIs and explicit authorization.

Ignoring Latency

A request that invokes search, fetch, MCP, and several model calls can become much slower than a simple model request.

Measure end-to-end latency.

Skipping Failure Testing

A successful demo proves very little about production reliability.

Test unavailable tools, timeouts, invalid responses, and partial failures.

Troubleshooting Checklist

When a Claude agent fails to use a tool correctly, check the following:

Verify that the model deployment supports the required capability.
Confirm that the tool is configured correctly.
Check authentication and project permissions.
Inspect tool-call logs and request IDs.
Test the tool independently where possible.
Verify that the MCP server is reachable.
Reduce the number of available tools when diagnosing selection problems.
Test with a small, deterministic prompt.
Check rate limits and service availability.
Validate the final response separately from tool execution.

For web search specifically, Microsoft recommends checking model and regional availability when the tool is unavailable.

Best Practices for Production

Start With One Tool

Do not introduce five capabilities simultaneously.

Start with a clear workflow such as web search, validate it, then add additional tools.

Separate Discovery From Execution

Tool search should identify capabilities; authorization should determine whether the agent is actually permitted to use them.

Measure Every Tool Call

Record:

Agent request
    |
    +-- Tool selected
    +-- Tool latency
    +-- Tool result status
    +-- Retry count
    +-- Model latency
    +-- Final result

This makes production troubleshooting substantially easier.

Build Explicit Fallbacks

If web search is unavailable, decide whether the agent should:

Use cached information
Ask the user to retry
Use an internal knowledge source
Return a controlled failure

Do not leave this behavior to chance.

Keep Critical Business Logic Deterministic

Use the agent for reasoning and orchestration where appropriate, but keep financial calculations, authorization decisions, database constraints, and other critical rules under deterministic application control.

Advantages and Disadvantages

Advantages	Disadvantages
Current web information	External dependency
Standardized external tool access	Larger security surface
Dynamic tool discovery	Tool-selection complexity
Predictable structured responses	Additional schema management
More capable agent workflows	Potentially higher latency
Azure-hosted Claude agent capabilities	Requires careful governance

Final Thoughts

The latest Claude capabilities in Microsoft Foundry represent an important shift from using an LLM as an isolated API toward using it as part of a connected agent architecture.

Web search gives agents access to current public information. Web fetch allows them to inspect specific resources. MCP connects them to external tools and systems. Tool search becomes increasingly useful as the available tool catalog grows. Structured outputs provide a safer bridge between agent responses and application code. Microsoft has made these five capabilities available for Claude models hosted on Azure in Foundry, reducing the need to build every piece of the agent toolchain independently.

But adding tools is only the beginning.

A production agent needs the same engineering discipline as any other distributed application: clear boundaries, authentication, authorization, observability, retries, validation, failure handling, and security controls.

The strongest implementation is therefore not the agent with the most tools. It is the agent that has the right tools, the right permissions, and a clearly defined responsibility for each tool call.