yeivily-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| YEIVILY_URL | No | Where the MCP server finds the daemon. Default `http://127.0.0.1:8000`. | |
| YEIVILY_HOST | No | Bind address (default `127.0.0.1`). | |
| YEIVILY_PORT | No | Bind port (default `8000`). | |
| YEIVILY_REGION | No | ddgs region (`es-es`, `cl-es`, `us-en`, ...). Default `wt-wt`. | |
| YEIVILY_API_KEY | No | Require `Authorization: Bearer <key>`. | |
| YEIVILY_CACHE_MAX | No | Cache entries. Default `256`. | |
| YEIVILY_CACHE_TTL | No | Cache seconds. Default `600`. | |
| YEIVILY_DEEP_TOP_N | No | Results enriched with page text when `include_raw_content` or `search_depth=advanced`. Default `3`. | |
| YEIVILY_SAFESEARCH | No | Safe search setting: `on`, `moderate`, `off`. Default `moderate`. | |
| YEIVILY_FAKE_ANSWER | No | Fill `answer` with concatenated snippets (not an LLM answer). Default off. | |
| YEIVILY_ALLOW_PRIVATE_FETCH | No | Let `/extract` reach LAN/localhost addresses. Default off. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| web_searchA | Search the web (DuckDuckGo) for current information, documentation, news or anything outside your training data. Returns titles, URLs and snippets. Set deep=true to also get text excerpts from the top pages. |
| fetch_pageA | Download a single web page and return its readable text. Use it to read a URL found via web_search. Does not execute JavaScript and does not read PDFs. |
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 cover clearly disjoint steps of a retrieval workflow: web_search discovers URLs and fetch_page reads a known URL. Descriptions even cross-reference each other, making the intended pipeline unambiguous.
Both names follow a consistent snake_case verb_noun pattern (web_search, fetch_page). The only nuance is that web_search puts the resource before the verb, but the two names still read as a coherent, predictable pair.
Two tools is minimal but each earns its place in a search-then-read workflow, with no redundancy. It is slightly thin for a standalone server, since filters or pagination would otherwise be separate tools.
Search plus fetch covers the core web-retrieval lifecycle with no dead ends for the stated scope. Gaps exist but are documented (no PDF reading, no JavaScript, no date/region filters or result-count control), which agents can work around.