search-boost-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| EXA_API_KEY | No | Exa API key. Enables the Exa engine in the api layer. | |
| XAI_API_KEY | No | X/Twitter (xAI) API key. Optional, used to improve x_search. | |
| BRAVE_API_KEY | No | Brave Search API key. Enables the Brave engine in the api layer. | |
| TAVILY_API_KEY | No | Tavily API key. Enables the Tavily engine in the api layer. | |
| SEARCH_BOOST_HOME | No | Override base directory for search-boost runtime data. | |
| SEARCH_BOOST_KEYS_FILE | No | Override path to the keys configuration file. | |
| SEARCH_BOOST_LAYER_FILE | No | Override path to the layer configuration file. | |
| SEARCH_BOOST_XAUTH_FILE | No | Override path to the X/Twitter authentication configuration file. |
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
} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fused_searchA | Use for the vast majority of public-web research tasks, from precise lookups to difficult investigations. This general-purpose multi-engine search does not require Jev. If adaptive_search is unavailable, disabled or Jev is not configured, use enabled fused_search normally; do not delay research or require Jev setup. When both tools are available, choose fused_search for direct retrieval, varied query angles or explicit source control. Prefer adaptive_search for higher-quality intent-guided evidence selection when a medium-to-high difficulty or uncertain question benefits from screening noisy or mixed-relevance results. Choose by the evidence need, not merely by which tools are configured. Returns ranked extracts, source attribution and execution diagnostics, including failures and warnings. Normally omit engines; request-local choices do not change persistent defaults. Add X community voices when relevant; use x_search for X-only tasks. Scores do not verify claims, and multiple engines finding the same page do not independently corroborate it. Use fetch_page to read decisive sources when extracts are insufficient. Optional live status: search-boost://capabilities Resource. |
| fetch_pageA | Read a known HTTP(S) URL without searching again. Returns readable HTML or locally extracted PDF text, with retrieval route and any extraction limitations. Long bodies use bounded windows; continue from nextOffset using the cached read, not a new request. A focus miss is not evidence of absence: retry without focus. Binary bodies and PDFs with no extractable text return errors, not page text. Network safety, proxy policy, cancellation and size limits remain enforced through all supported fallbacks. This is not an authenticated browser. |
| x_searchA | Find X/Twitter posts, account material or available thread content. Credential-free retrieval is supported; configured authentication can improve coverage. Results include source attribution and diagnostics. Author/date filters require verifiable metadata; unverified candidates are omitted. Coverage may be incomplete, stale or empty. A post sample does not establish platform-wide sentiment, and a thread result need not contain the full conversation. |
| search_layerA | Inspect the current search layer with layer=show (default, no change). layer=free or api persists a new default: only change it when authorized. free = free — compatibility default engine_pool=free (keyless). api = api — compatibility default engine_pool=hybrid (keyless plus configured APIs). For a single search, use fused_search.engine_pool instead; legacy api maps to hybrid, not the strict api pool. |
| search_statsA | Read-only search diagnostics: cache activity, engine configuration readiness and recent searches. Inspect result warnings as well; empty results do not prove absence or authorize changing credentials, permissions or defaults. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| search_routing | Explicitly requested search-plan helper for a task; not required for normal tool calls. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| search-capabilities | Current available engines, pool defaults, compatibility layer and X official/fallback readiness. Recomputed on every read; no credentials or live connectivity guarantee. |
| search-policy | Optional examples, evidence limitations, and connection/layer troubleshooting. Not required before tool calls. |
TDQS
Scored across 5 tools
Tools have mostly distinct purposes: fused_search for general web search, x_search for X/Twitter, fetch_page for URL reading, and search_stats/search_layer for diagnostics/configuration. However, search_stats and search_layer both touch engine configuration, and fused_search's description references a non-existent adaptive_search tool, which could cause mild confusion.
All names use snake_case, which is consistent. However, the naming patterns vary: fused_search (adjective_noun), fetch_page (verb_noun), x_search (noun_noun), search_stats (noun_noun), search_layer (noun_noun). There is no single predictable verb_noun convention, though names remain readable.
5 tools is well-scoped for a search server: core search, specialized X search, page fetch, diagnostics, and configuration. Each tool has a clear role without redundancy.
The surface covers general search, X search, page fetch, stats, and layer configuration. However, the descriptions reference an adaptive_search tool for higher-quality intent-guided evidence selection that is not present, indicating a notable gap in the intended tool set.