Oct 7, 2025

Max Murin
Users can now launch a remote MCP server using Streamable HTTP transport.
When you pass --transport=http, the server uses the Streamable HTTP transport instead of stdio, allowing it to run remotely (e.g., on EC2, Fly.io, or Kubernetes). You can optionally specify the port with --port.
npx -y my-org-mcp --transport=http # if you publish your server via Docker Hub, run it from the image: docker run --rm -i myorg/my-api-mcp --transport
Learn more about remote MCP servers in docs.
Oct 7, 2025

Max Murin
Users can now launch a remote MCP server using Streamable HTTP transport.
When you pass --transport=http, the server uses the Streamable HTTP transport instead of stdio, allowing it to run remotely (e.g., on EC2, Fly.io, or Kubernetes). You can optionally specify the port with --port.
npx -y my-org-mcp --transport=http # if you publish your server via Docker Hub, run it from the image: docker run --rm -i myorg/my-api-mcp --transport
Learn more about remote MCP servers in docs.
Oct 7, 2025

Max Murin
Users can now launch a remote MCP server using Streamable HTTP transport.
When you pass --transport=http, the server uses the Streamable HTTP transport instead of stdio, allowing it to run remotely (e.g., on EC2, Fly.io, or Kubernetes). You can optionally specify the port with --port.
npx -y my-org-mcp --transport=http # if you publish your server via Docker Hub, run it from the image: docker run --rm -i myorg/my-api-mcp --transport
Learn more about remote MCP servers in docs.
Oct 6, 2025

Max Murin
A new code execution tool is now available for Stainless generated MCP servers. Instead of exposing one tool per API method, the server can now expose a single tool that accepts TypeScript code and executes it in a secure Deno sandbox against your generated SDK.
Code execution reduces context window usage and is often faster and more accurate than exposing dozens of discrete tools. The feature is currently supported for local MCP servers, with remote support coming soon.
Check out docs for more info.
Oct 6, 2025

Max Murin
A new code execution tool is now available for Stainless generated MCP servers. Instead of exposing one tool per API method, the server can now expose a single tool that accepts TypeScript code and executes it in a secure Deno sandbox against your generated SDK.
Code execution reduces context window usage and is often faster and more accurate than exposing dozens of discrete tools. The feature is currently supported for local MCP servers, with remote support coming soon.
Check out docs for more info.
Oct 6, 2025

Max Murin
A new code execution tool is now available for Stainless generated MCP servers. Instead of exposing one tool per API method, the server can now expose a single tool that accepts TypeScript code and executes it in a secure Deno sandbox against your generated SDK.
Code execution reduces context window usage and is often faster and more accurate than exposing dozens of discrete tools. The feature is currently supported for local MCP servers, with remote support coming soon.
Check out docs for more info.
Sep 26, 2025

CJ Quines
MCP servers generated by Stainless now includes a docs search tool that lets LLMs query up-to-date documentation for your Stainless-generated SDKs. The documentation is served in Markdown optimized for model consumption, based on your latest OpenAPI spec and Stainless Config.
See docs for more details.
Sep 26, 2025

CJ Quines
MCP servers generated by Stainless now includes a docs search tool that lets LLMs query up-to-date documentation for your Stainless-generated SDKs. The documentation is served in Markdown optimized for model consumption, based on your latest OpenAPI spec and Stainless Config.
See docs for more details.
Sep 26, 2025

CJ Quines
MCP servers generated by Stainless now includes a docs search tool that lets LLMs query up-to-date documentation for your Stainless-generated SDKs. The documentation is served in Markdown optimized for model consumption, based on your latest OpenAPI spec and Stainless Config.
See docs for more details.
Jul 14, 2025

David Ackerman
Previously, large API responses could be a big problem for MCP servers - it would eat up LLM context windows with lots of irrelevant data, when a small subset may be sufficient to answer the user’s query. Manually excluding some response data in the MCP server can alleviate that problem, but then it makes some data inaccessible by the LLM.
To solve this problem, our MCP servers now provide an additional jq_filter parameter on each tool call, which allows the LLM to automatically use jq syntax to transform the API response based on the response schema.
This means that the LLM can dynamically select only the information it wants to answer the user’s query, while at the same time not restricting the data that is possible to access via the MCP server.
This functionality is automatically available in all MCP servers now.
Jul 14, 2025

David Ackerman
Previously, large API responses could be a big problem for MCP servers - it would eat up LLM context windows with lots of irrelevant data, when a small subset may be sufficient to answer the user’s query. Manually excluding some response data in the MCP server can alleviate that problem, but then it makes some data inaccessible by the LLM.
To solve this problem, our MCP servers now provide an additional jq_filter parameter on each tool call, which allows the LLM to automatically use jq syntax to transform the API response based on the response schema.
This means that the LLM can dynamically select only the information it wants to answer the user’s query, while at the same time not restricting the data that is possible to access via the MCP server.
This functionality is automatically available in all MCP servers now.
Jul 14, 2025

David Ackerman
Previously, large API responses could be a big problem for MCP servers - it would eat up LLM context windows with lots of irrelevant data, when a small subset may be sufficient to answer the user’s query. Manually excluding some response data in the MCP server can alleviate that problem, but then it makes some data inaccessible by the LLM.
To solve this problem, our MCP servers now provide an additional jq_filter parameter on each tool call, which allows the LLM to automatically use jq syntax to transform the API response based on the response schema.
This means that the LLM can dynamically select only the information it wants to answer the user’s query, while at the same time not restricting the data that is possible to access via the MCP server.
This functionality is automatically available in all MCP servers now.