groundlink-mcp
Groundlink MCP Server
Используйте цитируемые результаты веб-поиска Groundlink из любого хоста Model Context Protocol (MCP). Сервер предоставляет один узконаправленный инструмент groundlink_search, который отправляет запрос в Groundlink и возвращает результаты с источниками (title, url, snippet и source) для модели, когда ей нужны доказательства, а не догадки.
Groundlink в настоящее время объединяет результаты Wikipedia и DuckDuckGo. Каждый ключ API Groundlink включает 100 бесплатных тестовых запросов; после этого предоплаченное использование стоит $0,001 за запрос (один кредит за запрос).
Пакет:
groundlink-mcp@0.1.1опубликован на npm. Исходный код: https://github.com/ohhavefun/groundlink
Живая документация API: https://9ea69cec60fa01f65bbb647a092bcbb4.ctonew.app/docs
Цены и кредиты: https://9ea69cec60fa01f65bbb647a092bcbb4.ctonew.app/pricing
Инструмент
Поле | Значение |
Имя инструмента |
|
Входные данные |
|
| 1–10; по умолчанию 5 (или |
Выходные данные | JSON: |
Используйте его для фактических вопросов, когда хост должен вернуть URL-адреса/источники вместе с ответом. MCP-сервер намеренно минималистичен: он пересылает запрос в HTTPS API Groundlink и возвращает ответ API через MCP stdio.
Related MCP server: google-search-mcp
Установка и запуск
Вам понадобится ключ API Groundlink (glk_...). Запросите его у оператора Groundlink или получите через процесс адаптации Groundlink.
npm install -g groundlink-mcp
export GROUNDLINK_API_KEY=glk_your_key_here
groundlink-mcpАльтернативно, MCP-хост может выполнить пакет без глобальной установки:
npx -y groundlink-mcpПроцесс использует stdio; он не открывает HTTP-порт и не выводит обычные данные в stdout. MCP-хосты должны запускать его, а не выполнять в интерактивном режиме.
Конфигурация
Переменная | Обязательная | По умолчанию | Описание |
| Да | — | Ключ API, используемый для каждого запроса Groundlink. |
| Нет | Живой URL Groundlink | Переопределяйте только для совместимого развертывания. |
| Нет |
| Количество результатов по умолчанию на вызов инструмента; максимум |
Конфигурация Claude Desktop
Добавьте эту запись в файл конфигурации MCP в Claude Desktop и перезапустите Claude Desktop. Держите ключ API в тайне: не сохраняйте его в репозиторий и не публикуйте файл конфигурации.
{
"mcpServers": {
"groundlink": {
"command": "npx",
"args": ["-y", "groundlink-mcp"],
"env": {
"GROUNDLINK_API_KEY": "glk_your_key_here"
}
}
}
}Если пакет установлен глобально, используйте "command": "groundlink-mcp" и опустите args. Для хостов, которым нужен абсолютный путь к исполняемому файлу, укажите command на установленный бинарный файл groundlink-mcp.
Что происходит при ошибках
Отсутствует
GROUNDLINK_API_KEY: сервер завершает работу при запуске с понятной ошибкой настройки.Ключ API отклонен (401): возвращается MCP-хосту как ошибка инструмента; исправьте ключ, а не повторяйте попытки.
Нет оставшихся бесплатных или предоплаченных кредитов (402): возвращается как ошибка инструмента; пополните баланс ключа перед следующим поиском.
Сбой источника поиска (502): возвращается как ошибка инструмента; может помочь короткая повторная попытка.
Описание в маркетплейсе
Groundlink — цитируемый веб-поиск для MCP. Дайте Claude, Cursor и другим MCP-хостам один инструмент groundlink_search, который возвращает результаты с источниками вместо необоснованных фактических догадок. Каждый ключ начинается со 100 бесплатных тестов, затем использование стоит $0,001 за запрос через предоплаченные кредиты.
Проверки разработки и релиза
bun install
bun run typecheck
bun run build # emits executable dist/index.js
bun run test # MCP stdio smoke test
npm run pack:check # inspect the npm tarball without publishingПакет npm намеренно включает только скомпилированный dist/-рантайм, этот README и обязательные метаданные пакета npm. Исходный код и смоук-тесты не входят в архив.
Available Tools
1 toolgroundlink_searchA
Search Groundlink's verified index (Wikipedia + DuckDuckGo) for a query and return cited results (title, url, snippet, source) so the model can answer with sources. Each call costs a fraction of a cent against the API key's free/credit balance. Prefer this over guessing when a factual claim needs verification or a source.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to ground. Use a concise, factual question or phrase. | |
| max_results | No | How many cited results to return (1–10). Defaults to 5. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses meaningful behavioral traits: searches a verified index rather than arbitrary web content, returns structured cited results, and mentions cost ('a fraction of a cent against the API key's free/credit balance'). It does not mention rate limits or explicit read-only semantics, but the search action clearly implies no mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at three sentences, front-loads the primary purpose and output, adds a relevant cost note, and closes with usage guidance. Every sentence adds distinct value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is reasonably complete for a search tool with no output schema: it lists the returned fields, explains the verified-index scope, and provides cost awareness. It does not cover failure modes or authorization requirements, but for a read-only search operation these are not critical gaps and the essential calling context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides; the 'query' guidance and max_results behavior are already fully documented in the input schema. No additional insight is given about parameter formats or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Search'), names the exact resource ('Groundlink's verified index (Wikipedia + DuckDuckGo)'), and enumerates the returned fields ('title, url, snippet, source'). This unambiguously explains what the tool does and what output it produces, easily distinguishing it from any guessing or other knowledge retrieval behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Prefer this over guessing when a factual claim needs verification or a source.' It also implicitly states when not to use it (do not guess) and is the only tool of its kind, so no alternative routing is needed. This is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.1- First observed
groundlink_search
TDQS
Scored across 1 tool
With only one tool, there is no possibility of overlap or confusion between tools. The single search tool has a clearly defined purpose.
The tool name follows a clear and logical pattern: groundlink_search. Although there is only one tool, the naming is consistent with common conventions and leaves no ambiguity.
A single tool feels thin for a server, but it is focused on one specific search function that could be reasonably self-contained. It does not appear excessive, yet the surface is minimal.
For a search-focused server, the tool fully covers the core capability of searching and returning cited results. There are no obvious missing operations for its apparent purpose.
Maintenance
Related MCP Connectors
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
Web search, scraping, RAG answers with citations, and translation as MCP tools.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
MCP-native web evidence and claim verification: cited, source-grounded evidence for AI agents.
Related MCP Servers
- AlicenseBqualityCmaintenanceEnables web search and site-specific search capabilities through the Deepsearch model. Provides unified access to broad web retrieval and targeted site search functionality within the MCP ecosystem.27 npm5Apache 2.0
- AlicenseNot gradedqualityDmaintenanceEnables LLMs to perform real-time Google searches and retrieve web results via the MCP protocol.-
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to perform web searches with full content retrieval and multi-engine provenance, including trust scoring and local corpus persistence, via MCP integration.1 npm2Apache 2.0
- FlicenseAqualityCmaintenanceEnables MCP-compatible agents to perform web searches via the agent-web-search engine, returning ranked results with sources.1-