quick-search
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QUICK_SEARCH_LOG_LEVEL | No | Controls Python logging verbosity. Valid values: DEBUG, INFO, WARNING, ERROR, CRITICAL. | INFO |
| QUICK_SEARCH_MAX_FILES | No | Default max files to return. Overrides tool-level default of 12. | 12 |
| QUICK_SEARCH_MAX_SNIPPETS | No | Default max snippets to return. Overrides tool-level default of 8. | 8 |
| QUICK_SEARCH_MAX_TOTAL_LINES | No | Default max total lines to return. Overrides tool-level default of 1200. | 1200 |
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 |
|---|---|
| search_repo_contextA | Search a repository with explicit keywords, rank likely relevant files without reading full files, and return bounded snippets around the strongest clustered matches. The tool prefers source files over docs when scores are similar, boosts likely function, class, struct, module, or method definition hits, merges overlapping match windows, and enforces hard budgets on returned files, snippets, and total lines. Optional subtree and glob filters can narrow the search space before ranking. Matching defaults to substring mode, with optional word and identifier-aware modes for stricter code search. Keyword expansion is bounded and returned transparently in the output. Prefer specific keywords over very general ones; ranking gives substantially more weight to matches on the original input keywords than to expansion-only matches. Preferred agent workflow: call the tool in compact mode first, then expand the cached result by query_id in full mode only if you need richer metadata; enable diagnostics only for debugging or tuning. Use it to narrow a large repo before deeper inspection. It returns structured output with summary counts, ranked files, snippets, and usage guidance. Pass an absolute directory path for reliable agent behavior. Relative directory values such as '.' only work when the MCP client exposes roots, so they are not portable across clients. The result is bounded and does not necessarily include every file that could be relevant for context. Only do further searches across the repository if this context is insufficient. |
| search_focused_contextA | Use this only after |
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 2 tools
The two tools have clearly distinct roles: one performs broad repository search with bounded snippets, the other expands specific results into full context. The descriptions explicitly state when to use the second tool only after the first, leaving no ambiguity.
Both names follow the same `search_` prefix pattern with a modifier distinguishing scope: `_repo_context` for broad search and `_focused_context` for targeted expansion. This is a consistent and predictable convention.
With only two tools, the server feels minimal, but the narrow purpose of a quick-search utility is well served by this two-stage design. The count is slightly thin yet not unreasonable for the stated scope.
The tool surface covers the full intended workflow: initial bounded search, then optional expansion for deeper context. No obvious dead ends exist, though more advanced query refinement or result-management features could be considered minor gaps.