Where the term comes from ## Dynamic mode in context: the context-window problem The term dynamic mode appears in Alex Rattray's explanation of why naive MCP server design fails at scale. Translating a big API one-to-one into MCP tools fails because big APIs are big: the Stripe API exposes hundreds of endpoints, and exposing each as an MCP tool — with descriptions, request and response properties, and docs — burns hundreds of thousands of tokens from the context budget before any real work starts. [moment: 871] [moment: 919] [^913c216d-5ccb-51d9-8f42-8feb7c017d9d@871] [^ea9761fa-0184-555e-be30-4928a6682680@919] The standard advice — keep the number of tools small, with precise names, few parameters, and trimmed responses — only goes so far when the underlying API is enormous. [moment: 1346] [^913c216d-5ccb-51d9-8f42-8feb7c017d9d@1346] How dynamic mode works ## How dynamic mode solves tool-browsing at scale To solve tool-browsing at scale, Stainless offers dynamic mode: no matter how big the API, the MCP server exposes just three tools — list endpoints, get endpoint, execute endpoint. Context cost scales beautifully, but one action costs three turns of the model — slower, more expensive, and slightly lossier in performance. [moment: 1453] [^913c216d-5ccb-51d9-8f42-8feb7c017d9d@1453] So the mode is explicitly a scaling tradeoff: it trades a larger number of model turns for a dramatically smaller up-front context footprint. - Dynamic mode is Stainless's scaling strategy for MCP servers serving very large APIs.- The server exposes exactly three tools — list endpoints, get endpoint, execute endpoint — regardless of API size.- The tradeoff: context cost scales well, but each action takes three model turns, making it slower, more expensive, and slightly lossier.- It contrasts with the code-execution approach, where the model writes TypeScript against the SDK instead of clicking through tools. [moment: 2142] [^913c216d-5ccb-51d9-8f42-8feb7c017d9d@2142]