nvim-mcp

by paulburgess1357

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.0
Disambiguation5/5
All tools have clearly distinct purposes: highlights have separate add/clear, reading has range/full, state has full/brief, editing has targeted replace/full rewrite, diagnostics have single/all, and commands/keys are distinct. No ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., clear_highlights, read_buf_range, send_command). No mixing of conventions.
Tool Count5/5
14 tools is well within the ideal 3-15 range for a Neovim control server. Each tool serves a necessary function without bloat.
Completeness5/5
The tool surface covers all core Neovim interactions: connection, state inspection, diagnostics, buffer reading/writing, text editing, highlights, and command/keystroke execution. No obvious gaps.
Average 4.9/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on August 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses all relevant behaviors: only removes MCP highlights, no buffer content modification, safe when no highlights are present, returns a success object, and errors if the buffer is not open. This fully compensates for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs with no wasted words. The first paragraph covers the core purpose and safety, the second covers the parameter. It is front-loaded with the key action. Minor redundancy could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description covers the return value, error condition, and relationship to sibling tools. It is nearly complete; a minor gap is not detailing the error format for non-open buffers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds essential meaning: 'file' must be a path relative to Neovim's cwd, must correspond to an open buffer (as shown in `get_state`), and returns an error otherwise. This goes beyond the raw schema but could be slightly more detailed (e.g., mentioning it is a string).
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?
The description states: 'Remove all MCP highlights from a Neovim buffer.' It uses a specific verb and resource, and distinguishes from syntax/LSP highlights, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this to clean up highlights after an annotation workflow' and specifies it only removes highlights added by `highlight_range` or `highlight_ranges`, providing clear usage context. It does not explicitly list alternatives but sibling tools imply them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It explains highlights stack, no persistence, line clamping/swapping, color handling. Lacks mentions of permissions or side effects, but for a non-destructive tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: purpose first, then parameter details, usage alternatives, return value. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (3 required) and no output schema, description explains return value (highlighted count or error). Sufficient for a highlight tool, though missing limits or performance notes.
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 coverage is 0% (only titles and types given). Description adds path context, indexing, clamping behavior, color defaults and error conditions, significantly enriching parameter understanding.
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?
The description clearly states 'Add a colored line highlight to a Neovim buffer' and distinguishes it as a visual-only annotation. It differentiates from siblings by mentioning highlight_ranges and clear_highlights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies when to use highlight_ranges (multiple highlights) and clear_highlights (removal). It notes the buffer must be open. No explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explicitly states 'Read-only — does not modify any editor state' and details conditional return fields (alternate_window, terminals). It also calls itself 'lightweight,' which adds performance context. However, it does not mention potential edge cases or error conditions, leaving a slight gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into purpose, usage, and return details. It is not overly long for the information it conveys, and each sentence earns its place. The format is scannable, with clear sections, though it could be tightened slightly.
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?
With no output schema, the description fully specifies the return structure, including nested fields, conditional additions, and the meaning of each key. It also covers the tool's role in the broader context, making it complete for both invocation and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema is empty and inherently 100% covered. The description appropriately focuses on return value semantics rather than parameters, hitting the baseline 4 for a no-parameter tool.
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?
The description clearly states a specific action: 'Lightweight snapshot of the Neovim session for quick orientation.' It also distinguishes itself from the sibling tool `get_state` by positioning this as the 'brief' version, making the tool's purpose and scope explicit.
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?
The description explicitly says to 'Use this at the start of each turn' and provides an alternative: 'Use `get_state` instead when you need the full picture.' This gives clear when-to-use and when-not-to-use guidance, with a named sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully compensates. Discloses what it removes/doesn't remove, that it doesn't modify buffer content, idempotency, return value, and error condition for non-open buffer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs: first covers purpose and scope in three sentences, second explains the parameter. Every sentence adds necessary information.
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?
Given simple tool (one param, no output schema), description covers all aspects: purpose, parameter, return value, error condition, and safe usage. No gaps.
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 has 0% description coverage, but description fully explains the 'file' parameter: path relative to cwd, reference to get_state, and requirement that buffer must be open.
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?
Clearly states verb 'Remove' and resource 'MCP virtual text annotations from a Neovim buffer'. Distinguishes from siblings by specifying it only removes annotations added by add_virtual_text or add_virtual_texts, not affecting highlights, LSP, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to clean up after an annotation workflow' and references sibling tools for adding. States it's safe to call even with no annotations. Could be more specific about when not to use (e.g., use clear_highlights for highlights), but overall clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses edit is in-memory, undoable, not written to disk until user saves, and creates buffer if missing. Could mention error handling but overall very transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs, front-loaded with core purpose. Every sentence provides value: purpose, behavior, usage guidance, parameter descriptions, and return value. No redundancy.
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?
Despite no output schema and simple 2-param input, the description covers purpose, behavior, usage, parameters, and return structure ({total_lines}). Sufficiently complete for agent invocation.
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 description explains 'file: path relative to Neovim's cwd (as shown in get_state buffers)' and 'content: the full new text for the buffer.' Adds essential context beyond schema types.
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?
Clearly states 'Replace the entire content of a Neovim buffer' with specific verb and resource. Differentiates from sibling by contrasting with find_and_replace_buf.
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?
Explicitly says when to use this tool (rewrite whole file) and when to use alternative (find_and_replace_buf for targeted edits). Provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Fully discloses auto-connect logic, error conditions (no instances, timeout, bad index), and return structure. No annotations present, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points, but slightly longer than minimal. Still every sentence adds value and front-loaded with main purpose.
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?
Covers all necessary aspects: prerequisites (call first), behavior (auto-connect, selection), return values on success/failure, despite no annotations or output schema.
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 has 0% coverage (only titles), but description adds semantics for each parameter: index meaning 1-based, socket path as Unix or host:port, terminal_pid as process tree lookup.
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?
Clearly states 'Connect to a running Neovim instance' with specific transport methods. Distinguishes from sibling tools like read/write/send commands.
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?
Explicitly says 'Call this before any other tool' and explains when to call with no arguments vs. with selection parameters. Also notes connection is persistent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses in-memory editing, undoability, no disk write until user saves, buffer creation, exact match requirement (error if not found or multiple), and return value structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with summary, parameter details, guidelines, and return value. Slightly verbose but each sentence serves a purpose.
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?
Covers all necessary aspects: purpose, parameter semantics, behavioral traits, return format, and usage alternatives. No gaps given the tool's complexity and lack of annotations.
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?
Adds full context for all three parameters: file path relative to cwd, old_string exact match constraints with disambiguation advice, and new_string as replacement. Schema has 0% coverage, description compensates completely.
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?
Clearly states 'Find and replace text in a Neovim buffer' and distinguishes from siblings by mentioning write_full_buf for full replacement and read_full_buf/read_buf_range for viewing content.
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?
Provides explicit guidance: use for targeted edits, alternatives for full buffer replacement, and recommends reading first. Also explains undoability and disk persistence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return structure, severity levels, empty list case, and dependencies on LSP servers and open buffers. With no annotations, the description fully carries the burden of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences are perfectly front-loaded: what it does, when to use, and what it returns. No wasted words.
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?
Covers purpose, usage alternatives, behavioral dependencies, and return format comprehensively. Without an output schema, the description provides all necessary context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% trivially. Description adds no parameter info but is not required; the return format is explained. Baseline for 0 params is 4.
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?
The description clearly states that the tool retrieves LSP diagnostics from all open buffers, and contrasts with the sibling get_buf_diagnostics by specifying scope. The verb 'get' and resource 'all LSP diagnostics' are specific and 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?
Explicitly recommends use for project-wide overview and advises using get_buf_diagnostics for a specific file to get more focused data. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It opens with 'Read-only — does not modify any editor state,' which is a clear and explicit safety declaration. It then details the return structure comprehensively, including optional fields and their conditions, providing transparency about what the agent can expect without any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, front-loaded with purpose and usage, then organized by logical sections (windows, per-window fields, optional fields). Each sentence provides necessary detail about what the tool returns, and the formatting with headings and bullet-like lists enhances scannability without redundancy.
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?
Since there is no output schema, the description must fully explain the return values. It does so exhaustively, covering top-level fields, per-window subfields, and optional fields with their shapes. It also explains relationships (e.g., active window first, alternate second) and conditions (e.g., terminals only present when at least one exists), making the tool completely self-contained for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so there are no parameter semantics to explain. The baseline for 0 parameters is 4. The description does not discuss inputs because none exist; it focuses on output, which is appropriate for a parameterless getter.
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?
The description begins with 'Full snapshot of the current Neovim session,' using a specific verb ('snapshot') and resource ('Neovim session'). It clearly distinguishes this from the sibling 'get_state_brief' by stating that this tool provides the complete picture, including all window details, folds, marks, diagnostics, etc.
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?
The description provides explicit usage guidance: 'Use get_state_brief for quick orientation at the start of a turn. Use this when you need the complete picture.' This directly contrasts with an alternative, making the selection criteria clear. It also notes that the terminals field is a target for send_to_terminal, giving additional context for when this tool may be useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses: visual annotation only, no modification or persistence, stacking behavior, error handling for unknown colors and missing keys, and clamping of out-of-range lines. Also mentions return format and error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with separate sections for purpose, parameter details, usage guidance, return info, and example. Not overly long, but the parameter details could be slightly more concise (e.g., bullet points). Still highly efficient.
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?
Given complexity (nested objects with 4 keys) and presence of output schema, description covers all needed: purpose, parameter semantics, usage guidelines, behavioral traits, error handling, and example. Complete for correct tool invocation.
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 coverage is 0%, but description fully documents the 'highlights' parameter: structure of each dict (file, start_line, end_line, optional color with default and error behaviors), and includes an example. Adds meaning beyond the minimal schema.
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?
The description clearly states it adds colored line highlights to one or more Neovim buffers in a single call. It distinguishes from sibling tools 'highlight_range' (single range) and 'clear_highlights' (removing). The verb and resource are specific.
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 guidance: 'Use this when you need to highlight several ranges at once (possibly across different files).' Also provides alternatives: 'Use highlight_range for a single range. Use clear_highlights to remove all highlights.' Clear when to use and when not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: annotations stack, buffer must be open, line clamping, text constraints per position, and error conditions for unknown colors and missing buffer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: purpose upfront, visual-only note, parameter details, sibling references, and return value. Every sentence adds value with no redundancy.
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?
Given no output schema and no annotations, the description covers all aspects: parameter behavior, error handling, stacking, and return format. It is sufficiently complete for an agent to use the tool correctly.
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?
Despite 0% schema coverage, the description explains each parameter in detail: file path relative to cwd, line indexing and clamping, text array constraints, position options with default, and color type with default and error handling. This adds significant meaning beyond the schema.
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?
The description clearly states the tool adds a virtual text annotation to a Neovim buffer, emphasizing it is visual-only and does not alter the buffer's content. It explicitly distinguishes from siblings like add_virtual_texts and clear_virtual_texts.
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?
The description provides explicit guidance on when to use this tool vs alternatives: 'Use this for a single annotation. Use add_virtual_texts for multiple annotations in one call. Use clear_virtual_texts to remove all MCP virtual text from a buffer.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly discloses behavioral traits: visual only, stacking behavior, clamping of out-of-range lines, position options, color behavior (including error on unknown names), and the critical fact that partial application occurs on failure with rollback via clear_virtual_texts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: purpose first, then structured parameter breakdown, then usage guidance and example. Every sentence adds value; no redundancy or fluff.
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?
Given the tool's complexity (multiple items, nested fields, side effects), the description covers input format, constraints, error handling, return format, and partial application behavior. It is complete and leaves no ambiguity.
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?
With 0% schema description coverage, the description fully compensates by detailing each field in the items list, including required vs optional, types, defaults, and a concrete example. This adds significant meaning beyond the minimal schema.
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?
The description clearly states the tool adds multiple virtual text annotations to Neovim buffers in a single call, and explicitly distinguishes it from sibling tools (add_virtual_text for single, clear_virtual_texts for removal).
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?
Provides explicit guidance on when to use this tool ('when you need to add several annotations at once') and when to use alternatives, including direct references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares read-only nature, precondition (buffer must be open), and describes return format including severity levels. Fully transparent without annotation reliance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise 5-sentence description with front-loaded purpose. Every sentence adds value: purpose, read-only, parameter semantics, usage guidelines, return format.
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?
Covers all necessary aspects for a simple tool: purpose, usage, parameter semantics, return format with severity values, error condition. No gaps despite no output schema.
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?
Adds crucial context beyond schema: 'file path relative to Neovim's cwd (as shown in `get_state` buffers). The buffer must already be open; returns an error otherwise.' Schema has 0% coverage, so description compensates fully.
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?
Description clearly states it gets LSP diagnostics for a single Neovim buffer, distinguishing it from the sibling 'get_all_diagnostics' by specifying 'single' vs 'project-wide'. Verb and resource are explicit.
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?
Explicitly provides guidance: 'Use this when you need diagnostics for one specific file. Use `get_all_diagnostics` instead for a project-wide overview.' Also states buffer must be open.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior. It discloses read-only nature, reads from in-memory buffer, file path relative to Neovim's cwd, clamping of out-of-range values, swapping of start_line > end_line, and return format {lines, total_lines} with line-number prefix.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
124-word description is concise and well-structured. Purpose and behavior first, then parameter details, usage guidance, and return format. Every sentence provides unique value without redundancy.
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?
Despite no output schema, description includes return fields and behavior. Covers edge cases (clamping, swapping) and prerequisites (buffer must be open). Complete for a 3-parameter read tool.
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 coverage is 0%, so description adds full meaning. It explains 'file: path relative to Neovim's cwd... must be open', 'start_line: first line to read (1-indexed, inclusive)', 'end_line: last line... clamped, swapped if needed'. This goes far beyond bare schema.
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?
Description clearly states 'Read a specific line range from a Neovim buffer,' specifying verb (read), resource (Neovim buffer), and scope (line range). It distinguishes from sibling 'read_full_buf' by noting when to use each.
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?
Explicitly says 'Use this when you only need a section of a file. Use read_full_buf instead when you need the entire buffer.' Also warns that the buffer must be open in Neovim and reads from in-memory buffer, which may differ from disk.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description thoroughly covers behavior: read-only, reads from in-memory buffer (may differ from disk), returns error if buffer not open, and describes return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured. Main action front-loaded, then details in separate sentences. Every sentence adds value without redundancy.
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?
No output schema, but description fully explains return format (lines, total_lines with line numbers). Covers all behavioral aspects, constraints, and context. No gaps.
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?
Only one parameter 'file' with 0% schema description coverage. Description adds critical meaning: path relative to Neovim's cwd, must be open, error otherwise. Fully compensates for schema gap.
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?
Clearly states 'Read the full content of a Neovim buffer' with specific verb and resource. Distinguishes from sibling 'read_buf_range' by specifying when to use each.
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?
Explicitly says 'Use this when you need to see the entire file. Use read_buf_range instead when you only need a specific section.' Also notes the buffer must be open in Neovim.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses that it is a mutation tool that can modify buffers, files, windows, and editor state. It also explains error handling and list execution behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into paragraphs, front-loading the purpose, then parameter details, usage guidance, and return format. Every sentence adds value without redundancy.
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?
Given the single parameter and existence of an output schema, the description covers all necessary aspects: command syntax, mutation behavior, usage context, and return format (output or error, list support).
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?
Although schema coverage is 0%, the description thoroughly explains the 'command' parameter: it can be a string or list of strings, without leading ':', with concrete examples like 'w', 'e src/main.py', 'wincmd v'.
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?
The description opens with 'Run one or more Vim ex commands in Neovim,' which clearly specifies the action and resource. It further distinguishes itself from sibling tools by naming dedicated alternatives for buffer edits and normal-mode motions.
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?
It explicitly states when to use this tool ('for editor operations that don't have a dedicated tool') and when to use alternatives like send_keys or find_and_replace_buf, noting that the latter are safer and provide undo.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that Esc is prepended, multi-mode sequences must be sent in a single call, and keystrokes are fire-and-forget with errors not captured. No annotations exist, but the description fully covers behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with separate paragraphs for purpose, parameter details, usage guidelines, and return value. Every sentence adds value without redundancy.
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?
Given the single parameter and no output schema, the description covers all essential aspects: purpose, usage, parameter semantics, behavior, and return value. It is complete and self-contained.
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?
The only parameter 'keys' is thoroughly explained: format, automatic Esc prepend, special key notation, and multi-mode constraints. Schema coverage is 0%, but the description adds all necessary semantic detail.
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?
The description clearly states it sends raw keystrokes to Neovim, identifies it as a mutation tool, and distinguishes it from siblings like send_command and find_and_replace_buf.
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?
Explicitly specifies when to use this tool (normal-mode motions, visual selections, operator sequences) and when not to, with named alternatives (send_command, find_and_replace_buf, write_full_buf).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral transparency burden. It discloses that this is a mutation tool, explains under what conditions text is executed versus merely placed at the prompt, notes newline stripping when submit is false, describes terminal-target matching fallback to error with a list, and reports the exact return shape on success and failure. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place. It is front-loaded with the core action, then organized by parameter, then usage guidance, then return values. No redundant phrases or filler; the length is justified by the safety-critical nature and need for precise behavioral nuance.
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?
Given the tool has no annotations and no output schema, the description is remarkably complete. It covers mutation risk, execution control, parameter disambiguation, error behavior, and return values. It even anticipates ambiguities like multiple terminals and safety-critical submit semantics, making it sufficient for an agent to invoke correctly in varied contexts.
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%, but the description compensates thoroughly. It explains the 'text' parameter with newline and execution semantics, 'terminal' with matching rules and omission behavior, and 'submit' with defaults, execution implications, and explicit safety rules. This is far more useful than any schema description could be.
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?
The description opens with a specific verb+resource: 'Type text into a terminal buffer's running program' and immediately distinguishes it from siblings by noting it writes via the job channel, unlike send_keys or buffer edit tools. This clearly identifies what the tool does and how it differs from alternatives.
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?
The description explicitly states when to use the tool ('Use this whenever text needs to go into a terminal') and gives direct exclusions: 'unlike send_keys' and 'Terminal buffers cannot be edited with the buffer tools.' It also provides strong safety guidance about submit=false vs submit=true, with concrete examples of when not to use submit=true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![nvim-mcp MCP server](https://glama.ai/mcp/servers/paulburgess1357/nvim-mcp/badges/card.svg)](https://glama.ai/mcp/servers/paulburgess1357/nvim-mcp)

Score Badge

Copy to your README.md:

[![nvim-mcp MCP server](https://glama.ai/mcp/servers/paulburgess1357/nvim-mcp/badges/score.svg)](https://glama.ai/mcp/servers/paulburgess1357/nvim-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/paulburgess1357/nvim-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server