laburnum 1.17.1

An LSP framework for building language servers and compilers, powered by an incremental query tree with content-addressed storage, task-based dataflow, and parallel queries.
Documentation
// Copyright Two Neutron Stars Incorporated and contributors
// SPDX-License-Identifier: BlueOak-1.0.0

//! Built-in MCP tools that wrap a curated subset of LSP methods.
//!
//! See ADR0010 for the full design rationale. The same rationale is mirrored
//! below so anyone reading the tool implementations can see *why* the surface
//! is shaped the way it is without leaving the file.
//!
//! # What this module exposes
//!
//! - Query-shaped tools (no position required): `find_symbol`,
//!   `document_symbols`, `file_diagnostics`, `workspace_diagnostics`.
//! - Position-shaped tools (agent supplies uri + line + character):
//!   `goto_*`, `find_references`, `hover`, `code_actions`.
//! - Two-step chains exposed as single tools: `call_hierarchy_incoming`,
//!   `call_hierarchy_outgoing`, `type_hierarchy_supertypes`,
//!   `type_hierarchy_subtypes`.
//! - Mutating-but-non-applying: `prepare_rename`, `rename` — the latter
//!   returns the `WorkspaceEdit` JSON for the agent to apply itself with
//!   its own Edit/Write tools.
//! - Extension hatch: `execute_command::register_commands` — surfaced only
//!   when the implementing crate registers commands. Each registered
//!   command becomes its own typed MCP tool.
//!
//! # What this module deliberately does NOT expose, and why
//!
//! - **Lifecycle / sync** (`initialize`, `didOpen`, `didChange`, `didClose`,
//!   `didSave`, `willSave`, `willSaveWaitUntil`, file-watch notifications,
//!   workspace folder changes): handled internally by the MCP adapter's
//!   own connection to the daemon. Agents do not drive editor state — the
//!   daemon's filesystem hooks already keep the database in sync with the
//!   workspace.
//! - **`textDocument/publishDiagnostics`** (push): MCP is request/response
//!   with no native push channel that fits this shape. Agents pull
//!   diagnostics on demand via `file_diagnostics` / `workspace_diagnostics`.
//! - **`textDocument/completion`, `textDocument/signatureHelp`,
//!   `textDocument/selectionRange`**: position-based cursor UX. Their
//!   results only make sense with an interactive cursor for the user to
//!   pick from — an agent does not have a cursor.
//! - **`textDocument/formatting`, `textDocument/rangeFormatting`,
//!   `textDocument/onTypeFormatting`**: the agent edits files directly
//!   with its own Edit/Write tools. Format-on-save is editor-only
//!   behavior.
//! - **`textDocument/semanticTokens`, `textDocument/codeLens`,
//!   `textDocument/inlayHint`, `textDocument/documentColor`,
//!   `textDocument/documentLink`, `textDocument/foldingRange`,
//!   `textDocument/documentHighlight`,
//!   `textDocument/linkedEditingRange`, `textDocument/inlineValue`**:
//!   pure visual editor UX. No agent value.
//! - **`textDocument/moniker`**: cross-repo SCIP-style identifiers.
//!   Deferred until we have a concrete use case to motivate the MCP tool
//!   shape.
//!
//! These exclusions can be revisited if a real agent workflow needs one of
//! them. The absence here is "we don't see the use case", not "we cannot
//! do it".

pub mod code_action;
pub mod diagnostics;
pub mod execute_command;
pub mod goto;
pub mod hierarchy;
pub mod hover;
pub mod references;
pub mod rename;
pub mod symbol;

use crate::connect::mcp::tool::ToolRegistry;

/// Register the default set of language-agnostic tools onto a registry.
///
/// This is what `McpServerBuilder::with_default_tools` calls. Implementing
/// crates can call it directly if they want the default set plus their own
/// additions.
pub fn register_defaults(registry: &mut ToolRegistry) {
  symbol::register(registry);
  goto::register(registry);
  references::register(registry);
  hover::register(registry);
  diagnostics::register(registry);
  hierarchy::register(registry);
  code_action::register(registry);
  rename::register(registry);
}