Iterate on your SDKs locally with the Stainless Language Server
Source: Dev.to
Stainless Language Server
Stainless users configure their SDKs with two files: a stainless.yml config and an OpenAPI spec. Together, these files define how your API maps to generated SDKs—from resource structure and method naming to type definitions and pagination behavior. Getting them right is what makes the difference between a generated SDK that feels hand‑written and one that feels auto‑generated.
Until now, editing these files meant working in Stainless Studio or pushing changes and waiting for build feedback. That workflow works, but it has limitations: you make a change, trigger a build, wait for diagnostics, fix an issue, and repeat. For quick iterations on your config or spec, that loop is slower than it needs to be.
Today we’re releasing the Stainless Language Server, which brings the editing capabilities of the Studio directly into your local development environment. If you use VS Code, Cursor, Neovim, Zed, or any editor that supports the Language Server Protocol (LSP), you can now get real‑time feedback on your Stainless config and OpenAPI spec as you type.
What the Language Server does
The Stainless Language Server understands the relationship between your stainless.yml and your OpenAPI spec. It knows which endpoints map to which resources, which schemas are referenced where, and what valid configuration options look like in context. That understanding powers a set of features that make local editing significantly more productive.
Real‑time diagnostics and quick fixes
- Analyzes your Stainless config and OpenAPI spec in real time.
- Surfaces errors, warnings, and suggestions directly in your editor.
- Common issues include an autofix you can apply with one click.
- Warning‑level diagnostics can be suppressed with a single action.
The diagnostics engine is identical to the one used in Studio, so you get the same feedback locally without leaving your editor.
Intelligent completions
When editing stainless.yml, the server offers context‑aware autocompletion:
- Valid config keys.
- Endpoint paths and schema names drawn from your OpenAPI spec.
- Suggestions for new resource methods and referenced schemas.
This is especially useful for large APIs—no more flipping between a long spec and the config file.

Go to definition & find all references
- Go to definition jumps from a reference in
stainless.ymlstraight to the corresponding schema, parameter, or endpoint in the OpenAPI spec. - Find all references shows where a particular schema or endpoint is used across both files.
For teams with specs that contain hundreds of endpoints, this navigation alone saves a huge amount of time.

Codelenses in your OpenAPI spec
Codelenses appear inline in the spec, showing which schemas and endpoints are already configured in your Stainless config. This gives you a quick visual overview of your API’s SDK coverage without switching files.
Live transformations
If you use Stainless Transforms to reshape your OpenAPI spec, the language server generates and updates the transformed spec in real time as you edit your config. You can see the effect of each transform immediately, without a separate build step.
Getting set up
Setup takes only a few minutes. Install the Stainless CLI, initialize your workspace, and add the extension for your editor.
Install the CLI
brew tap stainless-api/tap
brew install stl
Initialize your workspace
stl init
This creates a .stainless/workspace.json file that the language server uses to identify your project and locate your config and spec files.
Install the editor extension
- VS Code / Cursor – Search for “Stainless” in the Extensions view and install it. The extension bundles the language server, so no separate LSP installation is needed.
- Neovim and other LSP‑compatible editors – Install the language server globally via npm:
npm install -g @stainless-api/stainless-language-server
Then configure your LSP client to run:
stainless-language-server --stdio
The server activates for YAML and JSON files when it detects .stainless/workspace.json in your project. See the full setup guide for additional configuration details.
[In‑less documentation – Install the extension for your editor](https://inless.com/docs/guides/iterate-with-lsp/#-install-the-extension-for-your-editor) has editor‑specific configuration examples.
[](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fy1wcvfjh7ug9bp6y5zjl.gif)
## The local development workflow
With the language server running, the workflow for iterating on your SDK configuration looks like this:
1. Open your `stainless.yml` and OpenAPI spec in your editor.
2. Edit your config with completions and inline validation guiding you.
3. See diagnostics in real‑time as you type, catching misconfigurations before they reach a build.
4. Use **go‑to‑definition** to navigate between your config and spec.
5. Review codelenses to check SDK coverage across your API.
6. When you’re satisfied, push your changes to Stainless for a full build.
This is the same set of features available in **Stainless Studio**, now running locally. For teams that prefer working in their own editor—or that want to use AI coding tools like Claude or Cursor alongside their Stainless config—the language server makes that possible.
## Try it out
The Stainless Language Server is available now. Install the [VS Code extension](https://marketplace.visualstudio.com/items?itemName=stainless.vscode-stainless) or the [npm package](https://www.npmjs.com/package/@stainless-api/stainless-language-server) and check out the [documentation](https://www.stainless.com/docs/guides/iterate-with-lsp/) for detailed setup instructions.
If you run into issues or have feedback, reach out to .