Provides Scheme language intelligence for Ansys Fluent's Scheme scripting environment, including hover information, completions, definitions, references, and diagnostics.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@scheme-langserver-bridge Show me the type of fold-left in this Scheme file."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) bridge that connects Kimi Code CLI to scheme-langserver, giving Kimi real-time language intelligence when working with Scheme code.
When you ask Kimi to write, refactor, or explain Scheme code, Kimi can now call scheme-langserver behind the scenes to obtain:
Precise type information — via textDocument/hover
Scope-aware completions — via textDocument/completion (includes local let and lambda bindings)
Exact definition locations — via textDocument/definition
Cross-reference search — via textDocument/references
Syntax / semantic diagnostics — via textDocument/publishDiagnostics
Safe rename edits — via textDocument/rename (server support is on the roadmap)
Function signatures — via textDocument/signatureHelp (server support is on the roadmap)
Workspace-wide symbol search — via workspace/symbol (requires scheme-langserver ≥ 2.1.0 (tested up to 2.1.10))
Code actions — via textDocument/codeAction (server support is on the roadmap)
Important: You (the user) never interact with scheme-langserver directly. Kimi invokes the bridge tools automatically when it judges that precise code information would help its reasoning.
Related MCP server: kimi-code-mcp
scheme-langserver is actively developed and not infallible:
Type inference is experimental and may be wrong or hang on complex code.
Macro support (syntax-case, syntax-rules) is incomplete. Production builds fall back to hand-written rules.
Analysis of unfinished code is best-effort.
Implementation-specific Chez Scheme extensions may not be recognized.
workspace/symbol requires scheme-langserver ≥ 2.1.0 (tested up to 2.1.10).
textDocument/rename, textDocument/signatureHelp, and textDocument/codeAction are exposed by the bridge but still on the server's roadmap; the server may return "method not found".
Kimi is expected to treat LSP output as a reference, cross-check it against its own training knowledge, and gracefully fall back when the server returns errors or nonsense.
Requires Python 3.12+ and a local scheme-langserver executable.
pip install scheme-langserver-bridgeOr with uv:
uv pip install scheme-langserver-bridgenix run .#scheme-langserver-bridgeOr enter the development shell:
nix develop
uv sync --extra devgit clone <this-repo>
cd scheme-langserver-bridge
uv sync --extra devAdd the bridge as an MCP server:
kimi mcp add --transport stdio scheme-langserver -- \
python3 -m scheme_langserver_bridgeOr manually edit ~/.kimi/mcp.json:
{
"mcpServers": {
"scheme-langserver": {
"command": "python3",
"args": ["-m", "scheme_langserver_bridge"],
"env": {
"SCHEME_LANGSERVER_PATH": "/path/to/scheme-langserver/run"
}
}
}
}Configuration is resolved in the following priority (highest first):
Project config — .scheme-langserver.toml (or .scheme-langserver.json) in the project root
Environment variables
Built-in defaults
Create .scheme-langserver.toml in your project root:
langserver_path = "/nix/store/.../bin/scheme-langserver"
multi_thread = "enable"
type_inference = "enable"
top_environment = "R6RS"
cache_path = ".scheme-langserver-cache"
auto_update = true
max_memory_mb = 4096
max_cpu_seconds = 300Supported fields:
Field | Type | Description |
| string | Override the scheme-langserver executable path |
| string |
|
| string |
|
| string |
|
| string | Override the log file path |
| string | Directory for workspace FASL cache (scheme-langserver 2.1.3+; default: |
| bool | Allow auto-download when no executable is found |
| int | Sub-process memory limit in MB (default: 2048) |
| int | Sub-process CPU time limit in seconds (default: 180) |
If no scheme-langserver executable is found locally, the bridge can automatically download the latest release from GitHub:
Uses GitHub's static redirect URL (releases/latest/download/...) with HEAD requests to detect the latest version without consuming API rate limits.
Downloads are cached to ~/.cache/scheme-langserver-bridge/versions/<version>/.
Version-check results are cached with a 1-hour TTL.
Controlled by auto_update in project config or SCHEME_LANGSERVER_AUTO_UPDATE env var (default true).
Currently supports Linux x86_64 glibc only. Other platforms will receive a manual-installation hint.
Variable | Description | Default |
| Path to the scheme-langserver executable | auto-discover |
| Log file path |
|
| Multi-threading |
|
| Type inference |
|
| Top-level environment: |
|
| Directory for workspace FASL cache (scheme-langserver 2.1.3+; default: |
|
| Request timeout in seconds |
|
| Completion request timeout in seconds |
|
| Sub-process memory limit in MB |
|
| Sub-process CPU time limit in seconds |
|
| Allow auto-download when no executable is found |
|
| Bridge log level: |
|
| Default directory for debug crash reports | current working dir |
The bridge applies hard resource limits to the scheme-langserver child process via Unix setrlimit:
Memory (RLIMIT_AS): capped at SCHEME_LANGSERVER_MAX_MEMORY_MB (default 2048 MB). If the server tries to allocate beyond this limit, the OS will deny the allocation.
CPU time (RLIMIT_CPU): capped at SCHEME_LANGSERVER_MAX_CPU_SECONDS (default 180 s). If the server consumes more CPU time, the kernel sends SIGXCPU and terminates it.
Core dumps (RLIMIT_CORE): disabled to avoid filling disk on crashes.
If an LSP request exceeds its timeout (default 30 s, or the completion-specific timeout):
The bridge first terminates (SIGTERM) the scheme-langserver process.
It waits up to 3 seconds for graceful exit.
If the process is still alive, it is killed (SIGKILL).
All pending requests receive a timeout error so Kimi can fall back to its own knowledge.
The bridge monitors the LSP process:
If the process exits unexpectedly (stdout EOF, stderr close), the bridge marks it as crashed.
Any subsequent tool call returns an error telling Kimi to call lsp_shutdown followed by lsp_initialize to restart the server.
On shutdown signals (SIGINT, SIGTERM), the bridge gracefully stops the LSP server before exiting.
When scheme-langserver crashes or behaves abnormally, the bridge automatically generates a debug report containing:
LSP traffic log (ready-for-analyse.log) — compatible with upstream replay scripts
Open file snapshots
Server stderr and own log
Environment metadata (versions, args, diagnostics)
You can also manually export a report at any time:
lsp_export_debug_report(output_path="/optional/path")⚠️ Reports contain your source code. Review before posting to a public issue tracker.
Reports are saved to
SCHEME_BRIDGE_REPORT_DIR(or the current working directory) as:scheme-langserver-debug-report-YYYYMMDD-HHMMSS/
Below are typical Kimi conversations that trigger LSP tools automatically:
Kimi will call:
lsp_definition(file_path="/project/math.scm", line=5, character=9)And receive the exact file, line, and column where factorial is defined, e.g.:
{
"uri": "file:///project/utils.scm",
"range": {
"start": { "line": 12, "character": 7 },
"end": { "line": 12, "character": 16 }
}
}When your cursor is inside a let binding, Kimi calls:
lsp_complete(file_path="/project/main.scm", line=8, character=14)The result includes local bindings (e.g., n, acc) that a plain text search would miss:
[
{ "label": "factorial", "kind": 3 },
{ "label": "n", "kind": 6 },
{ "label": "acc", "kind": 6 }
]Kimi calls:
lsp_hover(file_path="/project/main.scm", line=4, character=12)And gets the inferred type signature and documentation:
{
"contents": [
"```scheme\n(: factorial (-> integer? integer?))\n```",
"Compute n! recursively."
]
}To test a local development build of scheme-langserver, pass langserver_path to
lsp_initialize or lsp_restart:
lsp_restart(langserver_path="/home/dev/scheme-langserver/run")The bridge will use that executable and reopen all tracked documents. This is useful when iterating on scheme-langserver itself.
All tools are prefixed with lsp_:
Tool | Purpose |
| Start scheme-langserver for a project root |
| Open a file so the server can analyze it |
| Push updated file contents to the server |
| Close a file |
| Restart scheme-langserver and reopen tracked documents |
| Get type/docs for a symbol at a position |
| Get completion candidates at a position |
| Find where a symbol is defined |
| Find all references to a symbol |
| Compute workspace edits to rename a symbol |
| Get function signature help |
| List all symbols in a file |
| Search symbols across the workspace |
| Get quick fixes / refactorings for a range |
| Get errors and warnings (critical for catching unmatched brackets / tokenizer failures in Scheme) |
| Export a debug report for upstream issue reporting |
Enter the development environment with nix develop.
ruff and pyright must be installed through nixpkgs (they are included in the dev shell via uv / pyproject.toml dev dependencies).
On NixOS, the bridge will pick up scheme-langserver from PATH if it is installed via nixpkgs.
nix develop # enter dev shell
uv sync --extra dev # install Python deps
pytest # run tests
ruff check --fix # lint
pyright # type checkKimi CLI <--MCP (stdio)--> scheme-langserver-bridge <--LSP (stdio)--> scheme-langserverThe bridge is a thin Python layer that:
Spawns scheme-langserver as a subprocess with configurable resource limits.
Speaks JSON-RPC 2.0 over stdio with the LSP server.
Exposes LSP operations as MCP tools for Kimi to call.
Manages document sync, timeouts, crash detection, and graceful shutdown.
Notify the language server that a file has changed (like pressing Save).
Send the new full text of the file. This keeps the server's internal state in sync with the actual file contents.
When to use: IMMEDIATELY after you modify a Scheme file via filesystem tools (WriteFile/StrReplaceFile). If you skip this step, subsequent diagnostics and queries will operate on stale content.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses the effect (syncs server state) and the consequence of not calling it (stale diagnostics), but does not describe side effects like whether it triggers re-diagnostics or requires an active session. Still, it adds significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence followed by a when-to-use section. It's appropriately concise, though the warning could be slightly tighter. The key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with two required parameters and an output schema, the description covers the essential context: what it does, when to use it, and the parameter semantics. It lacks details about return values, but the output schema likely handles that, keeping completeness high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does by explaining that 'text' is the new full text of the file, which clarifies the expected format. However, it doesn't specify the path format or encoding of file_path, but given the simplicity, a 4 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it notifies the server of a file change by sending the full text, and explicitly frames it as the equivalent of pressing Save. This is distinct from other lsp_* tools like lsp_open or lsp_close, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: immediately after modifying a Scheme file via filesystem tools, and warns of stale content if skipped. This makes the usage context crystal clear and helps the agent decide when to invoke it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close a file in the language server.
When to use: When you are completely done with a file or at session end. Do NOT close files just because you paused editing; frequent open/close wastes server resources.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does add a useful performance caveat about frequent open/close cycles, but it does not disclose whether unsaved edits are affected, whether close is idempotent, or what happens if the file is not currently open. This is a meaningful gap for an operation without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured: a one-line action statement followed by bolded usage guidance. Every sentence adds value, and the critical behavioral caution is placed prominently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter close operation with an output schema available, the description covers the main invocation contexts and the primary anti-pattern. It does not mention error behavior or require the file to be open explicitly, but those are minor omissions given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain file_path format (e.g., URI vs filesystem path, absolute vs relative). The single parameter is nevertheless made reasonably clear by its name and title plus the tool's 'file' reference, so semantics are inferable but not enriched beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Close a file') and the resource ('the language server'). It is immediately distinguishable from sibling tools like lsp_open, lsp_change, and lsp_shutdown because close is a distinct operation in the same lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance ('completely done with a file or at session end') and an explicit when-not-to-use instruction ('Do NOT close files just because you paused editing'). It also explains the rationale (wasted server resources), making the routing decision easy for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get code actions (quick fixes, refactorings) for a range.
Limitation: codeAction is on the scheme-langserver roadmap and may return -32601 "method not found" or behave incompletely.
| Name | Required | Description | Default |
|---|---|---|---|
| end_line | Yes | ||
| file_path | Yes | ||
| start_line | Yes | ||
| end_character | Yes | ||
| start_character | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose a limitation ('may return -32601 method not found or behave incompletely'), which is a positive behavioral note. However, it does not state whether the operation is read-only, describe the response format, or mention any side effects, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. The main purpose is front-loaded in the first sentence, and the limitation is clearly separated in the second. It is appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 required parameters, no annotations, and an output schema, the description is minimal. It does not explain parameter semantics, prerequisites (e.g., server initialization), or the expected output. The limitation note is the only extra context, making it insufficient for an agent to call the tool correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only says 'for a range,' which hints at start/end positions but does not explain the individual parameters (file_path, line/character numbers) or coordinate conventions. The parameter names are somewhat self-explanatory, but the description adds no meaningful detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Get code actions (quick fixes, refactorings) for a range.' This specifies the verb, resource, and scope. While it doesn't explicitly differentiate from sibling tools like lsp_rename, the name and description are distinct enough for an agent to identify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other LSP tools. The only additional note is a limitation about potential -32601 errors, which addresses reliability rather than usage context. No alternatives, exclusions, or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger auto-completion at the cursor position.
Like pressing Ctrl+Space in an IDE. Returns identifiers available in the current scope, including local bindings (let, lambda parameters) that may not be obvious from a simple text search.
Confidence: MEDIUM. The list may miss identifiers generated by macros.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | ||
| character | Yes | ||
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It does well by explaining what is returned (scope-aware identifiers) and by disclosing a meaningful limitation: confidence is MEDIUM and macro-generated identifiers may be missed. This goes beyond the basic action and gives the agent realistic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line action, a clarifying analogy, the behavior, and a caveat. Every sentence earns its place, and the most important information appears first. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main behavior, scope-awareness, and a confidence caveat, and an output schema exists for return values. The notable gap is the missing coordinate-system context for line and character parameters, which is important for correctly invoking an LSP completion request. Overall it is usable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain line and character semantics. It only says 'at the cursor position,' leaving ambiguous whether coordinates are zero-based, whether UTF-16 code units are used, or how malformed positions should fail. Self-explanatory parameter names help slightly, but the LSP-specific conventions are undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Trigger auto-completion at the cursor position' and clarifies the result with 'Returns identifiers available in the current scope.' It distinguishes itself from text-search and hover tools by noting local bindings that would not appear in a simple text search. This is clearly a completion tool, not a lookup or navigation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The analogy 'Like pressing Ctrl+Space in an IDE' gives clear context for when to invoke the tool: when the user wants code completion at a specific location. The mention of local bindings also implicitly steers agents away from naive text search. However, it does not explicitly name alternative sibling tools or state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Go to Definition: jump to where the symbol is defined.
Like pressing F12 in an IDE. Returns file URI, line, and column.
Confidence: HIGH. Reliable for locating definitions across files.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | ||
| character | Yes | ||
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it is reliable across files and states the return format (file URI, line, column). However, it does not mention error cases, prerequisites (e.g., file must be open), or any side effects, which for a read-like operation is a minor gap but still leaves some uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. The analogy and confidence note are efficient and add value without bloat. The sentence order is logical, moving from action to analogy to output to confidence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description covers the core action and output, but it omits parameter semantics and any caveats about LSP state (e.g., need for initialization). Given the tool has an output schema, return format is partly handled, but the missing parameter explanation leaves a notable gap for a 3-parameter tool with 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what file_path, line, and character represent. It implies they are coordinates by mentioning return line/column, but never states that these parameters specify the symbol's location. An agent must infer their meaning from context, which is insufficient given no schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'jump to' and resource 'definition', and adds the analogy 'Like pressing F12 in an IDE' which makes the intent unambiguous. It doesn't explicitly contrast with siblings like lsp_references, but the definition vs references distinction is implicit and clear enough for an agent to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need a definition) via the F12 analogy, but provides no explicit guidance on when not to use it or mention of alternatives like lsp_references or lsp_hover. It leaves the selection to inference, which is adequate but not proactive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get diagnostic messages (errors, warnings) from the language server.
When to use: After lsp_change to check for errors, like IDE real-time linting. Also useful before finishing a task to ensure no errors were introduced.
Why this matters for Scheme: S-expressions are catastrophically sensitive to
bracket balance. A single missing or extra parenthesis can render the entire file
unparseable. Diagnostics will catch unmatched brackets, tokenizer errors, and
structural syntax failures with high reliability — things LLMs often miss by eye.
scheme-langserver 2.1.2+ restored clear bracket-mismatch diagnostics
(unclosed parenthesis, unexpected close bracket) in the fault-tolerant tokenizer.
Always pull diagnostics after significant edits.
Confidence: HIGH for basic syntax (brackets, undefined ids). MEDIUM/LOW for semantic errors and implementation-specific extensions (Chez-specific forms may be falsely flagged).
Args: file_path: If provided, returns diagnostics for that file only. If omitted, returns diagnostics for all open files.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden — and it delivers richly. It discloses confidence levels per diagnostic class (HIGH for syntax, MEDIUM/LOW for semantics), explains the bracket-mismatch behavior and the scheme-langserver version dependency, and warns about false positives for Chez-specific forms. This is exemplary behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical 'When to use' and parameter semantics are well front-loaded, but the 'Why this matters for Scheme' section is verbose — several sentences of background and version history that could be tightened. Every sentence adds some value, but the description is longer than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with a single optional parameter and an output schema already present, the description is more than complete. It covers the one param exhaustively, the behavioral caveats, confidence, and usage context — nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description fully compensates by explaining the file_path semantics: providing it scopes diagnostics to one file, omitting it returns diagnostics for all open files. This adds meaning the schema alone (just a nullable string) cannot convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get diagnostic messages (errors, warnings) from the language server'), and the LSP-specific context clearly separates it from sibling operations like hover, complete, and definition. Purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section names the sibling lsp_change as the trigger ('After lsp_change to check for errors'), gives a task-completion use case, and ends with a firm directive ('Always pull diagnostics after significant edits'). Usage guidance is complete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the file's symbol outline (functions, variables, macros).
Like the Outline / Structure panel in an IDE.
Confidence: MEDIUM. Symbols generated by macros may be missing.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add a useful behavioral caveat: 'Confidence: MEDIUM. Symbols generated by macros may be missing.' However, it does not disclose preconditions such as requiring LSP initialization or an open file, nor explicitly confirm the read-only nature beyond the verb 'Show.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences plus a bolded confidence note. The main action is front-loaded, the IDE analogy is useful, and every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the output schema exists, so return values are covered. The description gives purpose and a limitation, but omits usage guidance, parameter semantics, and preconditions like initialization or file-open requirements, leaving noticeable gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It only ties file_path to 'the file's' outline, adding minimal meaning; it does not explain path format, whether the file must be open, or how file_path relates to other LSP state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Show the file's symbol outline (functions, variables, macros).' It clearly distinguishes itself from lsp_workspace_symbol by scoping to a single file, so an agent can tell which tool to use without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The analogy to an IDE Outline/Structure panel gives a clear implied use case, but the description never explicitly says when to use this tool versus alternatives like lsp_workspace_symbol, nor does it state any exclusions or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a debug report for scheme-langserver upstream issue reporting.
The report contains the LSP traffic log, open project files, environment info, and server stderr. Review before sharing publicly — it includes source code.
When to use: scheme-langserver crashed or returned clearly wrong results, and you want to help debug by generating a report for the upstream issue tracker (https://github.com/ufo5260987423/scheme-langserver/issues).
| Name | Required | Description | Default |
|---|---|---|---|
| output_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description needed to disclose behavioral traits. It does well by stating that the report includes source code and advises reviewing before sharing publicly, which is a critical behavioral warning. It doesn't cover all possibilities (e.g., output format or potential side effects), but the main privacy concern is highlighted, earning a high score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, with a clear first sentence stating the tool's purpose, followed by a bullet-point list of contents, and a 'When to use' section. It is front-loaded with the core purpose and avoids redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description provides sufficient context for an agent to call the tool correctly. It covers what the report contains and when to use it. Could be more detailed on what happens after export (e.g., where the file is saved if no path is given), but that's minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on the output_path parameter beyond what the schema provides, and the schema coverage is 0%, so the description carries the burden. However, the parameter is optional and simple, and the description implies an output file is needed. With a single optional parameter, the description adds minimal meaning, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to export a debug report for upstream issue reporting. It lists the specific contents (LSP traffic log, open project files, environment info, server stderr) and provides a context for use (after a crash or wrong results). This distinguishes it from sibling tools that perform LSP operations, not reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'When to use' section that explicitly states the scenario: when the LSP server crashed or produced clearly wrong results, and the user wants to help debug upstream. It also mentions the issue tracker URL, which guides the agent on where the report is intended. This is explicit guidance that sets it apart from other LSP tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show hover tooltip (type, docs) for the symbol under the cursor.
Like hovering the mouse over an identifier in an IDE.
Confidence: MEDIUM. Type inference is experimental; info about macro-expanded identifiers may be inaccurate. Cross-check with your knowledge.
Args: file_path: Absolute path to the file. line: Zero-based line number. character: Zero-based character (column) position.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | ||
| character | Yes | ||
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a 'Confidence: MEDIUM' and notes that type inference is experimental, with potential inaccuracies for macro-expanded identifiers, advising cross-checking. This is valuable behavioral transparency about reliability, though it doesn't address side effects or prerequisites. It adds meaningful context beyond a simple 'hover' description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The purpose is front-loaded, followed by an analogy, a confidence note, and parameter explanations. Each sentence earns its place; there is no redundancy or filler. The format is easy to parse and act upon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a hover tool, the description covers the essential information: what it does, how to specify the location, and reliability caveats. An output schema exists, so return values are not required. It could mention prerequisites like needing an active LSP session or open file, but these are implied by sibling tools. The description is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an 'Args' section that explains each parameter: file_path as absolute path, line as zero-based, character as zero-based. This fully compensates for the schema's lack of descriptions, providing the agent with precise meaning for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Show hover tooltip (type, docs) for the symbol under the cursor.' This is a specific verb+resource that distinguishes it from siblings like lsp_definition or lsp_signature. The IDE analogy reinforces the purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The analogy 'Like hovering the mouse over an identifier in an IDE' provides clear context for when to use the tool. However, it does not explicitly mention alternatives or exclusions, such as when to use lsp_definition or lsp_references instead. The guidance is clear but lacks explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize the scheme-langserver connection.
Must be called before any other LSP tool. Provides the project root directory so the language server can resolve imports and analyze the codebase.
Args: root_dir: Project root directory. langserver_path: Optional path to a specific scheme-langserver executable. If provided, it overrides environment variables and project config. This is useful for switching between scheme-langserver builds at runtime, e.g. when debugging a local development build.
| Name | Required | Description | Default |
|---|---|---|---|
| root_dir | Yes | ||
| langserver_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the effect (provides project root for import resolution) and the override behavior of langserver_path. It does not address idempotency or behavior after shutdown, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured intro, lifecycle note, and Args block. Every sentence earns its place, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return values are covered. All parameters are explained and the ordering requirement is stated. Minor edge cases like path format or re-initialization behavior are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains root_dir as the project root directory and langserver_path with detailed override semantics (overrides env vars/project config, useful for switching builds).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Initialize the scheme-langserver connection.' It also adds that it must be called before any other LSP tool, which clearly distinguishes it from all sibling tools and establishes its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Must be called before any other LSP tool,' giving a clear when-to-use directive. It doesn't mention when not to use (e.g., if already initialized) or differentiate from lsp_restart, so it's not fully complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a file in the language server (like opening a tab in an editor).
The server needs to know file contents before it can provide hover, completion, or diagnostics for that file.
When to use: When you start working on a Scheme file. Keep the file open for the duration of the session; do NOT open and close repeatedly.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| language_id | No | scheme |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the rationale (server needs file contents) and gives a behavioral rule (keep open for session). Yet it does not disclose side effects, failure modes, or behavior on repeated opens, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action, followed by a brief rationale and usage guidance. Each sentence earns its place; no redundant content exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits prerequisites like calling lsp_initialize first and how it fits into the lifecycle. It does not explain return values, though an output schema exists. It provides session context but misses setup dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain file_path or language_id beyond schema titles. The mention of 'Scheme file' hints at the default language_id, but it does not clarify the parameters' purpose or usage, failing to add value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Open a file in the language server', with an editor tab analogy that makes the action intuitive. It implicitly distinguishes from siblings like lsp_close and lsp_change by focusing solely on the opening action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use ('When you start working on a Scheme file') and when not to ('do NOT open and close repeatedly'). However, it does not name alternative tools (e.g., lsp_change for edits, lsp_close for cleanup), so the guidance is clear but lacks explicit sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find All References: list every usage of the symbol across the workspace.
Like Shift+F12 in an IDE.
Confidence: HIGH. Reliable for assessing impact before refactoring.
Args: include_declaration: Whether to include the definition site in the results.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | ||
| character | Yes | ||
| file_path | Yes | ||
| include_declaration | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It states the tool is workspace-wide, has HIGH confidence, and is reliable for refactoring impact, which is useful context. It does not explicitly mention side effects, read-only behavior, or any server initialization prerequisites, though 'find references' strongly implies a non-mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loads the core behavior, and uses a helpful IDE analogy. The confidence note and the one parameter explanation earn their place, though the Args section is slightly redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, a use case, and one optional parameter, and an output schema exists. However, it omits explanations for the required position arguments and does not mention expected file-path or coordinate formats, so an agent may not correctly construct the primary invocation without external LSP knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains include_declaration, while the three required positional parameters file_path, line, and character receive no semantic explanation in either the schema or description. This is a meaningful gap for an LSP tool where coordinate semantics matter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'list every usage of the symbol across the workspace.' It clearly conveys what the tool does and the IDE analogy reinforces intent. It does not explicitly contrast itself with siblings such as lsp_definition or lsp_workspace_symbol, but its 'references/every usage' language makes the distinction fairly inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: it is like Shift+F12 and is reliable for assessing impact before refactoring. It does not explicitly state when not to use it compared with lsp_definition or lsp_workspace_symbol, but the refactoring-impact use case is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute workspace edits to rename a symbol.
Returns a set of text document edits that can be applied to safely rename the symbol across all files.
Limitation: rename is on the scheme-langserver roadmap and may return -32601 "method not found". If so, fall back to manual renaming.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | ||
| new_name | Yes | ||
| character | Yes | ||
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the tool returns edits rather than applying them directly, and it honestly flags the limitation that the server may return -32601 and suggests manual fallback. This is strong behavioral disclosure for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with the core purpose front-loaded, followed by the return behavior and a critical limitation. Every sentence earns its place, and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, output, and a key failure mode, but it omits important context such as whether the language server must be initialized, whether the target file must already be open, or whether line/character are zero-based. For an LSP operation with dependencies on sibling tools like lsp_initialize and lsp_open, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with four required parameters, and the description adds no parameter detail. It never explains line/character coordinate semantics or how file_path and new_name interact. The description must compensate given the low schema coverage, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'compute workspace edits to rename a symbol.' It also differentiates itself by explaining the result is a set of edits across all files, which distinguishes it from browsing tools like lsp_references or lsp_definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when renaming a symbol, and the returned edits can be applied to perform the rename. It does not explicitly compare against alternatives, but the purpose is clear enough that an agent can infer when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart the scheme-langserver connection and reopen tracked documents.
Use this when you want scheme-langserver to pick up configuration changes
(e.g. a new cache_path), switch to a different executable, or recover
from a stuck server. After restarting, all currently open files are
re-opened automatically so the server state is restored.
Args: root_dir: Project root directory. If omitted, the previously used root_dir is reused; if there is none, it is inferred from open documents or the current working directory. langserver_path: Optional path to a specific scheme-langserver executable. If provided, it overrides environment variables and project config. This lets you instantly switch to a local build for debugging or comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| root_dir | No | ||
| langserver_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing that open documents are reopened automatically, root_dir fallback behavior, and langserver_path override behavior. It does not mention potential side effects like lost server state or in-flight requests, but it covers the main state-changing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the purpose, followed by use cases, behavioral effects, and parameter details. Every sentence adds useful information without padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, parameter semantics, and post-restart behavior, and an output schema exists so return details are unnecessary. It is slightly missing guidance on edge cases such as whether a server must already be initialized, but overall it gives an agent enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining both parameters in detail: root_dir's reuse/inference fallback and langserver_path's override of environment variables and project config. This adds meaningful semantics far beyond the bare parameter names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence explicitly states the action: 'Restart the scheme-langserver connection and reopen tracked documents.' This goes beyond a tautology by naming the specific resource and secondary behavior, and it is clearly different from sibling tools like lsp_initialize or lsp_shutdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: pick up configuration changes, switch executables, or recover from a stuck server. It does not explicitly name alternatives or when-not-to-use cases, but the stated conditions are concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gracefully shut down the scheme-langserver connection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only adds 'gracefully.' It does not state that the connection becomes unusable afterward, whether shutdown is idempotent, or that a later lsp_initialize is required to resume work.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler, and the key verb and resource appear upfront. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters) and has an output schema, so the description does not need to document return values. However, it leaves lifecycle context unstated—no mention of shutdown being terminal or how it relates to lsp_initialize/lsp_restart—so a fully self-sufficient agent would need to infer behavior from LSP conventions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema properties object is empty, so there is nothing for the description to clarify beyond the schema. The baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb ('shut down') and target ('the scheme-langserver connection'), with 'gracefully' adding manner. It does not explicitly contrast with lsp_restart or lsp_initialize, so the agent must infer lifecycle boundaries largely from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement of when shutdown should be used instead of lsp_restart or lsp_initialize, and no warning about prerequisites. The only context is the word 'gracefully,' which implies finality but does not provide explicit selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get signature help for a function call.
Shows parameter names and types for the function being called at the given position.
Limitation: signatureHelp is on the scheme-langserver roadmap and may return -32601 "method not found". If so, fall back to your own knowledge.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | ||
| character | Yes | ||
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden, and it does so well by explicitly warning that signatureHelp is on the scheme-langserver roadmap and may return -32601 'method not found'. This is a valuable behavioral trait that an agent needs to handle gracefully. It does not discuss side effects, but as a read-only LSP query that is a minor omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by a single, clearly marked limitation. Every sentence earns its place, and the fallback instruction is easy to notice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and a key limitation, and an output schema exists to explain return values. However, the parameter semantics gap and lack of positional details make the tool not fully self-contained for correct invocation, especially given no annotations are available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining file_path, line, and character semantics. It only mentions 'at the given position', which does not explain coordinate bases, whether positions are zero-based, or how the file_path locates the document. The parameter names are self-evident but not sufficiently documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get signature help for a function call.' It goes further by stating what the tool shows ('parameter names and types'), making its purpose unambiguous. This clearly distinguishes it from sibling tools like lsp_hover or lsp_complete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied from the purpose: call this when a function call is being made and signature details are needed. However, there is no explicit guidance on when to prefer this over alternatives such as lsp_hover or lsp_complete, and no when-not-to-use conditions besides the error fallback note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search symbols across the entire workspace.
Like Ctrl+T / Go to Symbol in an IDE. Returns all symbols matching the query string across all indexed files.
Confidence: MEDIUM. Accuracy depends on index completeness. Requires scheme-langserver >= 2.1.0.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well by disclosing confidence level, dependence on index completeness, and a version requirement. It also describes the returned behavior ('all symbols matching the query string'). It does not mention failure modes or prerequisites beyond the version, but the provided context is genuinely useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line purpose, a helpful analogy, a summary of behavior, and two critical operational caveats. Each sentence adds distinct value and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the core purpose, behavior, confidence, and a version requirement. The main missing piece is explicit routing relative to lsp_document_symbol, and whether an initialized LSP session is required, but the overall context is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'query' parameter with 0% description coverage, so the description must compensate. It only says the query is a 'query string' and that symbols 'matching' it are returned, which adds minimal meaning beyond the schema's bare property name. No format, case-sensitivity, wildcard, or matching semantics are documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and a clear resource ('symbols across the entire workspace'), and contrasts with lsp_document_symbol by emphasizing workspace-wide scope. The Ctrl+T / Go to Symbol analogy reinforces the intent and makes the tool immediately recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use this to find symbols workspace-wide, like an IDE's Go to Symbol. It does not explicitly name lsp_document_symbol as the alternative or state when not to use it, but the 'across all indexed files' phrasing implies the workspace-vs-document distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0lsp_changelsp_closelsp_code_actionlsp_completelsp_definitionlsp_diagnosticslsp_document_symbollsp_export_debug_reportlsp_hoverlsp_initializelsp_openlsp_referenceslsp_renamelsp_restartlsp_shutdownlsp_signaturelsp_workspace_symbolScored across 17 tools
Each tool maps to a distinct LSP operation or lifecycle event, so there is no meaningful overlap: open/change/close manage document state, hover/complete/definition/references/signature query different perspectives, and document_symbol vs workspace_symbol are explicitly scoped to file vs workspace. The few related pairs are differentiated clearly by name and description.
All 17 tools follow the same lsp_ snake_case prefix and mostly mirror standard LSP method names, making the set predictable and easy to navigate. Even though some names are nouns rather than verb_noun phrases, the convention is uniform across the whole server.
17 tools is at the upper end of comfortable scope, but nearly every one corresponds to a distinct LSP feature or lifecycle step needed by a language-server bridge. The count feels justified rather than bloated; it is only slightly above the typical well-scoped range.
The set covers the full editing loop: initialize, open/change/close documents, query symbols/references/hover/completion, and fetch diagnostics, plus shutdown/restart and troubleshooting. Minor gaps remain (e.g., formatting, document highlighting) and a few exposed features (rename/signature/code_action) are documented as possibly unsupported by the server, but there are no critical dead ends for the core workflow.
Lean 4 MCP server: compile, prove theorems, and formalize math with Mathlib.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The official Svelte MCP server providing docs and autofixing tools for Svelte development
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
