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.
Join the conversation! Your thoughts help the community grow.