I’m building a custom Language Server (LSP) for a proprietary/DSL language used internally, wired into Cursor via a standard VS Code-style extension (vscode-languageclient on the client side, publishing diagnostics via textDocument/publishDiagnostics). The goal is to have Agent read compiler-generated diagnostics in real time and self-correct before handing code back to the user — similar to how it seems to work with TypeScript/ESLint today.
A few things I haven’t been able to confirm from the docs:
Does Agent’s self-correction loop consume diagnostics from any LSP server publishing standard publishDiagnostics messages, or is it specifically tuned to recognize certain built-in linters/type-checkers (tsc, ESLint, etc.)?
Is this passive — i.e., does Agent automatically notice new diagnostics after an edit — or does it only check when explicitly told to run a lint/build/check step?
If it’s the latter, is there a way to hint Agent that a given file type has an LSP-based diagnostic source it should check after edits, without the user having to explicitly say “now check for errors” every time?
I’ve seen references to an “iterate on lint errors” feature, but couldn’t find documentation on whether it’s linter-source-agnostic. Any clarity from the team or others who’ve wired up custom language servers would be really helpful — trying to decide how much to lean on this vs. just prompting Agent to run an explicit compile/check command in a loop.
Diagnostics visibility. The Agent reads diagnostics from the same store as the Problems panel, so anything published via standard textDocument/publishDiagnostics is visible to it, including a custom vscode-languageclient server. There’s no special-casing of tsc or ESLint, and the diagnostic source string is passed to the model as-is. Note that only Error and Warning severities are surfaced.
When it checks. The Agent has a built-in lint-reading tool and is instructed to check files it just edited and fix errors it introduced (capped at roughly 3 fix iterations per file). In practice it does this after substantive edits, but that’s model behavior, not a guaranteed post-edit trigger. After an edit, it waits briefly for diagnostics to settle, and results computed against an older file version are marked stale, so if your server publishes slowly, the Agent may see stale or empty results.
You can nudge it with a rule:
After editing *.dsl files, always check linter errors and fix any you introduced.
Two things to design around:
Most LSP servers only publish diagnostics for open documents. Files the Agent edits do get opened, but files affected indirectly by an edit won’t be, so the lint check can come back empty even when your compiler would complain.
This only works in the IDE. The Agents window runs just an allowlisted set of well-known language extensions, and the CLI and Cloud Agents don’t run an extension host at all. So for a custom language server, diagnostics-based self-correction is IDE-only; use a shell-based compile/check everywhere else.
Recommendation: do both. Rely on the automatic lint pass for edited files, and add a rule telling the Agent to run your compiler’s check command before finishing.