January 2026 Summaries

Starting today, deploying a generated MCP server from an OpenAPI specification has been simplified with the introduction of the command "speakeasy mcp deploy," which allows users to host their server on https://getgram.ai without requiring infrastructure setup. Traditionally, teams had to manage complex infrastructure tasks such as setting up Docker containers, cloud functions, authentication, and HTTPS certificates to make APIs accessible to AI agents, a process that was manual and time-consuming. This new deployment solution addresses the "Day 0" problem by providing a live, publicly accessible endpoint within minutes, eliminating the need for immediate infrastructure decisions or deployment pipelines. As needs evolve, users retain the flexibility to move their MCP server to their own infrastructure since the generated code is compatible with any environment that supports Node.js. The deployment process is integrated into the workflow.yaml and gen.yaml configurations, and further enhancements such as custom domains, environment management, and CI/CD integration are planned to improve the hosting experience.

Vishal Gowda's article explores methodologies for handling evolving APIs in Java, focusing on implementing forward-compatible union types with Jackson. It discusses the challenges of maintaining backward compatibility when APIs introduce new types, emphasizing the importance of preserving unknown data to prevent crashes. Two primary patterns, discriminated and non-discriminated unions, are examined. Discriminated unions, suitable for object-only members, utilize a discriminator property within JSON objects to resolve types using Jackson annotations, while non-discriminated unions handle mixed member types via a custom deserializer, using a fallback mechanism to manage unknown data. The article highlights the limitations of Java interfaces and the advantages of using wrapper patterns for external types or primitives. It also touches on the enhancements Java 17+ brings, such as sealed interfaces and records, to simplify union handling. Additionally, the piece introduces Speakeasy, a tool for generating forward-compatible Java SDKs from OpenAPI specifications, which automates these patterns to ensure robust API interactions.

Vishal Gowda discusses the limitations of Java's native enums in dealing with evolving APIs and offers a solution through a class-based "open enum" pattern. Native enums in Java are fixed at compile time, which can cause issues when an API introduces new enum values that the consuming code isn't prepared to handle, leading to deserialization failures and potential service disruptions. Replacing enums with strings sacrifices type safety, while configuring deserialization to handle unknown values as null introduces ambiguity and potential bugs. The proposed "open enum" pattern involves wrapping string values in a class, using static constants for ease of use, implementing singleton caching for reference equality, and adding an inner enum to maintain exhaustive switch statements and type safety. This approach preserves unknown values, maintains type safety, and allows for both reference equality and exhaustive switches, providing a more robust solution for APIs that evolve over time. The pattern is integrated into Speakeasy for generating Java SDKs, offering a forward-compatible approach to handling API responses.

Designing forward-compatible unions in TypeScript involves addressing challenges related to API evolution, especially when handling unknown variants in SDKs. A common problem arises when APIs introduce new providers or types, causing applications to crash if they cannot parse unexpected data. While proper API versioning could mitigate this, it is not always feasible, making forward-compatible client design a practical necessity. The article explores several strategies to handle this, emphasizing the importance of preserving type narrowing and gracefully managing new server responses. One effective approach uses a sentinel value like "UNKNOWN" to capture unknown variants while maintaining type safety, although it may introduce breaking changes if the API later adopts "UNKNOWN" as a legitimate value. The Speakeasy SDK generator employs this approach when a discriminator can be inferred, defaulting to a monadic wrapper for more complex polymorphic unions without common discriminators. Overall, the article highlights that while there are no perfect solutions, understanding the trade-offs of each method is crucial for building robust and forward-compatible SDKs.

As AI agents become integral to organizations, managing access to MCP servers without individual credentials has become a challenge, which Gram addresses through its centralized MCP gateway and OAuth feature. This setup allows platform teams to manage servers, environments, and API keys centrally while providing users with seamless access via standard authentication methods like Google SSO. Initially, organizations often manage their own MCP servers, leading to issues with credential duplication and security as usage grows. Gram’s platform offers a solution by hosting all MCP servers centrally, setting up credentials once, and enabling OAuth-based access, eliminating the need for users to handle API keys. By integrating Gram OAuth, users can access servers easily as they would any other service, and administrators can onboard members simply by adding them to the organization, streamlining the process significantly.

Speakeasy has updated its Ruby SDKs to support Ruby 4.0, which was released on December 25, 2025, incorporating new features such as Ruby Box for isolated definition spaces, the experimental ZJIT compiler, and upgrades to core classes like Set and Pathname. The update also includes the removal of deprecated methods and changes to *nil behavior, as well as the elimination of process creation via IO and various standard library modifications. Speakeasy ensures seamless compatibility with these changes, allowing users to maintain focus on their core products without interruption. Users of Speakeasy can easily regenerate their SDKs to incorporate these improvements, while those maintaining SDKs manually are encouraged to use Speakeasy to alleviate concerns about runtime compatibility.