---
schema: 1
type: term
title: _dynamic mode_
description: >-
  In Stainless's MCP tooling, **_dynamic mode_** is a server mode in which the
  MCP server exposes just three tools — _list endpoints_, _get endpoint_,
  _execute endpoint_ — no matter how large the underlying API is, keeping
  context cost small at the price of extra model turns per action.
canonical: 'https://liquidgold.cc/channel/everyinc/explore/term/dynamic-mode-d3bfa6bdde37'
markdown: >-
  https://liquidgold.cc/channel/everyinc/explore/term/dynamic-mode-d3bfa6bdde37.md
llms: null
parent: 'https://liquidgold.cc/channel/everyinc/llms.txt'
channel: everyinc
updated: '2026-10-23T22:12:35.346Z'
language: null
children: []
---


# \_dynamic mode\_

Canonical: https://liquidgold.cc/channel/everyinc/explore/term/dynamic-mode-d3bfa6bdde37

Parent: [Channel index](https://liquidgold.cc/channel/everyinc/llms.txt)

## Definition

In Stainless's MCP tooling, **_dynamic mode_** is a server mode in which the MCP server exposes just three tools — _list endpoints_, _get endpoint_, _execute endpoint_ — no matter how large the underlying API is, keeping context cost small at the price of extra model turns per action.

## 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*.   [^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.  [^913c216d-5ccb-51d9-8f42-8feb7c017d9d@1346] ## 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.  [^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.  [^913c216d-5ccb-51d9-8f42-8feb7c017d9d@2142]