mcp-human-search
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HUMAN_SEARCH_HOME | No | State root (default `~/.human-search`) | ~/.human-search |
| HUMAN_SEARCH_LOCALE | No | Locale override | |
| HUMAN_SEARCH_BROWSER | No | Explicit browser executable path | |
| HUMAN_SEARCH_ENGINES | No | Comma list: the enabled set and its order (`bing,google` = only those two, Bing first) | |
| HUMAN_SEARCH_HEADLESS | No | `0`/`false`/`no` runs searches headed | |
| HUMAN_SEARCH_IDLE_CLOSE_MS | No | Idle browser close delay (`0` = keep alive) | |
| HUMAN_SEARCH_CHAIN_BUDGET_MS | No | Whole-chain budget | |
| HUMAN_SEARCH_PER_ENGINE_TIMEOUT_MS | No | Per-engine budget |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| human_searchA | Search the web the way a person does: a real browser drives real search engines (Google, DuckDuckGo, Bing, Baidu, Sogou) in a persistent per-engine profile, trying them in a configured fallback order. CAPTCHAs and bot walls fail over to the next engine and open a headed sign-in window on the server machine for the user to solve (see human_search_sign_in); cookies persist across searches. Returns a provenance note (which engine served, which were skipped and why) followed by a numbered result list, plus structured sources for citation. Use human_search_status to inspect engine health. |
| human_search_sign_inA | Open a headed browser window on the machine running this MCP server, on the engine's own persistent profile, so the user can solve a CAPTCHA and/or sign in to their account (Google, Microsoft, Baidu, ...). The user types credentials into the engine page itself; this server never sees them. Cookies persist for all future searches. While the window is open, searches on that engine fail over to the others instantly. Requires a display on the server machine (SSH X forwarding counts); on a headless host, warm the profiles with the |
| human_search_statusA | Report the human-search server state without touching the network: whether a usable browser was found (and which), per-engine health (ok / blocked / signing-in, with reasons), sign-in windows currently open, the state root, and the resolved configuration. |
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 targets a distinct concern: human_search_status inspects server state without networking, human_search performs the actual search, and human_search_sign_in handles CAPTCHA/credential solving. The descriptions explicitly cross-reference each other (e.g. 'Use human_search_status to inspect engine health'), leaving no realistic misselection.
All three tools share the human_search_ prefix and snake_case, giving a clear family. The main action tool drops the suffix entirely (human_search instead of human_search_run/search), a minor deviation from the otherwise predictable prefix+qualifier pattern.
Three tools cleanly cover the server's narrow purpose of browser-driven human-like search: search, inspect status, and solve sign-in. Nothing is redundant and nothing feels missing by way of extra surface area.
The search/status/sign-in lifecycle is well covered, including failover and provenance reporting. Minor gaps exist—no tool to close a pending sign-in window, clear/logout cookies, or list warm profiles (some of this is only reachable via the documented CLI).