nas-search-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| UNISEARCH_KEY | Yes | Path to the search-only SSH key used to reach the NAS, e.g. ~/.ssh/unisearch_agent (equivalent to `key=...` in ~/.config/unisearch/client.conf). | |
| UNISEARCH_HOST | Yes | The NAS SSH host, in the form <ssh-user>@<nas-host> (equivalent to `host=...` in ~/.config/unisearch/client.conf). | |
| UNISEARCH_LANG | No | Set to `en` for English messages (equivalent to `lang = en` in the settings files). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Search files on the user's Synology NAS through its Universal Search index (file names and indexed text). Read-only: it cannot open, change or delete files, and it only sees the folders the user allowed. Results and errors are the same JSON as the nas-search command. Rely on error.type and exit_code, not on the message text. If exit_code is 8, ask the user to start the search session on the NAS; never try to log in yourself. Never ask for passwords or codes, and do not send file names or paths to outside services.
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 |
|---|---|
| searchA | Search the NAS by file name and document text. Returns JSON with hits (name, share_path, path, size, is_dir, modified_utc) and next_offset. Tell the user locations with share_path. total is always null; more results exist when next_offset is not null, so pass it as offset to get the next page, or use max_results to collect several pages at once. If the index changes between pages, deduplicate by share_path. One search can take from a few seconds to several minutes; avoid many calls in a row. If nothing is found, try a shorter query or other spellings (full-width/half-width, English/Japanese). Errors: exit_code 2 = fix the arguments, 4 = retry once (scan_limit continues where it stopped), 5 = NAS or network down, 6 = unexpected response, 8 = no search session (ask the user to start it). |
| statusA | Show the NAS search session: expiry, time left (remaining_seconds), allowed folders, number of searches and the last error. |
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 serve entirely different purposes: 'search' performs content/name queries over the NAS, while 'status' only reports session metadata (expiry, folders, counters, last error). There is no realistic scenario where an agent would confuse the two, and the descriptions reinforce the distinction.
Both names are single, lowercase, underscore-free tokens with no prefix clutter, so the style is consistent. The only minor deviation is grammatical: 'search' is a verb while 'status' is a noun, which slightly breaks a verb_noun prediction but remains perfectly readable.
Two tools is thin even for a search-only server; the surface is essentially one operation plus a diagnostics call. The narrow purpose prevents it being a mismatch, but there is little headroom for anything beyond querying and checking state.
Search covers paging (offset/next_offset), sizing, and a detailed error taxonomy, which is solid for the core workflow. However, there is no way to browse a share or folder hierarchy, inspect a single file's details, or start/refresh the search session — a missing-session error (exit_code 8) leaves the agent with only 'ask the user', a dead end.