mcp-retriever
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
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| result_readB | Read up to 12000 UTF-8 bytes by opaque result_id. Follow next_offset and next_byte_offset as byte_offset within that line. Join byte continuations directly, ordinary line pages with LF. Results expire or may be evicted. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| provider-status | Current status of all search providers |
TDQS
Scored across 1 tool
There is only one tool, so there is no risk of confusing it with another operation. Its purpose—reading stored result content by an opaque result_id—is clear.
With a single tool, there is no internal inconsistency across names. The name result_read is readable but uses a noun-first form rather than the more typical verb_noun convention.
A single tool is borderline thin for a server surface, though this may be acceptable for a narrowly scoped result-retrieval utility. It does not feel excessive, but it lacks enough breadth to feel fully well-scoped.
The tool covers paginated reading of result content, including byte-offset continuation. However, there are no operations for discovering result IDs, inspecting metadata/status, or managing expired/evicted results, which are notable gaps for a retrieval surface.