Skip to main content
Glama
santanusinha

neovim-use-mcp

by santanusinha
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Open files in Neovim

nvim_open_file
Idempotent

Open one or more files in Neovim buffers and start their LSP clients. Pass a path or array of paths to receive buffer IDs, filetypes, line counts, and attached LSP clients, enabling pre-warming for faster subsequent operations.

Instructions

Open one or more files in Neovim buffers and start their LSP clients. Pass a single path or an array of paths. Returns the buffer id, filetype, line count and attached LSP clients for each file. Optional: use it to pre-warm files or tune wait_ms. Other tools open files on demand.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesFile path, or an array of file paths, absolute or relative to the server cwd
wait_msNoMilliseconds to wait for the LSP client to attach

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.4
    • addedInput schema / properties / path / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]
    • changedInput schema / properties / path / description
      Previous value: -"File path, absolute or relative to the server cwd"New value: +"File path, or an array of file paths, absolute or relative to the server cwd"
    • removedInput schema / properties / path / type
      Removed value: -"string"
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool idempotent and non-destructive. The description adds behavioral context by stating it starts LSP clients and supports a wait_ms control for client attachment, which goes beyond the structured hints and helps the agent anticipate 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 three sentences: core action, input/output summary, and optional use. Information is front-loaded, and every sentence serves a purpose with no filler or 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?

With no output schema, the description explains return values (buffer id, filetype, line count, LSP clients). It also covers input format, optional waiting behavior, and distinguishes from siblings. Nothing essential for correct invocation is missing.

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 baseline is 3. The description's parameter hints ('single path or array', 'tune wait_ms') largely restate the schema and add little semantic value beyond the structured field descriptions.

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 action: 'Open one or more files in Neovim buffers and start their LSP clients.' It names the verb, resource, and distinctive side effect. It also differentiates from siblings by noting 'Other tools open files on demand,' giving the tool a clear identity.

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?

The description provides clear usage context: 'use it to pre-warm files or tune wait_ms' and notes that other tools open files on demand. This helps an agent decide when to use the tool, though it doesn't name specific sibling alternatives or state explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools