groundlink-mcp
Servidor MCP de Groundlink
Usa los resultados de búsqueda web citados de Groundlink desde cualquier host de Model Context Protocol (MCP). El servidor expone una herramienta enfocada, groundlink_search, que envía una consulta a Groundlink y devuelve resultados con fuentes (title, url, snippet y source) para que el modelo los use cuando necesite evidencia en lugar de una suposición.
Groundlink combina actualmente resultados de Wikipedia y DuckDuckGo. Cada clave de API de Groundlink incluye 100 consultas de prueba gratuitas; después, el uso prepagado es de $0,001 por consulta (un crédito por consulta).
Paquete:
groundlink-mcp@0.1.1está publicado en npm. Código fuente: https://github.com/ohhavefun/groundlink
Documentación de la API en vivo: https://9ea69cec60fa01f65bbb647a092bcbb4.ctonew.app/docs
Precios y créditos: https://9ea69cec60fa01f65bbb647a092bcbb4.ctonew.app/pricing
Herramienta
Campo | Valor |
Nombre de la herramienta |
|
Entrada |
|
| 1–10; predeterminado 5 (o |
Salida | JSON: |
Úsala para preguntas factuales en las que el host deba devolver URLs/fuentes con su respuesta. El servidor MCP es deliberadamente ligero: reenvía la consulta a la API HTTPS de Groundlink y devuelve la respuesta de la API a través de MCP stdio.
Related MCP server: google-search-mcp
Instalación y ejecución
Necesitas una clave de API de Groundlink (glk_...). Pide una al operador de Groundlink u obtén una a través del flujo de incorporación de Groundlink.
npm install -g groundlink-mcp
export GROUNDLINK_API_KEY=glk_your_key_here
groundlink-mcpAlternativamente, un host MCP puede ejecutar el paquete sin una instalación global:
npx -y groundlink-mcpEl proceso usa stdio; no abre un puerto HTTP ni imprime salida normal en stdout. Los hosts MCP deben lanzarlo en lugar de ejecutarlo de forma interactiva.
Configuración
Variable | Requerida | Predeterminado | Significado |
| Sí | — | Clave de API usada para cada solicitud de Groundlink. |
| No | URL en vivo de Groundlink | Anula solo para un despliegue compatible. |
| No |
| Resultados predeterminados por llamada de herramienta; limitado a |
Configuración de Claude Desktop
Añade esta entrada al archivo de configuración MCP de Claude Desktop y reinicia Claude Desktop. Mantén la clave de API privada: no la confirmes en un repositorio ni compartas el archivo de configuración.
{
"mcpServers": {
"groundlink": {
"command": "npx",
"args": ["-y", "groundlink-mcp"],
"env": {
"GROUNDLINK_API_KEY": "glk_your_key_here"
}
}
}
}Si el paquete está instalado globalmente, usa "command": "groundlink-mcp" y omite args. Para hosts que necesiten una ruta ejecutable absoluta, apunta command al binario groundlink-mcp instalado.
Qué ocurre con los errores
Falta
GROUNDLINK_API_KEY: el servidor se cierra al inicio con un error de configuración claro.Clave de API rechazada (401): se devuelve al host MCP como un error de herramienta; corrige la clave en lugar de reintentar.
Sin créditos gratuitos o prepagados restantes (402): se devuelve como un error de herramienta; recarga la clave antes de otra búsqueda.
Caída de la fuente de búsqueda (502): se devuelve como un error de herramienta; un reintento breve puede ayudar.
Descripción para el marketplace
Groundlink: búsqueda web citada para MCP. Dale a Claude, Cursor y otros hosts MCP una herramienta groundlink_search que devuelve resultados con fuentes en lugar de suposiciones factuales sin respaldo. Cada clave comienza con 100 pruebas gratuitas; después, el uso es de $0,001 por consulta mediante créditos prepagados.
Comprobaciones de desarrollo y publicación
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 publishingEl paquete npm incluye intencionadamente solo el runtime compilado dist/, este README y los metadatos de paquete requeridos por npm. El código fuente y las pruebas de humo quedan fuera del tarball.
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-