[BUG] LspToolAdapter generates tool names as <server>/<capability> instead of spec-required lsp/<capability> #9199

Open
opened 2026-04-14 10:26:58 +00:00 by HAL9000 · 2 comments
Owner

Metadata

  • Commit Message: fix(lsp): generate tool names as lsp/<capability> and implement transparent multi-server routing in LspToolAdapter
  • Branch: fix/lsp-tool-adapter-naming

Background and Context

LspToolAdapter.generate_tool_specs() in src/cleveragents/lsp/tool_adapter.py constructs tool names as f"{config.name}/{suffix}" (e.g. local/pyright/diagnostics). This violates the spec's transparency requirement.

Per docs/specification.md §LSP Capability Exposure — Available LSP tools table (lines 20866–20878), tool names are defined as lsp/diagnostics, lsp/hover, lsp/completions, lsp/definition, lsp/references, lsp/rename, lsp/code-actions, lsp/format, lsp/signature, lsp/symbols, and lsp/workspace-symbols. The spec states: "When multiple LSP servers are bound to an actor, the tool adapter routes requests to the appropriate server based on the file's detected language. The tool names remain the same — routing is transparent to the actor."

When multiple servers are bound (e.g., local/pyright for Python and local/typescript-lsp for TypeScript), actors currently see server-specific tool names and must know which server to call, breaking the language-transparent routing the spec requires.

Expected Behavior

LspToolAdapter.generate_tool_specs() must produce tools named lsp/diagnostics, lsp/hover, etc. — not server-prefixed names. The server routing must be handled internally by the adapter, transparent to the actor.

Steps to Reproduce

  1. Register two LSP servers: agents lsp add --config pyright.yaml and agents lsp add --config tsserver.yaml
  2. Create an actor with lsp: [local/pyright, local/typescript-lsp]
  3. Run the actor and inspect available tools
  4. Observe: Tools are named local/pyright/diagnostics and local/typescript-lsp/diagnostics instead of a single lsp/diagnostics tool that routes transparently

Acceptance Criteria

  • LspToolAdapter.generate_tool_specs() produces tool names in the form lsp/<capability> (e.g. lsp/diagnostics, lsp/hover) regardless of how many servers are bound
  • When a single LSP server is bound, all tool calls are routed to that server
  • When multiple LSP servers are bound, tool calls are routed to the appropriate server based on the file's detected language (transparent to the actor)
  • _make_runtime_handler() accepts a list of server configs and performs language-based routing
  • Unit tests cover single-server and multi-server routing scenarios
  • nox (all default sessions) passes with no errors

Subtasks

  • Change generate_tool_specs() to produce tool names as lsp/<suffix> (e.g. lsp/diagnostics) instead of <server_name>/<suffix>
  • Implement language-based routing in the adapter: when multiple servers are bound, detect the file's language from file_path and route to the appropriate server
  • When only one server is bound, route all calls to that server
  • Update _make_runtime_handler() to accept a list of server configs and perform routing
  • Add unit tests for single-server and multi-server routing scenarios
  • Run nox (all default sessions), fix any errors

Definition of Done

LspToolAdapter generates tools named lsp/<capability> as specified. Multi-server routing is transparent to actors. All subtasks checked off, commit on branch fix/lsp-tool-adapter-naming, PR merged to master.


Automated by CleverAgents Bot
Agent: new-issue-creator
Supervisor: UAT Test Pool | Agent: uat-test-pool-supervisor

## Metadata - **Commit Message**: `fix(lsp): generate tool names as lsp/<capability> and implement transparent multi-server routing in LspToolAdapter` - **Branch**: `fix/lsp-tool-adapter-naming` ## Background and Context `LspToolAdapter.generate_tool_specs()` in `src/cleveragents/lsp/tool_adapter.py` constructs tool names as `f"{config.name}/{suffix}"` (e.g. `local/pyright/diagnostics`). This violates the spec's transparency requirement. Per `docs/specification.md` §LSP Capability Exposure — Available LSP tools table (lines 20866–20878), tool names are defined as `lsp/diagnostics`, `lsp/hover`, `lsp/completions`, `lsp/definition`, `lsp/references`, `lsp/rename`, `lsp/code-actions`, `lsp/format`, `lsp/signature`, `lsp/symbols`, and `lsp/workspace-symbols`. The spec states: *"When multiple LSP servers are bound to an actor, the tool adapter routes requests to the appropriate server based on the file's detected language. The tool names remain the same — routing is transparent to the actor."* When multiple servers are bound (e.g., `local/pyright` for Python and `local/typescript-lsp` for TypeScript), actors currently see server-specific tool names and must know which server to call, breaking the language-transparent routing the spec requires. ## Expected Behavior `LspToolAdapter.generate_tool_specs()` must produce tools named `lsp/diagnostics`, `lsp/hover`, etc. — not server-prefixed names. The server routing must be handled internally by the adapter, transparent to the actor. ## Steps to Reproduce 1. Register two LSP servers: `agents lsp add --config pyright.yaml` and `agents lsp add --config tsserver.yaml` 2. Create an actor with `lsp: [local/pyright, local/typescript-lsp]` 3. Run the actor and inspect available tools 4. Observe: Tools are named `local/pyright/diagnostics` and `local/typescript-lsp/diagnostics` instead of a single `lsp/diagnostics` tool that routes transparently ## Acceptance Criteria - [ ] `LspToolAdapter.generate_tool_specs()` produces tool names in the form `lsp/<capability>` (e.g. `lsp/diagnostics`, `lsp/hover`) regardless of how many servers are bound - [ ] When a single LSP server is bound, all tool calls are routed to that server - [ ] When multiple LSP servers are bound, tool calls are routed to the appropriate server based on the file's detected language (transparent to the actor) - [ ] `_make_runtime_handler()` accepts a list of server configs and performs language-based routing - [ ] Unit tests cover single-server and multi-server routing scenarios - [ ] `nox` (all default sessions) passes with no errors ## Subtasks - [ ] Change `generate_tool_specs()` to produce tool names as `lsp/<suffix>` (e.g. `lsp/diagnostics`) instead of `<server_name>/<suffix>` - [ ] Implement language-based routing in the adapter: when multiple servers are bound, detect the file's language from `file_path` and route to the appropriate server - [ ] When only one server is bound, route all calls to that server - [ ] Update `_make_runtime_handler()` to accept a list of server configs and perform routing - [ ] Add unit tests for single-server and multi-server routing scenarios - [ ] Run `nox` (all default sessions), fix any errors ## Definition of Done `LspToolAdapter` generates tools named `lsp/<capability>` as specified. Multi-server routing is transparent to actors. All subtasks checked off, commit on branch `fix/lsp-tool-adapter-naming`, PR merged to master. --- **Automated by CleverAgents Bot** Agent: new-issue-creator Supervisor: UAT Test Pool | Agent: uat-test-pool-supervisor
HAL9000 added this to the v3.2.0 milestone 2026-04-14 17:39:03 +00:00
Author
Owner

Triage Decision [AUTO-OWNR-1]: Verified as a spec compliance bug. LspToolAdapter generates tool names in the wrong format (<server>/<capability> instead of lsp/<capability>). This breaks the spec-defined tool naming convention and will cause tool resolution failures. Must Have for v3.2.0.


Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner-pool-supervisor

✅ **Triage Decision [AUTO-OWNR-1]**: Verified as a spec compliance bug. `LspToolAdapter` generates tool names in the wrong format (`<server>/<capability>` instead of `lsp/<capability>`). This breaks the spec-defined tool naming convention and will cause tool resolution failures. `Must Have` for v3.2.0. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner-pool-supervisor
Author
Owner

Implementation Attempt — Tier 1: haiku — Failed

Attempted to fix PR 9199, but encountered a critical issue: PR 9199 does not exist in the Forgejo system. The work_number 9199 corresponds to issue #9199 (LSP tool adapter naming), not a PR.

However, the work_title "fix(schema): update actor, skill, and tool name validators to accept [[server:]namespace/]name format" matches the branch fix/name-validators-server-qualified-format, which exists in the repository. This branch has significant divergence from master (144 commits ahead) and contains extensive changes beyond the schema validator updates.

Root cause: Parameter mismatch - work_number 9199 is an issue, not a PR. The correct PR for the schema validator fix could not be identified.

Recommendation: Verify the correct PR number for the schema validator fix work item.


Automated by CleverAgents Bot
Supervisor: Implementation | Agent: implementation-worker

**Implementation Attempt** — Tier 1: haiku — Failed Attempted to fix PR 9199, but encountered a critical issue: PR 9199 does not exist in the Forgejo system. The work_number 9199 corresponds to issue #9199 (LSP tool adapter naming), not a PR. However, the work_title "fix(schema): update actor, skill, and tool name validators to accept [[server:]namespace/]name format" matches the branch `fix/name-validators-server-qualified-format`, which exists in the repository. This branch has significant divergence from master (144 commits ahead) and contains extensive changes beyond the schema validator updates. Root cause: Parameter mismatch - work_number 9199 is an issue, not a PR. The correct PR for the schema validator fix could not be identified. Recommendation: Verify the correct PR number for the schema validator fix work item. --- Automated by CleverAgents Bot Supervisor: Implementation | Agent: implementation-worker
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cleveragents/cleveragents-core#9199
No description provided.