Changelog

You can now deploy your MCP servers as Cloudflare Workers, making them accessible to web-based AI interfaces like claude.ai.

When you enable generate_cloudflare_worker: true in your MCP server configuration, Stainless generates a complete Cloudflare Worker template alongside your MCP server. This worker implements OAuth authentication and serves your APItools remotely, eliminating the need for local installations or API key management in client configs.

The generated worker includes:

• OAuth consent screen with customizable form fields (text, password, select dropdowns)
• Support for both SSE and Streaming HTTP protocols
• One-click deployment via GitHub integration

This opens up MCP servers to a broader audience beyond desktop developers, enabling seamless integration with web-based AI tools while maintaining security through proper OAuth flows.

Take a look at our documentation to learn more about deployment options and customization.

The Java/Kotlin SDKs now support configuring a query param as the discriminator for a method that supports both streaming and non-streaming.

When configured this way the HTTP method will result int two generated SDK methods. For example, an HTTP method called create will result in the following two SDK methods:

• create → doesn’t send the query param discriminator
• createStreaming → sends the query param discriminator set to true

To configure SSE streaming for your API contact sales.

In the Studio editor, pressing Cmd + P opens a Command Palette with relevant commands for editing your OpenAPI spec and Stainless config. Useful commands include:

• Format Document
• Go to Symbol
• Decrease / Increase Editor Font Size

You can now add SDK code examples to your Mintlify docs with a one-line setup.

Simply paste the OpenAPI URL into your docs.json file. See docs for more information.

Large APIs with many endpoints can be difficult for LLMs to work with effectively when all endpoints are exposed as individual tools. The generated MCP server now provides a "dynamic tools" mode to address this issue.

When you specify --tools=dynamic to the MCP server, instead of exposing one tool per API endpoint, it exposes just three powerful meta-tools:

1. list_api_endpoints - Discovers available endpoints, with optional filtering by search query
2. get_api_endpoint_schema - Gets detailed schema information for a specific endpoint
3. invoke_api_endpoint - Executes any endpoint with the appropriate parameters

This approach allows the LLM to dynamically discover, learn about, and invoke endpoints as needed, without requiring the entire API schema to be loaded into its context window at once. The LLM will use these tools together to search for, look up, and call endpoints on demand.

‍

You can now pass the last path parameter positionally in Java/Kotlin.

We released a “V2” of the Go SDK generator, with a completely redesigned JSON model, more ergonomic union types, and a cleaner DX across the board.

• No need for pkg.F(…) constructors
  • petstore.Pet{ Name: petstore.F("Joey") } → petstore.Pet{ Name: "Joey" }
• Pointer-free JSON model using omitzero: Ergonomic optional and nullable parameters using the new standard library omitzero JSON semantics.
• Improved discoverability of union variants: Unions now use a struct-based design with json:",omitzero,inline" semantics instead of interfaces for better discoverability
• Ergonomic access to shared fields in union types: No need to switch on variants when you know the property you want
• Automatic helper generation for complex union variants:

  
// Old: Manually constructed variants

openai.ChatCompletionNewParams{
   	Messages: openai.F([]openai.ChatCompletionMessageParam{
   		openai.ChatCompletionUserMessageParam{
     		Content: openai.F([]openai.ChatCompletionMessageContent{
       			openai.UnionString("Write me a poem")
       		}),
		Type: openai.F[ChatCompletionMessageParamRole]("user"),
    }),
    Model: openai.ChatModelO3Mini,
}

// New: Automatically generated helpers

openai.ChatCompletionNewParams{
	Messages: []openai.ChatCompletionMessageParamUnion{
		openai.UserMessage("Write me a poem"),
	},
	Model: openai.ChatModelO3Mini,
}
  
  

  
// New: Automatically generated helpers

openai.ChatCompletionNewParams{
		Messages: []openai.ChatCompletionMessageParamUnion{
			openai.UserMessage("How can I list all files in a directory using Python?"),
		},
		Model: openai.ChatModelO3Mini,
	},
  
  

• Supports unmarshalling into parameters: Request parameter types, including unions, can now be unmarshalled from external input.

We’re continuing to expand Go support. Send us a note if there is anything you’d like to see in upcoming updates. support@stainless.com

Our Model Context Protocol (MCP) server now adapts to different client capabilities when serving tools generated by Stainless.

MCP clients like Claude Desktop, Cursor, or OpenAI Agents each handle the JSON schemas provided by MCP servers differently. For example, Cursor has a strict 60-character tool name length, and Claude Code does not support unions of objects at the top level of a tool.

To mitigate this, users can provide a --client argument to our MCP server to specify which client they are working with, and our server will automatically transform the generated JSON Schemas to serve clients a format that is compatible.

For example: npx my-api-mcp --client=claude-code

You can read more about the transformations in our recent blog post.

The Ruby SDK generator is now generally available, with modern type system support and a minimal-dependency design that feels right at home in the Ruby ecosystem.

• ‍Sorbet: Each SDK includes comprehensive RBI annotations, including enums and aliases, without a dependency on sorbet-runtime.‍
• RBS: Each SDK also includes Ruby 3’s RBS type annotations, compatible with the steep typechecker.‍
• YARD: Full YARD docs support for methods and types, with navigable links between related objects, published to Gemdocs automatically.‍
• Tooling support: Great auto-completion for ecosystem tool chains, including generics for pagination & streaming for all supported language services.‍
• File uploads & downloads: Full lazy upload and download support with conveniences like Pathname support.‍
• Type conversions: Automatic conversions to Time, Integer and so on as appropriate.‍
• Pattern matching: All data containers support Ruby 3 pattern matching.‍
• Minimal dependencies: The SDKs use stdlib net/http for requests, relying only on connection_pool.‍
• Introspection: Pretty printing is supported for all internal types, for both classes and instances.‍
• Streaming: Support for SSE & JSON-L streams as ruby Enumerators, allowing for convenient .map, .filter, and so on, with automatic closing during GC.‍
• Advanced use cases: Raw and undocumented request support.

We plan to add support for middleware soon, along with other conveniences; if there’s more you’d like to see, please share: hello@stainless.com.

We have shipped a “v2” of our Node / TypeScript SDK generator, focused around dropping support for EOL versions of Node and removing node-fetch in favor of the now-stable built-in fetch.

Upgrading to the new SDK requires a major version bump for any 1.0 or later SDK, though typically most developers will not be required to change any code.

The new SDKs are lighter, more consistent, and have zero dependencies out of the box. We also took the opportunity to clean up a variety of details along the way.

• Native fetch support: node-fetch has been removed in favor of the native web Fetch API, as we have dropped support for Node 16 which did not include it as a stable builtin.
• Zero dependencies: All runtime dependencies have been removed!
• Clearer path parameters: Methods with multiple path parameters now use named arguments instead of positional ones.
• Automatic path parameter encoding: Path parameters are now automatically URI-encoded. If you were manually calling encodeURIComponent(), you should remove it.
• fetchOptions replaces httpAgent: The httpAgent option is removed. The new fetchOptions property can be used for things like proxy configuration, taking advantage of platform APIs.
• Consistent method naming: All delete operations now consistently use .delete() instead of .del().
• Simplified pagination: Pagination methods are simpler and more consistent. nextPageRequestOptions() replaces nextPageParams() and nextPageInfo().
• Lighter type system: Pagination classes are now simple type aliases instead of runtime classes.
• Streamlined file uploads: The deprecated and platform-specific fileFromPath helper has been removed. Instead, users can use fs.createReadStream or Bun.file directly.

Our Terraform Provider generator is now generally available.

If any of your users would like to configure resources in your API with Infrastructure as Code (IaC) using Terraform, they can now do so.

Our Terraform providers generate Hashicorp docs, handle complex datatypes, and support custom acceptance tests and state migrations to ensure robust deployments.

Simply select Terraform from the languages list in the SDK Studio to get started:

1. The Terraform Provider uses the Go SDK, so it will be enabled as well, if it isn’t already.
2. Enable some resources and address any diagnostics.‍
3. Try the provider locally.

Users can now install a package of any typescript build via npm install https://pkg.stainless.com/s/{repo_name}/{git_sha}.

The SDK Studio supports Ruby in the SDK preview pane.

Sorbet type definitions are stable with improved autocomplete for models.

Stainless Ruby SDKs are among the first to support type annotations without relying on sorbet-runtime, giving you static analysis without the extra overhead.

It’s also the first to offer Sorbet, RBS, and YARD docs with full generics.

You can now upload OpenAPI specs to Stainless directly from GitLab CI/CD pipelines.

Apply all suggested fixes from the diagnostics panel with one-click.

Stainless can now generate an MCP server for your API. The feature is currently experimental and is free to all users.

Get the full details in the launch blog.

The SDK Studio now supports Java and Kotlin in the SDK preview pane.

Configure JSONL endpoints in the Stainless config just like server-sent events (SSE).

The SDK Studio features an improved editor. This provides a more consistent coding experience and comes with improved autocomplete and cmd+click navigation.

You can now preview Ruby docs in Stainless Studio.

Users with code snippets enabled in their Stainless config can toggle a feature in the Studio UI to make their documented OpenAPI spec downloadable via a public URL.

For APIs where the base URL includes dynamic segments like a region subdomain (https://{region}.acme.com), you can map client options to them with the server_variable property in your Stainless config.

This allows your SDK users to set region directly without constructing custom baseURLs.

  
// now
const client = new Acme({ region: 'us-east-2' })
// before
const client = new Acme({ baseURL: 'https://us-east-2.amazonaws.com' })
  
  

  
# Stainless config
client_settings:
	opts:
		region:
			type: string
			env: ACME_REGION
			nullable: false
			server_variable: region
  
  

Users can now set global default values for path and query parameters via client options in the Go SDK.

You can now generate a Ruby SDK for your API using Stainless. Once your project is configured, follow this guide to get started.

See it in action here: Modern Treasury Ruby SDK.

For any feedback or feature requests, ping hao@.

Java and Kotlin SDKs come with hosted API docs—Javadocs and KDocs are published to javadoc.io and linked from the README.

The autoguesser is built-in tooling that helps turn your OpenAPI spec into the Stainless Config.

“V2” of our autoguesser comes with:

• Improved model guessing
• Smarter default config for features like pagination and OAuth
• Fewer diagnostics out of the box, providing a smoother setup experience
• Better handling of large OpenAPI specs where not all endpoints can be guessed at once

The Java and Kotlin SDK generators are now generally available, with improved support for complex OpenAPI specs and several new features.

• Convenient builders for complex objects: The SDKs now include helper methods to make building complex objects easier, such as .addCard(Card) alongside .cards(List<Card>) or .addUserMessage(String) for a discriminated union like {role: 'user', message: string}.
• Automatic cleanup for unreachable objects: The HttpClient and other resources are now closed automatically when no longer in use, even if the user forgets to call .close() (available in Java 9+).
• File uploads: Multipart form data is fully supported, even with nested file fields. Builders like FileCreateParams.builder().file(...) accept byte[], InputStream, or Path, and stream data directly to the API, without buffering in-memory whenever possible.
• Binary responses: Methods like client.files().retrieve(...) return an HttpResponse with a .body() stream. This is ideal for handling binary data without loading it all into memory.
• Raw response access: Easily access headers and more for any method call; for example, client.cards().withRawResponse().create(...) returns an HttpResponseFor<Card> with .headers(), .parse(), etc.
• SSE and JSONL streaming: Endpoints with streaming responses are now supported (e.g., client.chat().completions().createStreaming()).
• Jackson compatibility: The SDKs work with Jackson versions as old as 2.13.4, minimizing the chance of version conflicts in downstream applications.

We have a slew of additional improvements to our Java SDKs planned; please reach out to hello@stainless.com with anything you’d be most excited to see.

Stainless docs now have an “Integrations” section with guides on integrating with other platforms. Check out the first integration guide with bump.sh.

Stainless now outputs Java/Kotlin code snippets, which will be read by API reference documentation providers and displayed in your documentation.

Here is an example (binary response handling) of the code snippets:

  
package com.example.api.example;

import com.example.api.client.TestOrgClient;
import com.example.api.client.okhttp.TestOrgOkHttpClient;
import com.example.api.core.http.HttpResponse;
import com.example.api.models.FileContentParams;

public final class Main {
    private Main() {}

    public static void main(String[] args) {
      // Configures using the `EXAMPLE_API_KEY` environment variable
      TestOrgClient client = TestOrgOkHttpClient.fromEnv();

      FileContentParams params = FileContentParams.builder()
          .fileId("file_id")
          .build();
      HttpResponse response = client.files().content(params);
    }
}
  
  

The SDK Studio is now served from app.stainless.com, with the homepage updated to stainless.com (formerly stainlessapi.com).

The SDK Studio now shows Terraform schemas and snippets in the SDK preview pane.

Stainless automatically resolves more repetitive, low-risk merge conflicts with a syntax-aware merge algorithm.

When generating code snippets for documentation providers, Stainless will prioritize the first example in your OpenAPI spec’s request examples.

Generate a Terraform Provider for your API using Stainless to allow your customers to automatically provision resources in your API. Follow this guide to get started. To see an example in action, try the Cloudflare v5 Terraform Provider.

For any feedback or feature requests, ping dackerman@.

You can now ignore specific diagnostics in the SDK Studio to better prioritize build-critical ones.

See changes you’re making to the Stainless Config and the OpenAPI spec before you save them.

Setting max_retries to 0 is now supported across our SDKs. Use this setting if retries are not compatible with your API.

When deprecating a schema, SDKs will include a message. In your OpenAPI spec, add x-stainless-deprecation-message: <your message> alongside deprecated: true to use this feature.

SDKs now support endpoints that return JSONL responses. Mark your endpoint’s content type as application/jsonl or application/x-jsonl to use this feature.

The SDK Studio now features a redesigned preview pane with an improved look and feel. Use the preview pane to review complete language-specific content including method signatures, parameters, types, and more.

Use Cmd+S (Ctrl+S on Linux/Windows) to save your progress in the SDK Studio.

The project dashboard page displays the status of each SDK, release configuration, and build history.

The Java and Kotlin SDKs support logging requests when setting a <OrgName>_LOG environment variable to info or debug depending on the desired verbosity.

This is also available in Python and TypeScript.

The Java and Kotlin SDKs now use custom, SDK-specific code instead of Guava, reducing generated JAR size by 10% (3 MB).

The Java and Kotlin SDKs automatically prevent accidental memory leaks. If a user forgets to close an HTTP response or client, then it will be automatically closed when it becomes phantom reachable.

SDKs now include an X-Stainless-Retry-Count header in every request to indicate the current retry attempt. This provides better visibility into why requests are being sent to your API.

Stainless now seamlessly integrates with JSR, a multi-platform package manager for TypeScript developed by the Deno team.