Microsoft Foundry SDK

Purpose and Scope

The Microsoft Foundry SDK package is the Azure AI Foundry-specific entry point for using Claude from TypeScript and JavaScript applications. It is published as @anthropic-ai/foundry-sdk and wraps the same generated Claude client family used by the main @anthropic-ai/sdk, while changing configuration, credential handling, and endpoint construction for Foundry resources. Use this package when your application reaches Claude through Microsoft Foundry rather than the direct api.anthropic.com Claude API endpoint.

Sources: packages/foundry-sdk/README.md, packages/foundry-sdk/package.json, packages/foundry-sdk/src/client.ts

Microsoft Foundry access is an Azure-native deployment path for Claude. The official product documentation frames it as access through Foundry resources, Azure Marketplace billing, and either Azure-hosted or Anthropic-hosted model deployments. In SDK terms, that means the application still calls familiar Claude resources such as messages.create, but the client must target a Foundry resource URL and authenticate with either a Foundry API key or a Microsoft Entra token provider. This page focuses on those package-level behaviors and the public constructor surface exposed by this repository.

Relevant Source Files

• packages/foundry-sdk/README.md - package README with installation, API-key usage, Azure AD token provider usage, and Foundry documentation link.
• packages/foundry-sdk/package.json - npm package metadata, build scripts, dependency on the main SDK package, and CommonJS/ESM export map.
• packages/foundry-sdk/src/index.ts - public package entrypoint exporting AnthropicFoundry, the default export, and FoundryClientOptions.
• packages/foundry-sdk/src/client.ts - Foundry client implementation, constructor options, credential validation, resource/baseURL handling, and resource overrides.
• packages/foundry-sdk/tests/client.test.ts - behavior tests for initialization, environment fallback, validation errors, Azure AD token provider behavior, and generated base URLs.

Installation and Package Shape

Install the package from npm when you are building against Claude in Microsoft Foundry:

npm install @anthropic-ai/foundry-sdk

The package metadata identifies @anthropic-ai/foundry-sdk as the official TypeScript library for the Anthropic Foundry API, with public publishing enabled and generated distribution entrypoints under dist. Its dependency on @anthropic-ai/sdk is declared as a local file dependency in this monorepo, which matches the implementation: the Foundry client subclasses the shared Anthropic client and reuses the generated resource types rather than duplicating the entire SDK. The export map supports the root package entrypoint plus subpath imports for built JavaScript and declaration files.

Sources: packages/foundry-sdk/package.json, packages/foundry-sdk/src/index.ts, packages/foundry-sdk/src/client.ts

The public entrypoint is deliberately small. packages/foundry-sdk/src/index.ts re-exports everything from ./client, exports AnthropicFoundry as the default export, and separately exports the FoundryClientOptions type. In user code, this supports both named and default import styles, but the README demonstrates the named import. Because the class extends the shared Anthropic client, familiar request options such as timeouts, retry counts, custom fetch, default headers, and default query parameters remain part of the constructor contract through ClientOptions.

Core Primitives

The central primitive is AnthropicFoundry, an API client for the Anthropic Foundry API. It has a messages resource for creating Claude messages and a beta resource for beta APIs that are available through the Foundry wrapper. The implementation explicitly overrides models to undefined, and its comments note that the Foundry client uses a different Messages type that omits batches. Treat this as a provider-specific SDK: it is intentionally not a byte-for-byte replacement for the direct Claude SDK surface.

Sources: packages/foundry-sdk/src/client.ts, packages/foundry-sdk/tests/client.test.ts

The second primitive is the target endpoint. You can provide either resource or baseURL, but not both. Tests show that a resource such as example-resource becomes https://example-resource.services.ai.azure.com/anthropic/, while an explicit baseURL is preserved as passed. This distinction matters operationally: resource is the convenient Azure Foundry resource name path, and baseURL is the escape hatch for callers that already have the full Foundry-compatible Anthropic endpoint.

The third primitive is the credential. The client accepts exactly one of apiKey or azureADTokenProvider. An API key is a static secret, defaulting from ANTHROPIC_FOUNDRY_API_KEY. The Azure AD token provider is an async function that returns a Microsoft Entra access token and is invoked through the client’s authentication path on requests. Tests verify that the token provider is stored as the effective API-key provider internally, which lets the shared Anthropic base client continue to attach authorization consistently.

Authentication Patterns

For API-key authentication, pass apiKey and a Foundry resource, or rely on environment variables. The README uses ANTHROPIC_FOUNDRY_API_KEY and a resource value, then calls client.messages.create with the normal Claude Messages request shape: model, max_tokens, and a messages array containing a user message. The constructor also reads ANTHROPIC_FOUNDRY_RESOURCE and ANTHROPIC_FOUNDRY_BASE_URL, so deployment environments can configure the client without hard-coding secrets or endpoint names in application code.

Sources: packages/foundry-sdk/README.md, packages/foundry-sdk/src/client.ts, packages/foundry-sdk/tests/client.test.ts

import { AnthropicFoundry } from '@anthropic-ai/foundry-sdk';
 
const client = new AnthropicFoundry({
  apiKey: process.env.ANTHROPIC_FOUNDRY_API_KEY,
  resource: 'example-resource',
});
 
const message = await client.messages.create({
  model: 'claude-3-5-sonnet-20241022',
  max_tokens: 1024,
  messages: [{ role: 'user', content: 'Hello, Claude!' }],
});

For Microsoft Entra authentication, pass azureADTokenProvider instead of apiKey. The README demonstrates DefaultAzureCredential and getBearerTokenProvider from @azure/identity with the https://ai.azure.com/.default scope. This pattern aligns with Azure-native workload identity practices: the application asks Azure identity libraries for a token and the SDK uses that provider for requests. The constructor marks dangerouslyAllowBrowser true when a token provider is supplied, but the security model still depends on how and where the provider obtains tokens.

import { AnthropicFoundry } from '@anthropic-ai/foundry-sdk';
import { getBearerTokenProvider, DefaultAzureCredential } from '@azure/identity';
 
const credential = new DefaultAzureCredential();
const azureADTokenProvider = getBearerTokenProvider(
  credential,
  'https://ai.azure.com/.default',
);
 
const client = new AnthropicFoundry({
  azureADTokenProvider,
  resource: 'example-resource',
});

Constructor Reference

Validation is strict and happens during construction. The client throws if neither credential path is available, if both credential paths are supplied, if neither resource nor baseURL is available, or if both endpoint inputs are supplied. These errors are covered by tests, so callers can depend on configuration mistakes failing before the first network request. In production applications, this makes startup validation straightforward: instantiate the client during service initialization and fail fast when the Azure resource or credential environment variables are missing.

Sources: packages/foundry-sdk/src/client.ts, packages/foundry-sdk/tests/client.test.ts

Request Flow and Resource Differences

Once constructed, the Foundry client is used like the standard Claude Messages client for ordinary generation calls. The README examples call client.messages.create with model, max_tokens, and messages, then read message.content. That continuity is intentional: the provider package should change authentication and endpoint targeting, not force application code to learn a separate message schema for common requests. The README also notes deployment-oriented URL behavior for configured model deployments, where the SDK can use deployment-specific message paths.

Sources: packages/foundry-sdk/README.md, packages/foundry-sdk/src/client.ts

The provider differences are still important. The implementation overrides models to undefined, so applications should not use this package for model-listing workflows that they may use against the direct Claude API. The custom messages and beta resources are typed differently from the base SDK resources, with comments indicating omitted batch support. If you are porting an existing direct-API integration, audit calls to client.models, message batches, and any beta methods before switching the import to @anthropic-ai/foundry-sdk.

Testing Signals and Next Steps

The Foundry test suite documents the intended initialization contract. It verifies API-key construction, explicit baseURL construction, Azure AD token provider initialization, environment-variable fallback, missing credential errors, missing endpoint errors, mutual exclusion for credentials, and mutual exclusion for resource plus baseURL. These tests are useful examples for service owners writing their own configuration checks, because they show exactly which constructor inputs are expected to be valid and which combinations should be rejected.

Sources: packages/foundry-sdk/tests/client.test.ts

Next, choose the credential pattern that matches your Azure environment. Use apiKey for the simplest setup or local proof of concept. Use azureADTokenProvider with Azure identity libraries when you want Microsoft Entra-based authentication and secretless workload patterns. After the client is constructed, start with messages.create, then review provider-specific gaps before migrating broader direct Claude SDK usage. Related pages: messages-api, anthropic-client-reference, google-vertex-sdk, and amazon-bedrock-sdk.