What problem are you trying to solve?
NOOA’s CodeAct/pass-by-reference execution model is strong for structured agent behavior, but coding agents currently lack first-class Language Server Protocol (LSP) capabilities for repository-aware code intelligence.
For larger codebases, relying on text search and file inspection alone makes tasks such as symbol navigation, reference discovery, diagnostics, and rename/refactor operations less efficient and less reliable.
The goal is to give NOOA coding agents a language-agnostic interface to standard language servers such as Pyright, rust-analyzer, clangd, gopls, and TypeScript language servers.
Proposed solution
Add a generic LSP client/service to NOOA that exposes language-server capabilities as typed Python objects usable from CodeAct. This would be implemented as an optional Skill module (not required by defaut).
For example:
lsp = await self.lsp.for_file("src/orders.py")
definitions = await lsp.definition("OrderService")
references = await lsp.references("OrderService")
diagnostics = await lsp.diagnostics("src/orders.py")
symbols = await lsp.document_symbols("src/orders.py")The implementation should remain language-server agnostic and handle:
- LSP server process lifecycle
- workspace initialization
- file/language-to-server resolution
- JSON-RPC transport
- diagnostics
- go-to-definition
- references
- document/workspace symbols
- rename
- capability discovery
- restart/error handling
A declarative server registry could define executable names, file/language matching, arguments, initialization options, and per-server configuration.
The feature should preserve NOOA’s existing execution model: LSP results should be exposed as structured/live Python objects rather than flattened into large prompt strings.
Alternatives considered
- Integrate directly with individual servers such as Pyright, rust-analyzer, or tsserver. This would duplicate lifecycle and protocol logic and make multi-language support harder to maintain.
- Wrap an existing coding agent’s LSP subsystem, such as Oh My Pi’s implementation, as an external service. This could accelerate a prototype but would introduce another runtime/process boundary and tighter coupling to another project.
- Rely on grep/tree-sitter/AST search only. These remain useful but do not provide semantic information such as resolved references, diagnostics, or language-aware refactoring.
A useful implementation reference is Oh My Pi’s LSP subsystem, which provides a generic client over standard LSP servers and maintains a broad declarative server configuration registry.
Additional context
This would complement NOOA’s existing CodeAct and pass-by-reference model particularly well: instead of serializing large code-navigation results into model context, the agent could retain and operate on structured LSP results as live objects.
It would also help make NOOA more capable as a general-purpose coding-agent runtime across Python, TypeScript/JavaScript, Rust, Go, C/C++, C#, Java/Kotlin, and other languages with mature LSP servers.
A reasonable first milestone could support:
- server discovery/configuration
- initialize/shutdown lifecycle
- diagnostics
- definition
- references
- document symbols
- rename
with broader LSP capabilities added incrementally later.
If this feature would be welcome to the NOOA project, I'd be willing to code and contribute it. Happy to discuss implementation details, testing strategy, or integration points with the existing codebase.
What problem are you trying to solve?
NOOA’s CodeAct/pass-by-reference execution model is strong for structured agent behavior, but coding agents currently lack first-class Language Server Protocol (LSP) capabilities for repository-aware code intelligence.
For larger codebases, relying on text search and file inspection alone makes tasks such as symbol navigation, reference discovery, diagnostics, and rename/refactor operations less efficient and less reliable.
The goal is to give NOOA coding agents a language-agnostic interface to standard language servers such as Pyright, rust-analyzer, clangd, gopls, and TypeScript language servers.
Proposed solution
Add a generic LSP client/service to NOOA that exposes language-server capabilities as typed Python objects usable from CodeAct. This would be implemented as an optional Skill module (not required by defaut).
For example:
The implementation should remain language-server agnostic and handle:
A declarative server registry could define executable names, file/language matching, arguments, initialization options, and per-server configuration.
The feature should preserve NOOA’s existing execution model: LSP results should be exposed as structured/live Python objects rather than flattened into large prompt strings.
Alternatives considered
A useful implementation reference is Oh My Pi’s LSP subsystem, which provides a generic client over standard LSP servers and maintains a broad declarative server configuration registry.
Additional context
This would complement NOOA’s existing CodeAct and pass-by-reference model particularly well: instead of serializing large code-navigation results into model context, the agent could retain and operate on structured LSP results as live objects.
It would also help make NOOA more capable as a general-purpose coding-agent runtime across Python, TypeScript/JavaScript, Rust, Go, C/C++, C#, Java/Kotlin, and other languages with mature LSP servers.
A reasonable first milestone could support:
with broader LSP capabilities added incrementally later.
If this feature would be welcome to the NOOA project, I'd be willing to code and contribute it. Happy to discuss implementation details, testing strategy, or integration points with the existing codebase.