graphlens-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| searchA | Find code by NAME, CONTENT, or MEANING — the one way in (default limit 25). Returns graph nodes WITH their signatures (not dead text lines): often enough to answer without info(). Pass any node to relations/info. Use wherever you'd grep or search for a symbol; content hits fold into the enclosing symbol. text_matches = non-symbol hits. Content is matched LITERALLY (not regex) — write 'Request(' or 'getErrorMap(' as-is, no escaping needed. Scope with path_glob (e.g. 'tests/', '.ts', '!tests/' to exclude) — there is no file:/content: query syntax, so use this instead of guessing one. Test files are excluded by default unless you set path_glob yourself or the query says 'test' — pass path_glob='tests/' to search them on purpose. For 'list EVERY file that calls/imports X' — where the top-N node list could miss some — set exhaustive=true: returns every matching file path (no signatures), uncapped by the normal limit. If the response's note field is set, your exact text matched nothing — every node is a name/meaning guess, not a confirmed hit — simplify the query instead of repeating it. |
| relationsA | A symbol's neighbourhood in one call: who calls it, what it calls, what implements/subclasses it, and non-call references — each with its signature. Accepts a node id OR a name (default depth 2, limit 25). THE tool for impact analysis and 'what implements X'. If the name matches several definitions, pass file (a path or suffix) to pin the right one — e.g. one UserService per service in a monorepo. |
| infoA | Read a specific target. A SYMBOL (node id or name) -> source, signature and location. A FILE path -> its symbol outline by default (default limit 200 symbols) — a cheap structural overview. Set mode='source' to read the file's actual current content instead: line-numbered (same shape as Read, safe to Edit from), windowable with offset/limit exactly like Read, plus which files import it. Use mode='source' instead of opening the file yourself whenever you need the body, not just its symbol list. If a symbol name matches several definitions, pass file (a path or suffix) to pin the right one — e.g. one UserService per service in a monorepo. |
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 3 tools
Each tool has a clearly distinct purpose: 'search' finds code by various criteria, 'info' reads details of a specific target, and 'relations' explores a symbol's connections. There is no overlap or ambiguity.
All tool names are single lowercase words ('info', 'relations', 'search'), following a consistent and predictable style. Although not verb_noun, the pattern is uniform.
With exactly 3 tools, the server is well-scoped for code graph analysis. Each tool covers a fundamental operation (find, inspect, explore) without being too few or too many.
The tool surface covers the essential workflows for code navigation: searching for symbols, reading their details or file contents, and exploring relationships. No obvious gaps are present for the intended domain.