{"id":2848,"date":"2026-08-17T12:20:07","date_gmt":"2026-08-17T19:20:07","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/foundry\/?p=2848"},"modified":"2026-08-17T12:20:07","modified_gmt":"2026-08-17T19:20:07","slug":"five-new-claude-capabilities-now-available-in-foundry","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/foundry\/five-new-claude-capabilities-now-available-in-foundry\/","title":{"rendered":"From single call to agents: five new Claude capabilities now available in Microsoft Foundry"},"content":{"rendered":"

From single call to agents: five new Claude capabilities now available in Microsoft Foundry<\/h1>\n

Structured outputs, Web search, Web fetch, MCP connector, and Tool search are now available for Claude models in Microsoft Foundry hosted on Azure, the building blocks that turn a model endpoint into a production agent platform.<\/strong><\/p>\n

\n

When Claude models became generally available in Microsoft Foundry in June 2026, the headline was new hosted on Azure access: frontier Claude models, Azure-native endpoints, Entra ID authentication, and Azure Marketplace billing. That solved the procurement and governance<\/em> problem. Teams could finally run Claude inside the same subscription, network perimeter, and cost-management surface as the rest of their Azure estate.<\/p>\n

But access to a model is not the same as a platform for agents. In the weeks since the generally available launch, we\u2019ve now added more capabilities to the Hosted on Azure options. The pattern we have seen across Foundry customers is the same: a team ships a strong Claude-powered feature, then spends the next quarter rebuilding the same four pieces of scaffolding.<\/p>\n

    \n
  1. A retry loop that re-prompts the model because it returned JSON with a trailing comma.<\/li>\n
  2. A bespoke search-and-scrape service, with its own crawler, cache, robots.txt handling, and citation plumbing.<\/li>\n
  3. A hand-rolled MCP client so the model can reach Jira, ServiceNow, Confluence, and three internal APIs.<\/li>\n
  4. A tool router, because once you wire up 300 tools the model starts picking the wrong one.<\/li>\n<\/ol>\n

    Every one of those is undifferentiated engineering. None of it is your product. This release moves all four into the platform and, critically, moves them onto deployments hosted on Azure, so you no longer choose between agentic capability and keeping prompts and completions within Azure.<\/p>\n

    This post walks through each capability: what it does, the API shape on Foundry, a realistic enterprise use case, and the constraints that will bite you in production. Code examples are given in Python and TypeScript using the Anthropic Foundry SDKs.<\/p>\n

    \n

    The part that changes the architecture: these now run hosted on Azure<\/h2>\n

    Claude models in Microsoft Foundry come in two hosting options, chosen when you create the deployment. Previously, the agentic feature set was available only on Hosted on Anthropic deployments, which forced trade-off: teams with a data-handling commitment that prompts and completions stay within Azure had to either give up that commitment or rebuild search, fetch, MCP, and tool routing client-side.<\/p>\n

    That trade-off is now resolved. Structured outputs, Web search, Web fetch, MCP connector, and Tool search are available on deployments hosted on Azure.<\/strong><\/p>\n\n\n\n\n\n\n\n\n\n
    <\/th>\nHosted on Azure<\/strong><\/th>\nHosted on Anthropic<\/strong><\/th>\n<\/tr>\n<\/thead>\n
    Where inference runs<\/td>\nAnthropic-operated service on Azure infrastructure<\/td>\nAnthropic-operated service on Anthropic infrastructure<\/td>\n<\/tr>\n
    Model availability<\/td>\nLatest Opus, Sonnet, and Haiku models<\/td>\nThe full Claude catalogue on Foundry<\/td>\n<\/tr>\n
    Deployment types<\/td>\nGlobal Standard, US Data Zone Standard<\/td>\nGlobal Standard<\/td>\n<\/tr>\n
    The five features in this post<\/td>\n\u2713<\/td>\n\u2713<\/td>\n<\/tr>\n
    Recommended for<\/td>\nMost workloads<\/td>\nAccess to models not yet hosted on Azure<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    For deployments hosted on Azure, prompts and completions remain within Azure; only usage metadata and content flagged by Anthropic’s safety systems egress to Anthropic. Anthropic acts as an independent processor for Microsoft, and customers using Claude through Foundry are subject to Anthropic’s data use terms.<\/p>\n

    The practical consequence for regulated industries is significant. A US Data Zone Standard deployment keeps inference within the United States, equivalent to setting inference_geo: \"us\"<\/code> on the Claude API and that deployment can now run a web-search-backed research agent, connect to your internal MCP servers, and return grammar-constrained JSON. Twelve months ago that combination required choosing between capability and residency posture. It no longer does.<\/p>\n

    See these capabilities in action on this upcoming webinar. [LINK: https:\/\/www.anthropic.com\/webinars\/claude-in-microsoft-foundry-tool-integrations-in-practice?utm_source=partner-msft&utm_medium=webinar&utm_campaign=msft-promotion]<\/p>\n

    \n

    1. Structured Outputs: the end of JSON.parse() roulette<\/h2>\n

    The problem<\/h3>\n

    Every team that has put an LLM in a data pipeline has written this code:<\/p>\n

    for attempt in range(3):\r\n    raw = call_model(prompt)\r\n    try:\r\n        data = json.loads(raw)\r\n        validate(data)\r\n        break\r\n    except (json.JSONDecodeError, ValidationError):\r\n        prompt += \"\\n\\nYour last response was invalid JSON. Try again.\"<\/code><\/pre>\n
    It works most of the time. “Most of the time” is a terrible property for a batch job that processes 400,000 documents overnight, because 0.3% failure is 1,200 rows in a dead-letter queue that somebody has to triage on Monday.<\/p>\n
    What it does<\/h3>\n
    Structured outputs constrain generation itself. The model’s decoding is restricted by a grammar compiled from your JSON Schema, so the output cannot<\/em> be malformed. Two complementary features, usable independently or together:<\/p>\n
      \n
    • JSON outputs<\/strong> (output_config.format<\/code>) \u2014 controls the shape of Claude’s response text.<\/li>\n
    • Strict tool use<\/strong> (strict: true<\/em> on a tool) \u2014 guarantees schema-valid tool inputs<\/em>.<\/li>\n<\/ul>\n
      The first governs what Claude says. The second governs how Claude calls your functions.<\/p>\n
      Use case: claims intake at a specialty insurer<\/h3>\n
      A commercial insurer receives first-notice-of-loss submissions as free-text email, broker PDFs, and adjuster voice-note transcripts. The downstream system is an Azure SQL table with a rigid schema and a Logic Apps workflow that routes by severity. Historically, extraction ran through a regex-and-heuristics pipeline that covered about 60% of formats and dumped the rest into a manual queue.<\/p>\n
      With structured outputs, the extraction contract is the schema:<\/p>\n
      from pydantic import BaseModel\r\nfrom typing import Literal\r\nfrom anthropic import AnthropicFoundry\r\n\r\nclass ClaimIntake(BaseModel):\r\n    policy_number: str\r\n    claimant_name: str\r\n    loss_date: str                       # ISO 8601\r\n    loss_type: Literal[\r\n        \"property_damage\", \"bodily_injury\", \"business_interruption\",\r\n        \"auto_liability\", \"other\",\r\n    ]\r\n    estimated_severity_usd: float\r\n    third_party_involved: bool\r\n    injuries_reported: bool\r\n    summary: str\r\n    escalate_to_adjuster: bool\r\n\r\nclient = AnthropicFoundry(resource=\"contoso-ai\")\r\n\r\nresponse = client.messages.parse(\r\n    model=\"claude-opus-5\",\r\n    max_tokens=2048,\r\n    system=(\r\n        \"You are a claims intake analyst. Extract only what is stated or \"\r\n        \"clearly implied in the submission. If severity is not stated, \"\r\n        \"estimate conservatively from comparable losses.\"\r\n    ),\r\n    messages=[{\"role\": \"user\", \"content\": submission_text}],\r\n    output_format=ClaimIntake,\r\n)\r\n\r\nclaim = response.parsed_output      # a ClaimIntake instance, already validated\r\nif claim.escalate_to_adjuster:\r\n    enqueue_for_adjuster(claim)<\/code><\/pre>\n
      The TypeScript equivalent, using Zod:<\/p>\n
      import { z } from \"zod\";\r\nimport AnthropicFoundry from \"@anthropic-ai\/foundry-sdk\";\r\nimport { zodOutputFormat } from \"@anthropic-ai\/sdk\/helpers\/zod\";\r\n\r\nconst ClaimIntake = z.object({\r\n  policy_number: z.string(),\r\n  claimant_name: z.string(),\r\n  loss_date: z.string(),\r\n  loss_type: z.enum([\r\n    \"property_damage\", \"bodily_injury\", \"business_interruption\",\r\n    \"auto_liability\", \"other\",\r\n  ]),\r\n  estimated_severity_usd: z.number(),\r\n  third_party_involved: z.boolean(),\r\n  injuries_reported: z.boolean(),\r\n  summary: z.string(),\r\n  escalate_to_adjuster: z.boolean(),\r\n});\r\n\r\nconst client = new AnthropicFoundry({ resource: \"contoso-ai\" });\r\n\r\nconst response = await client.messages.parse({\r\n  model: \"claude-opus-5\",\r\n  max_tokens: 2048,\r\n  messages: [{ role: \"user\", content: submissionText }],\r\n  output_config: { format: zodOutputFormat(ClaimIntake) },\r\n});<\/code><\/pre>\n
      \n
      2. Web Search: current information, with citations, without a crawler<\/h2>\n
      What it does<\/h3>\n
      Add one tool to the request and Claude decides when to search, runs as many searches as it needs within your limit, and returns an answer with citations attached to the specific spans it drew from. You do not run a crawler, manage an index, or write a re-ranker.<\/p>\n
      Version available is web_search_20250305<\/code> \u2014 basic search<\/p>\n
      response = client.messages.create(\r\n    model=\"claude-opus-5\",\r\n    max_tokens=4096,\r\n    messages=[{\"role\": \"user\", \"content\": \"What's the current state of the EU AI Act's GPAI obligations?\"}],\r\n    tools=[{\"type\": \"web_search_20250305\", \"name\": \"web_search\", \"max_uses\": 5}],\r\n)<\/code><\/pre>\n
      Dynamic filtering: the token economics change<\/h3>\n
      With basic search, every result loads into the context window in full \u2014 including the boilerplate, the nav chrome, and the four paragraphs that had nothing to do with your question. On a research-heavy request that is tens of thousands of wasted input tokens per turn.<\/p>\n
      With web_search_20260209<\/code> and later, Claude instead writes and runs code that filters results before<\/em> they reach context, keeping only relevant content. Mechanically, search runs from inside the code execution tool: on these versions allowed_callers<\/code> defaults to [\"code_execution_20260120\"]<\/code>, and Foundry provisions the code execution the request needs automatically. You do not add code execution to your tools<\/em> array, and there is no extra charge for those calls beyond standard token costs.<\/p>\n
      To force direct calls without dynamic filtering, set allowed_callers: [\"direct\"]<\/code>. Models that do not support programmatic tool calling require this; without it you get a 400 telling you so.<\/p>\n
      Use case: regulatory change monitoring at a global bank<\/h3>\n
      A Tier 1 bank’s regulatory affairs team tracks rule changes across a dozen jurisdictions. The old process was a team of analysts with RSS feeds and a shared inbox; the median time from publication to an internal impact note was six days.<\/p>\n
      The rebuild is a nightly Azure Container Apps job. The critical design choice is not the prompt \u2014 it is allowed_domains<\/code>. Regulatory monitoring is exactly the case where you cannot afford a secondary source paraphrasing a rule incorrectly:<\/p>\n
      REGULATOR_DOMAINS = [\r\n    \"eba.europa.eu\", \"esma.europa.eu\", \"eur-lex.europa.eu\",\r\n    \"federalreserve.gov\", \"sec.gov\", \"occ.gov\",\r\n    \"bankofengland.co.uk\", \"fca.org.uk\",\r\n    \"mas.gov.sg\", \"apra.gov.au\",\r\n]\r\n\r\nresponse = client.messages.create(\r\n    model=\"claude-opus-5\",\r\n    max_tokens=8192,\r\n    system=(\r\n        \"You monitor prudential and conduct regulation for a global bank. \"\r\n        \"Report only changes published in the last 7 days. For each change, \"\r\n        \"state the regulator, the instrument, the effective date, and the \"\r\n        \"business lines affected. Do not speculate beyond the source text.\"\r\n    ),\r\n    messages=[{\"role\": \"user\", \"content\": \"What changed this week in capital and liquidity rules?\"}],\r\n    tools=[{\r\n        \"type\": \"web_search_20260318\",\r\n        \"name\": \"web_search\",\r\n        \"max_uses\": 12,\r\n        \"allowed_domains\": REGULATOR_DOMAINS,\r\n        \"user_location\": {\r\n            \"type\": \"approximate\",\r\n            \"city\": \"London\",\r\n            \"region\": \"England\",\r\n            \"country\": \"GB\",\r\n            \"timezone\": \"Europe\/London\",\r\n        },\r\n    }],\r\n)<\/code><\/pre>\n
      const response = await client.messages.create({\r\n  model: \"claude-opus-5\",\r\n  max_tokens: 8192,\r\n  system: \"You monitor prudential and conduct regulation for a global bank. ...\",\r\n  messages: [{ role: \"user\", content: \"What changed this week in capital and liquidity rules?\" }],\r\n  tools: [{\r\n    type: \"web_search_20260318\",\r\n    name: \"web_search\",\r\n    max_uses: 12,\r\n    allowed_domains: REGULATOR_DOMAINS,\r\n    user_location: {\r\n      type: \"approximate\", city: \"London\", region: \"England\",\r\n      country: \"GB\", timezone: \"Europe\/London\",\r\n    },\r\n  }],\r\n});<\/code><\/pre>\n
      allowed_domains<\/code> and blocked_domains<\/code> are mutually exclusive \u2014 send both and you get a 400. Entries are bare domains with an optional path (example.com<\/code>, example.com\/blog<\/code>), no scheme.<\/p>\n
      \n
      3. Web Fetch: read the document you have given<\/h2>\n
      What it does<\/h3>\n
      Where web search discovers, web fetch reads. Point it at a URL and it returns full page text or, for PDFs, base64 document content that is processed exactly like a directly attached PDF.<\/p>\n
      Versions, again meaningful:<\/p>\n
        \n
      • web_fetch_20250910<\/code> \u2014 basic fetch<\/li>\n<\/ul>\n
        Use case: third-party risk assessment at a healthcare system<\/p>\n
        A hospital network onboards roughly 40 SaaS vendors a quarter. Each triggers a security review: read the vendor’s trust centre, their subprocessor list, their most recent SOC 2 scope summary, their DPA, and their status page history. An analyst spends two to three hours per vendor reading PDFs.<\/p>\n
        VENDOR_DOCS = [\r\n    \"https:\/\/vendor.example.com\/trust\",\r\n    \"https:\/\/vendor.example.com\/legal\/subprocessors\",\r\n    \"https:\/\/vendor.example.com\/security\/soc2-scope.pdf\",\r\n    \"https:\/\/vendor.example.com\/legal\/dpa.pdf\",\r\n]\r\n\r\nresponse = client.messages.create(\r\n    model=\"claude-opus-5\",\r\n    max_tokens=8192,\r\n    system=(\r\n        \"You are a third-party risk analyst for a healthcare system subject to \"\r\n        \"HIPAA. Assess each vendor against: data residency, subprocessor \"\r\n        \"disclosure, breach notification SLA, encryption at rest and in transit, \"\r\n        \"BAA availability, and SOC 2 scope coverage. Cite the source for every \"\r\n        \"finding. If a control is not addressed in the documents, say so \"\r\n        \"explicitly rather than inferring.\"\r\n    ),\r\n    messages=[{\r\n        \"role\": \"user\",\r\n        \"content\": \"Assess this vendor:\\n\" + \"\\n\".join(VENDOR_DOCS),\r\n    }],\r\n    tools=[{\r\n        \"type\": \"web_fetch_20260318\",\r\n        \"name\": \"web_fetch\",\r\n        \"max_uses\": 8,\r\n        \"allowed_domains\": [\"vendor.example.com\"],\r\n        \"citations\": {\"enabled\": True},\r\n        \"max_content_tokens\": 60000,\r\n    }],\r\n)<\/code><\/pre>\n
        const response = await client.messages.create({\r\n  model: \"claude-opus-5\",\r\n  max_tokens: 8192,\r\n  system: \"You are a third-party risk analyst for a healthcare system ...\",\r\n  messages: [{ role: \"user\", content: `Assess this vendor:\\n${VENDOR_DOCS.join(\"\\n\")}` }],\r\n  tools: [{\r\n    type: \"web_fetch_20260318\",\r\n    name: \"web_fetch\",\r\n    max_uses: 8,\r\n    allowed_domains: [\"vendor.example.com\"],\r\n    citations: { enabled: true },\r\n    max_content_tokens: 60000,\r\n  }],\r\n});<\/code><\/pre>\n
        Three parameters are doing real work here. citations: { enabled: true }<\/code> \u2014 unlike web search, citations are off by default<\/strong> for fetch, and for a risk assessment that is exactly backwards, so turn them on. allowed_domains<\/code> prevents the model from wandering off to a marketing blog. max_content_tokens<\/code> truncates oversized text content before it enters context \u2014 with one important caveat covered below.<\/p>\n
        Budget accordingly: an average 10 kB web page is roughly 2,500 tokens, a 100 kB documentation page roughly 25,000, and a 500 kB research-paper PDF roughly 125,000. Four documents of that size will consume a serious fraction of your context window in a single turn.<\/p>\n
        Combining search and fetch<\/h3>\n
        The highest-leverage pattern in this release is enabling both tools together. When a user names a specific document without giving a URL \u2014 “read the README from the anthropics\/anthropic-sdk-python repo,” “pull up the vendor’s latest DPA” \u2014 Claude uses search to locate it, then fetch to read it in full:<\/p>\n
        response = client.messages.create(\r\n    model=\"claude-opus-5\",\r\n    max_tokens=8192,\r\n    messages=[{\r\n        \"role\": \"user\",\r\n        \"content\": (\r\n            \"Find the three most recent independent analyses of hospital \"\r\n            \"ransomware incidents in 2026 and give me a detailed comparison \"\r\n            \"of the attack vectors described.\"\r\n        ),\r\n    }],\r\n    tools=[\r\n        {\"type\": \"web_search_20260318\", \"name\": \"web_search\", \"max_uses\": 5},\r\n        {\r\n            \"type\": \"web_fetch_20260318\",\r\n            \"name\": \"web_fetch\",\r\n            \"max_uses\": 5,\r\n            \"citations\": {\"enabled\": True},\r\n            \"max_content_tokens\": 50000,\r\n        },\r\n    ],\r\n)<\/code><\/pre>\n
        Claude searches, picks the most promising results, fetches them in full, and analyses with citations. Search gives you breadth cheaply; fetch gives you depth on the handful of sources that matter.<\/p>\n
        \n
        4. MCP Connector: your systems of record, without an MCP client<\/h2>\n
        What it does<\/h3>\n
        Model Context Protocol has become the de facto standard for exposing enterprise systems to models. MCP connector lets you point the Messages API at remote MCP servers directly \u2014 no client implementation, no session management, no tool-schema translation layer. The service performs the connection and the tool calls on your behalf.<\/p>\n
        The API has two halves: mcp_servers<\/code> defines connections, and an mcp_toolset<\/code> entry in tools<\/em> defines which of that server’s tools are enabled and how.<\/p>\n
        response = client.beta.messages.create(\r\n    model=\"claude-opus-5\",\r\n    max_tokens=4096,\r\n    messages=[{\"role\": \"user\", \"content\": \"What's blocking the payments release?\"}],\r\n    mcp_servers=[{\r\n        \"type\": \"url\",\r\n        \"url\": \"https:\/\/mcp.contoso.com\/jira\/sse\",\r\n        \"name\": \"jira\",\r\n        \"authorization_token\": jira_oauth_token,\r\n    }],\r\n    tools=[{\"type\": \"mcp_toolset\", \"mcp_server_name\": \"jira\"}],\r\n    betas=[\"mcp-client-2025-11-20\"],\r\n)<\/code><\/pre>\n
        Note client.beta.messages.create<\/code> and the betas<\/em> header \u2014 the MCP connector is in beta on Foundry, as it is on the Claude API.<\/p>\n
        Use case: an internal IT support agent<\/h3>\n
        A manufacturer’s IT service desk handles 12,000 tickets a month. Roughly 40% are resolvable through a fixed sequence: look up the user in the directory, check their device compliance state, search the knowledge base, and either apply a known fix or escalate with context attached. The team already runs MCP servers for ServiceNow, Intune, and their Confluence knowledge base \u2014 built for their internal Claude Code deployment.<\/p>\n
        MCP connector lets the same servers back a customer-facing agent with no new integration work. The interesting part is the tool governance:<\/p>\n
        response = client.beta.messages.create(\r\n    model=\"claude-opus-5\",\r\n    max_tokens=4096,\r\n    system=(\r\n        \"You are an IT support agent. Diagnose using read-only tools first. \"\r\n        \"Never make a change without stating what you are about to do.\"\r\n    ),\r\n    messages=[{\"role\": \"user\", \"content\": user_ticket}],\r\n    mcp_servers=[\r\n        {\"type\": \"url\", \"url\": \"https:\/\/mcp.contoso.com\/servicenow\/sse\",\r\n         \"name\": \"servicenow\", \"authorization_token\": snow_token},\r\n        {\"type\": \"url\", \"url\": \"https:\/\/mcp.contoso.com\/intune\/sse\",\r\n         \"name\": \"intune\", \"authorization_token\": intune_token},\r\n        {\"type\": \"url\", \"url\": \"https:\/\/mcp.contoso.com\/confluence\/sse\",\r\n         \"name\": \"kb\", \"authorization_token\": kb_token},\r\n    ],\r\n    tools=[\r\n        # ServiceNow: everything except the destructive operations\r\n        {\r\n            \"type\": \"mcp_toolset\",\r\n            \"mcp_server_name\": \"servicenow\",\r\n            \"configs\": {\r\n                \"delete_incident\": {\"enabled\": False},\r\n                \"bulk_close_incidents\": {\"enabled\": False},\r\n                \"modify_sla\": {\"enabled\": False},\r\n            },\r\n        },\r\n        # Intune: strict allowlist, read-only\r\n        {\r\n            \"type\": \"mcp_toolset\",\r\n            \"mcp_server_name\": \"intune\",\r\n            \"default_config\": {\"enabled\": False},\r\n            \"configs\": {\r\n                \"get_device_compliance\": {\"enabled\": True},\r\n                \"list_user_devices\": {\"enabled\": True},\r\n            },\r\n        },\r\n        # Knowledge base: large, rarely all needed at once\r\n        {\r\n            \"type\": \"mcp_toolset\",\r\n            \"mcp_server_name\": \"kb\",\r\n            \"default_config\": {\"defer_loading\": True},\r\n        },\r\n    ],\r\n    betas=[\"mcp-client-2025-11-20\"],\r\n)<\/code><\/pre>\n
        const response = await client.beta.messages.create({\r\n  model: \"claude-opus-5\",\r\n  max_tokens: 4096,\r\n  system: \"You are an IT support agent. Diagnose using read-only tools first. ...\",\r\n  messages: [{ role: \"user\", content: userTicket }],\r\n  mcp_servers: [\r\n    { type: \"url\", url: \"https:\/\/mcp.contoso.com\/intune\/sse\", name: \"intune\",\r\n      authorization_token: intuneToken },\r\n  ],\r\n  tools: [{\r\n    type: \"mcp_toolset\",\r\n    mcp_server_name: \"intune\",\r\n    default_config: { enabled: false },\r\n    configs: {\r\n      get_device_compliance: { enabled: true },\r\n      list_user_devices: { enabled: true },\r\n    },\r\n  }],\r\n  betas: [\"mcp-client-2025-11-20\"],\r\n});<\/code><\/pre>\n
        Three patterns are worth naming because they map directly onto how enterprises actually govern agents:<\/p>\n