scheme-langserver-bridge

Overview Schema Source Related Servers Discussions Admin

lsp_diagnostics

Retrieve syntax errors and warnings for Scheme code. Use after edits to catch unmatched brackets and structural issues, for a specific file or all open files.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`file_path`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server