LSP and tools for agents
Catenary runs one language server for your code and shares it between the editor and the agents. It also gives every agent running in a Catenary terminal a set of tools to drive the IDE: open a file, split a terminal, start a task, ask for your attention. There is nothing to configure.
One language server, shared
TypeScript, JavaScript and Python files are served by a local engine: typescript-language-server and pyright, bundled with the app. There is one server per workspace, worktree and language, and it restarts on its own if it crashes. When the project has its own typescript in node_modules, that is the one used.
In the editor it powers completion, hover, go to definition, references, rename, diagnostics and semantic highlighting.
The same engine, for agents
Five read-only tools put that server in the agent's hands:
| Tool | What it returns |
|---|---|
catenary_lsp_definition | Where a symbol is defined, by position or by name |
catenary_lsp_references | Where it is used |
catenary_lsp_hover | The full type signature and its documentation |
catenary_lsp_document_symbols | The symbol tree of a file |
catenary_lsp_diagnostics | Errors and warnings, for one file or the whole workspace |
The agent reads what you see. If the file is open in the editor with unsaved changes, the answer comes from that buffer, not from disk, and every result says which one it used: source: "buffer" or source: "disk". While the server is still indexing, the result says that too, and an empty list of diagnostics is not yet a clean bill of health.
Registered on its own
When a terminal starts, Catenary adds a server named catenary to the MCP config of each agent CLI installed on the machine: Claude Code, Codex, Antigravity, Cursor and OpenCode.
- It only touches agents that have actually run there.
- It never replaces a
catenaryentry you wrote yourself. - Outside a Catenary terminal the server lists no tools, so the entry costs nothing elsewhere.
Cursor asks once to approve the server. That prompt belongs to Cursor.
The tools
| Tool | What it does |
|---|---|
catenary_get_environment | Describes the session the agent is running in |
catenary_open_file | Opens a file in the editor, at a line and column |
catenary_split_terminal | Splits the agent's terminal; the new pane starts in the same folder |
catenary_create_worktree | Creates an isolated branch |
catenary_create_task | A worktree plus a terminal session; with an instruction, it also launches an agent there |
catenary_capture_preview | Captures the session's built-in browser |
catenary_get_canvas_state | Lists the sessions, panels, branches and open ports of the workspace |
catenary_request_attention | Raises a request under the bell. It asks for your attention; it never grants an approval |
They obey the same switches as the catenary CLI, in Settings, CLI: a Read and a Control column for each surface (Browser, Terminal, Panels, Editor, Notifications, Boards, Maestro). All are on by default. Turn off Command-line control (Catenary CLI) and none of the tools works.
A structured inbox
catenary_delegate_task queues a message for another agent in the same workspace: an instruction and, if needed, a list of files. Nothing is typed into its terminal. The other agent reads it with catenary_read_inbox and confirms it with catenary_ack_message.
- Reading marks a message as delivered, and acknowledging marks it as received. Neither means the task is done.
- Retrying with the same
operationIdnever creates a duplicate. - A message nobody reads expires after 24 hours.
For a question that needs an answer right now, catenary ask is still the shorter path. See connection wires.