webnav-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WEBNAV_MCP_ROOTS | No | Comma-separated label=relative/path pairs to index separately, e.g. app=src,prototypes=design when two trees define their own values. | the whole workspace as one root, labelled web |
| WEBNAV_MCP_EXCLUDE | No | Comma-separated workspace-relative paths of generated script output (e.g. the JS a TS build emits). These aren't opened, are hidden from search_symbol, and are rejected by the position tools. The CSS/selector index still reads them. | nothing |
| WEBNAV_MCP_WORKSPACE | No | Pins the project root (never overridden). Default: unset: follows the client's MCP roots when they name a worktree of the same git repository, else CLAUDE_PROJECT_DIR, else the working directory. | unset: follows the client's MCP roots when they name a worktree of the same git repository, else CLAUDE_PROJECT_DIR, else the working directory |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| hoverB | Get type/documentation info for the symbol at a position.
|
| workspaceA | Which directory is webnav navigating, and why? Use when results look like they come from the wrong checkout/worktree. |
| definitionA | Go to the definition of the symbol at a position.
|
| referencesA | Find all usages of the symbol at a position across the workspace.
|
| search_symbolA | Search JS/TS files for a symbol by name (function, class, const, etc.). JS/TS-only: the HTML/CSS language servers don't implement useful
workspace-wide symbol search (webnav does not reimplement it). Prefer
|
| symbol_infoA | What is X and where is it used? Example: One-call summary for a JS/TS name: header, hover text, definition, and
references grouped by file — the usual first lookup instead of chaining
search_symbol → hover → definition → references by hand. Pass |
| outlineA | What's in this file? Example: Indented outline (functions, classes, interfaces, with |
| diagnosticsA | Get the relevant language server's diagnostics (errors/warnings) for a single file. For |
| css_varA | Where is this The CSS/HTML language servers only see one file at a time, so
|
| selectorA | Who uses this Looks up the selector across the whole workspace. Cross-references CSS rule definitions, HTML |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools have clearly distinct purposes: hover/definition/references are standard position-based LSP queries, css_var and selector target distinct cross-file resource types, and workspace is a unique diagnostic. The only real overlap is search_symbol vs symbol_info (both accept a name), but the descriptions explicitly frame symbol_info as the one-call summary wrapper, which should steer selection correctly.
All names are lowercase and use snake_case for multi-word names (search_symbol, symbol_info, css_var), with single-word names for the rest, so there is no case or delimiter mixing. However, there is no unifying verb_noun pattern—several tools are bare nouns (hover, definition, references, diagnostics, outline)—so it is consistent in style but not in grammatical shape.
Ten tools is a well-scoped set for a code-navigation server: four core LSP-style primitives, three navigation helpers (outline, search_symbol, symbol_info), two cross-file CSS/HTML index lookups, and one workspace diagnostic. Each tool maps to a distinct workflow and none feel padded.
The surface covers navigation (definition, references, hover, outline, symbol search), diagnostics, and cross-file CSS/HTML lookups well, with clear coverage of the stated JS/TS/CSS/HTML domain. Minor gaps remain—no rename, call hierarchy, implementation lookup, or general textual/file search—but these are outside the apparent navigation-focused scope and agents can work around them.