PocketDex MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| POCKETDEX_DATA | No | Override the location where PocketDex stores project databases. Defaults to data/projects when run from a clone, or ~/.local/share/pocketdex/projects when installed. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| index_projectA | Index or refresh one project folder in its own private database. Call once before searching an unfamiliar repository, and again after large changes. Incremental: unchanged files are skipped. |
| searchA | Search one project's index by keyword or identifier. Returns file paths, line ranges and short highlighted snippets, so use this before opening whole files. Good for 'where is X', 'who calls Y', 'how is Z implemented'. |
| statsA | Show indexed projects, their separate databases, file and chunk counts, and index size. Use to check whether a folder is indexed. |
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
The three tools target clearly separate actions: building an index (index_project), querying it (search), and inspecting index metadata (stats). There is no overlap in purpose and the descriptions reinforce the boundaries (index before search, stats to verify indexing).
index_project follows a verb_noun pattern, but 'search' is a bare verb and 'stats' is a bare noun, so the set mixes conventions. All names are short and readable, but there is no single predictable pattern.
Three tools is a tight, well-scoped surface for a code-index/search server, and each tool clearly earns its place. It sits at the lower bound of a comfortable range, leaving little room for complementary operations.
Index, query, and inspect cover the core workflow, but there is no way to delete or drop a stale project database, refresh all projects at once, or retrieve full file contents (search only returns snippets). Agents can work around some of this, but index lifecycle management is notably absent.