mcp-neovim-server

by bigcodegen

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific Neovim operations like buffer management, editing, navigation, and system control. There is no overlap or ambiguity; for example, vim_search handles searching within a buffer while vim_grep handles project-wide searches, and vim_buffer_switch is distinct from vim_tab or vim_window for navigation.
Naming Consistency5/5
All tools follow a consistent 'vim_' prefix with descriptive snake_case names that clearly indicate their function, such as vim_buffer_save, vim_command, and vim_search_replace. This uniform pattern makes the tool set predictable and easy to understand, with no deviations in style or structure.
Tool Count4/5
With 19 tools, the count is slightly high but reasonable for covering the broad scope of Neovim operations, including editing, navigation, file management, and system health. It avoids being excessive by focusing on core functionalities without redundant tools, though it might feel heavy compared to simpler servers.
Completeness5/5
The tool set provides comprehensive coverage of Neovim's core features, including CRUD-like operations for buffers, files, and content, as well as navigation, search, macros, marks, and system status. There are no obvious gaps; it supports full lifecycle management from opening files to editing, saving, and navigating, ensuring agents can handle typical workflows without dead ends.
Average 3/5 across 19 of 19 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on September 14, 2025
- 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.
Add a glama.json file to provide metadata about your server.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Manage' is ambiguous about behavior - it doesn't specify if this is a read, write, or both operation. It doesn't disclose whether this tool modifies register contents, what happens to existing register data, or any side effects. For a tool with no annotation coverage, this leaves critical behavioral traits undefined.
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 extremely concise at just 4 words, which is efficient. However, this brevity comes at the cost of clarity - 'Manage' is too vague. The structure is front-loaded but under-specified rather than appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a vague description, this is incomplete for a tool that presumably modifies Neovim register state. The description doesn't explain what 'manage' means operationally, what the tool returns, or how it interacts with the Neovim environment. For a tool with 2 required parameters and potential side effects, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (register and content). The description adds no additional meaning beyond what's in the schema - it doesn't explain register semantics in Neovim context, what happens when content is provided, or how registers are used. Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Manage Neovim register contents' states the general purpose (managing register contents) but is vague about what 'manage' entails - it could mean read, write, delete, or list operations. It distinguishes from siblings like vim_buffer or vim_command by focusing on registers, but doesn't specify the exact action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With siblings like vim_buffer (for buffer operations) and vim_macro (for macro recording), there's no indication of whether this tool is for storing text, retrieving register contents, or other register-related tasks. The description offers no context about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what the tool does but doesn't disclose behavioral traits like whether it's read-only, if it requires specific buffer states, what happens with invalid filenames, or how it handles multiple buffers. The description is minimal and lacks operational context.
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 extremely concise (one short phrase) and front-loaded with the core purpose. Every word earns its place, with no wasted text or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that presumably returns buffer contents. It doesn't explain what format the output takes (e.g., text, structured data), how errors are handled, or what 'buffer contents' entails beyond line numbers. For a tool with 1 parameter and no structured safety hints, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the optional 'filename' parameter. The description doesn't add any meaning beyond what the schema provides, such as explaining what 'buffer contents' includes or how line numbers are formatted. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get buffer contents') and what is returned ('with line numbers'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'vim_status' or 'vim_file_open' which might also provide buffer-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'vim_buffer_save', 'vim_buffer_switch', 'vim_edit', and 'vim_file_open', the description doesn't indicate whether this is for viewing current buffers, specific buffers, or how it differs from other buffer-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions saving but doesn't specify if this overwrites files, requires write permissions, handles errors (e.g., if filename is invalid), or confirms success. This leaves gaps in understanding the tool's behavior beyond the basic action.
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 extremely concise—a single, front-loaded sentence that efficiently conveys the core functionality without any wasted words. It directly addresses the tool's purpose in a clear and structured manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a file-saving operation with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, permissions, or what happens on success/failure, which are crucial for an AI agent to use the tool correctly in a Vim context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'filename' clearly documented in the schema as optional and defaulting to the current buffer's filename. The description adds minimal value by restating this but doesn't provide additional context like format requirements or examples beyond what the schema already covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'save' and the resource 'current buffer' or 'specific filename', making the tool's purpose immediately understandable. It distinguishes between saving to the current buffer's filename versus a different filename, though it doesn't explicitly differentiate from sibling tools like vim_buffer or vim_edit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like vim_buffer (which might manage buffers) or vim_edit (which might create/edit files). It lacks context about prerequisites, such as needing an active buffer, or exclusions like not working on read-only files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It doesn't mention whether this operation is safe, what happens if the identifier doesn't exist, whether it changes the current view, or any side effects. The description only states the basic action without behavioral details.
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 a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after switching buffers, what errors might occur, or how to verify the switch succeeded. Given the lack of structured metadata, more behavioral context would be needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the identifier parameter fully. The description adds minimal value by mentioning 'by name or number' which aligns with the schema's union type, but doesn't provide additional syntax, format, or usage details beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('switch') and resource ('buffers') with the mechanism ('by name or number'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like vim_buffer or vim_tab, but the specificity of buffer switching is reasonably distinct within the Vim context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like vim_tab (for tab switching) or vim_window (for window switching). The description states what it does but offers no context about appropriate use cases or prerequisites for buffer switching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It mentions shell command support via '! prefix', which adds some context, but doesn't disclose critical traits like whether commands are read-only or destructive, error handling, execution environment, or output format. This is inadequate for a tool that executes commands, leaving significant gaps in understanding its 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 extremely concise with a single sentence that directly states the purpose and key feature (shell command support). It's front-loaded and wastes no words, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing Vim commands (which can range from safe reads to destructive writes) and the lack of annotations and output schema, the description is incomplete. It doesn't address safety, permissions, or what the tool returns, leaving the agent with insufficient information to use it effectively in context with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'command' parameter with its description. The description adds minimal value by reiterating the command focus and hinting at shell usage, but doesn't provide additional syntax examples, constraints, or semantic context beyond what's in the schema. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Execute') and resource ('Vim commands'), specifying the action. It distinguishes from siblings like vim_edit or vim_search by focusing on raw command execution rather than specific operations, though it doesn't explicitly contrast with tools like vim_buffer or vim_macro that might also involve commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance, mentioning 'optional shell command support' which hints at a use case, but offers no explicit when-to-use rules, prerequisites, or alternatives. It doesn't clarify when to choose this over sibling tools like vim_edit for editing or vim_search for searching, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions the editing modes but fails to explain critical behaviors like whether changes are immediate, if they require saving, error handling for invalid line numbers, or side effects on the buffer state. This leaves significant gaps for a mutation tool.
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 a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes essential details about modes, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, response format, or error conditions, which are crucial for safe and effective use in a Vim editing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no additional meaning beyond what the schema provides, such as examples or edge cases, but doesn't need to compensate for gaps. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Edit buffer content') and specifies the available modes ('insert, replace, or replaceAll'), which distinguishes it from tools like vim_buffer_save or vim_command. However, it doesn't explicitly differentiate from vim_search_replace or other editing-related siblings, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like vim_search_replace or vim_buffer. It lacks context about prerequisites, such as needing an open buffer, and doesn't mention exclusions or complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions opening files into 'new buffers,' which implies creation behavior, but lacks details on permissions, error handling (e.g., if file doesn't exist), side effects (e.g., buffer numbering), or response format. For a tool with no annotation coverage, this leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Open files into new buffers.' It is front-loaded with the core action and target, with zero wasted words. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (file operations in Vim), no annotations, no output schema, and 100% schema coverage for a single parameter, the description is incomplete. It lacks context on error cases, Vim-specific behaviors (e.g., buffer management), and integration with sibling tools. For a tool in a rich Vim environment, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'filename' documented as 'Path to the file to open.' The description adds no additional parameter semantics beyond what the schema provides, such as path format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open files into new buffers' clearly states the action (open) and target (files into new buffers). It distinguishes from siblings like vim_buffer_switch (switching existing buffers) and vim_edit (editing without specifying buffer creation), but doesn't explicitly contrast with all siblings like vim_command or vim_search. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. With siblings like vim_edit (which might open files differently), vim_buffer (managing buffers), and vim_command (executing Vim commands), there's no indication of preferred contexts, prerequisites, or exclusions. Usage is implied only by the tool name and basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'manage code folding' implies mutation operations, it doesn't disclose important behavioral details: whether folds persist across sessions, what happens when creating overlapping folds, whether operations are undoable, or what visual feedback to expect. For a tool with multiple actions including 'delete,' more behavioral context is needed.
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 extremely concise (7 words) and front-loaded with the core purpose. Every word earns its place: 'Manage code folding' establishes scope, and the action list specifies capabilities without redundancy. No wasted words or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters (one required), no annotations, and no output schema, the description is insufficient. It doesn't explain what 'managing' entails operationally, what the tool returns, or how folding integrates with Vim's editing model. The agent would need to guess about important contextual aspects of folding behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description mentions 'create' which implies startLine/endLine parameters, but adds no additional semantic context beyond what the schema provides. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as managing code folding with specific actions (create, open, close, toggle). It distinguishes from sibling tools by focusing on folding operations rather than buffers, commands, searches, etc. However, it doesn't explicitly differentiate from all siblings (e.g., vim_visual might also involve folding).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It doesn't mention prerequisites, when folding is appropriate, or how it relates to other Vim operations. With many sibling tools available, this lack of context leaves the agent guessing about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the quickfix list output, which hints at a read-only operation with structured results, but doesn't clarify permissions, side effects, error handling, or output format details. This is inadequate for a search tool with zero annotation coverage.
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 a single, efficient sentence with zero waste—it directly states the tool's purpose and method. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It mentions the quickfix list but doesn't explain what that entails (e.g., structured results, navigation capabilities). For a search tool in a complex environment like Vim, more context on behavior and output is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional parameter semantics beyond implying project-wide scope, which is already suggested by the schema's default filePattern. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Project-wide search using vimgrep with quickfix list', which specifies the verb (search), resource (project files), and method (vimgrep with quickfix). It distinguishes from siblings like 'vim_search' by mentioning the vimgrep method and quickfix output, though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like 'vim_search' or other sibling tools. It mentions the method (vimgrep) but doesn't explain when this is preferable or what contexts it's designed for, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but lacks critical behavioral details: it doesn't specify if this requires an active Neovim instance, what happens if no jumps exist (e.g., error behavior), whether it's read-only or modifies state, or what the output looks like (especially for 'list' direction). For a navigation tool with zero annotation coverage, this is insufficient.
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 perfectly concise and front-loaded in a single sentence that captures the core functionality. Every word earns its place: 'Navigate' sets the action, 'Neovim jump list' specifies the resource, and 'go back, forward, or list jumps' enumerates the options. There's zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (navigation in an editor context), no annotations, no output schema, and 100% schema coverage, the description is incomplete. It adequately states the purpose but fails to provide necessary behavioral context (e.g., state modification, error handling) or usage guidance. For a tool interacting with Neovim's state, more completeness is needed to help the agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'direction' fully documented in the schema with enum values and description. The description adds no additional parameter semantics beyond implying the three actions map to the enum values. This meets the baseline of 3 when the schema does the heavy lifting, but the description doesn't compensate with extra context like format details or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Navigate') and resource ('Neovim jump list'), specifying the three actions available (go back, forward, or list jumps). It distinguishes this tool from siblings like vim_buffer or vim_command by focusing on jump list navigation rather than buffer management or command execution. However, it doesn't explicitly differentiate from vim_mark (which might involve similar navigation concepts), keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It doesn't mention prerequisites (e.g., needing an active Neovim session), when not to use it, or how it relates to sibling tools like vim_buffer_switch for buffer navigation or vim_search for search-based movement. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 lists the actions but doesn't explain what happens during recording (e.g., overwrites existing macros), stopping (e.g., saves to register), or playing (e.g., executes keystrokes). It also omits details like error handling, side effects, or any constraints, which are critical for a tool that modifies editor state.
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 extremely concise—a single, front-loaded sentence that lists all key actions without any fluff. Every word earns its place by directly stating the tool's core functionality, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (manipulating macros in an editor) and the lack of annotations and output schema, the description is insufficient. It doesn't cover behavioral aspects like what 'record' entails (e.g., starts capturing keystrokes), how 'stop' works, or what 'play' returns (e.g., success/failure). For a tool with potential side effects, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three parameters with enums and defaults. The description adds no additional semantic context beyond what's in the schema, such as explaining interactions between parameters (e.g., 'count' only applies to 'play'). This meets the baseline score since the schema adequately covers parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('record, stop, and play') and resource ('Neovim macros'), making it easy to understand what the tool does. However, it doesn't explicitly distinguish this tool from its sibling 'vim_register', which might also handle macro registers, leaving room for slight ambiguity in sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It doesn't mention any prerequisites, context for choosing between actions, or how it relates to sibling tools like 'vim_register' or 'vim_command', leaving users to infer usage based on the action names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions 'regex support and options', hinting at functionality, but fails to describe key behaviors: whether it moves the cursor to matches, highlights results, returns match positions, or has side effects like modifying the buffer. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how it operates.
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 a single, efficient sentence that front-loads the core action ('Search within current buffer') and adds key features ('with regex support and options') without waste. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search operation with regex and options, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., match count, positions), how errors are handled, or behavioral nuances like search direction. This leaves the agent with insufficient context to use the tool effectively beyond basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three parameters (pattern, ignoreCase, wholeWord) with their types and defaults. The description adds value by confirming regex support for 'pattern' and hinting at 'options', but doesn't provide additional syntax or format details beyond what the schema already states. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'within current buffer', making the purpose understandable. It distinguishes from siblings like 'vim_grep' (likely global search) and 'vim_search_replace' (search and replace), though it doesn't explicitly name these alternatives. However, it doesn't fully specify the scope (e.g., search forward/backward, highlight results), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance, mentioning 'regex support and options' but not when to use this tool versus alternatives like 'vim_grep' or 'vim_search_replace'. It lacks explicit context on prerequisites (e.g., requires an open buffer) or exclusions, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. While it mentions the three boolean options (global, case-insensitive, confirm), it doesn't disclose important behavioral aspects like whether this operates on the current buffer or all open files, whether changes are saved automatically, what happens if no matches are found, or what the response format looks like. For a mutation tool with zero annotation coverage, this is insufficient.
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 extremely concise - a single sentence that efficiently communicates the core functionality and key options. Every word earns its place with zero wasted text, making it front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, how errors are handled, whether the operation is reversible, or what permissions might be required. Given the complexity of a find-and-replace operation in a text editor context, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description mentions the three boolean options (global, case-insensitive, confirm) but adds no additional semantic meaning beyond what's already in the schema descriptions. This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Find and replace' with specific options (global, case-insensitive, confirm), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'vim_search' or 'vim_grep', which might have overlapping search functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. With multiple sibling tools related to search (vim_search, vim_grep) and editing (vim_edit, vim_command), there's no indication of when this specific find-and-replace operation is appropriate versus other search or editing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. While it mentions the actions (create, close, navigate), it doesn't describe what 'manage' entails operationally - such as whether tabs persist across sessions, if closing a tab destroys content, what permissions are needed, or what the response format looks like. For a mutation tool with zero annotation coverage, this is inadequate.
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 extremely concise - a single sentence that efficiently communicates the core functionality. It's front-loaded with the main purpose and lists the key actions. Every word earns its place with no redundant information or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (managing tabs involves creation and deletion) with no annotations and no output schema, the description is incomplete. It doesn't address what happens when tabs are created or closed, what the return values are, or how errors are handled. For a tool with 2 parameters and significant behavioral implications in a Neovim environment, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly with descriptions and enum values. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain the relationship between 'action' and 'filename', or provide examples of how parameters interact. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as managing Neovim tabs with specific actions (create, close, navigate). It uses a specific verb ('manage') and identifies the resource ('Neovim tabs'). However, it doesn't explicitly distinguish this tool from its many siblings like vim_window or vim_buffer, which might have overlapping functionality in the Neovim context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. With 17 sibling tools listed, including vim_window and vim_buffer, there's no indication of how tab management differs from window or buffer operations in Neovim. The description only states what the tool does, not when it's appropriate to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the action but doesn't explain what 'visual mode selections' entail (e.g., whether they persist, require Vim to be in visual mode, or affect buffer state). This is a significant gap for a tool that likely modifies editor state.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a Vim visual selection tool with no annotations and no output schema, the description is inadequate. It doesn't explain the behavioral impact (e.g., how selections interact with other Vim commands), return values, or error conditions, leaving critical gaps for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all four parameters with indexing details. The description adds no parameter-specific information beyond implying selection creation, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create visual mode selections') and the target ('in the buffer'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like vim_edit or vim_search_replace, which might also involve buffer manipulation, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It doesn't mention prerequisites, context (e.g., after opening a file with vim_file_open), or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool checks health but doesn't explain what 'health' entails (e.g., connectivity, plugin status, performance), what the output might include, or any side effects like logging or timeouts. This is inadequate for a tool with zero annotation coverage.
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 a single, efficient sentence: 'Check Neovim connection health.' It is front-loaded with the core action and resource, with zero wasted words. Every element earns its place by clearly conveying the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't specify what 'health' means, what the tool returns (e.g., status codes, error messages), or behavioral traits like execution time or dependencies. For a health-check tool, this leaves significant gaps in understanding its functionality and output.
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?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids unnecessary details. A baseline of 4 is applied as it meets expectations for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Check Neovim connection health' with a specific verb ('Check') and resource ('Neovim connection health'). It distinguishes itself from siblings like vim_buffer or vim_command by focusing on health verification rather than buffer operations or command execution. However, it doesn't explicitly differentiate from vim_status, which might overlap in monitoring functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, such as when to verify connection health (e.g., after errors or periodically), or suggest alternatives like vim_status for broader status checks. This lack of context leaves usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. While 'Set' implies a mutation operation, it doesn't disclose whether this action is reversible, if it requires specific buffer states, what happens if a mark already exists, or any error conditions. For a mutation tool with zero annotation coverage, this is a significant gap in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a mutation operation with 3 parameters) and no annotations or output schema, the description is minimally adequate. It states what the tool does but lacks crucial context about behavior, usage scenarios, and error handling that would be needed for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all three parameters (mark, line, column). The description adds no additional parameter semantics beyond what the schema provides, such as explaining the relationship between parameters or typical usage patterns. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set named marks') and the target ('at specific positions in the buffer'), which is a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from potential sibling tools like 'vim_jump' or 'vim_visual' that might also involve buffer navigation or marking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. There are no mentions of prerequisites, typical use cases, or comparisons with sibling tools like 'vim_jump' (which might involve jumping to marks) or 'vim_visual' (which might involve visual selections).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. While 'manage' implies mutation capabilities, it doesn't specify permissions needed, side effects (e.g., whether closing a window destroys content), error conditions, or response format. For a mutation tool with zero annotation coverage, this is a significant gap.
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 extremely concise and front-loaded in a single sentence that efficiently communicates the core functionality. Every word earns its place with no redundancy or unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (managing windows with multiple commands), no annotations, and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose but lacks behavioral details, error handling, or output expectations that would be helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'command' fully documented in the schema including enum values and descriptions. The description adds no additional parameter semantics beyond what's in the schema, so the baseline score of 3 is appropriate when the schema does the heavy lifting.
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's purpose with specific verbs ('split, close, and navigate') and resource ('Neovim windows'), distinguishing it from siblings like vim_buffer or vim_tab which handle different Neovim components. It precisely communicates what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It doesn't mention prerequisites, when not to use it, or how it relates to sibling tools like vim_tab for tab management or vim_buffer for buffer operations. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a read operation ('Get') and lists specific data returned, but lacks details on permissions, rate limits, or error behavior. It adequately describes what the tool does without contradicting any annotations.
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 a single, efficient sentence that front-loads the core action ('Get comprehensive Neovim status') and enumerates key data points. Every word adds value without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 0 parameters and no output schema, the description is minimally adequate. It specifies what data is retrieved but doesn't detail the return format or structure. Given the lack of annotations and output schema, more context on the response would be beneficial.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately omits parameter details, focusing on the tool's purpose. Baseline is 4 for zero parameters, as it doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('comprehensive Neovim status'), specifying what information is retrieved (cursor position, mode, marks, registers). It distinguishes from siblings like vim_mark or vim_register by covering multiple status aspects, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving Neovim status, but provides no explicit guidance on when to use this tool versus alternatives like vim_health or other status-related tools. Usage context is inferred from the tool's purpose rather than stated.
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:

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

Score Badge

Copy to your README.md:

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

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/bigcodegen/mcp-neovim-server'

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