使用 Groundlink 的引用网络搜索结果，来自任何模型上下文协议（MCP）主机。该服务器提供一个聚焦的工具 groundlink_search，它向 Groundlink 发送查询，并返回带来源的结果（title、url、snippet、source），供模型在需要证据而非猜测时使用。
Groundlink 目前结合了 Wikipedia 与 DuckDuckGo 的结果。每个 Groundlink API 密钥包含 100 次免费测试查询；之后，预付费使用价格为 每次查询 $0.001（每次查询一个积分）。
包:
groundlink-mcp@0.1.1已发布在 npm 上。 来源： https://github.com/ohhavefun/groundlink
实时 API 文档： https://9ea69cec60f01f65feb647a092bcbb4.ctonew.app/docs
定价与积分： https://9ea69cec60f01f65feb647a092bcbb4.ctonew.app/pricing
字段 | 值 |
工具名称 |
|
输入 |
|
| 1–10；默认 5（或 |
描述 | 对需要宿主在回答时返回 URL/来源的事实性问题使用此工具。该 MCP 服务器刻意保持轻量：它将查询转发到 Groundlink API，并通过 MCP stdio 返回 API 响应。 |
Related MCP server: google-search-mcp
你需要一个 Groundlink API 密钥（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 主机应以启动方式运行，而不是交互式运行。
参数 | 是否必填 | 默认值 | 说明 |
| 是 | — | 用于每次 Groundlink 请求的 API 密钥。 |
| 否 | Groundlink 实时地址 | 仅用于覆盖兼容部署的 URL。 |
| 否 |
| 每次工具调用的默认结果数；上限为 |
将此条目添加到 Claude Desktop 的 MCP 配置文件中，然后重启 Claude Desktop。请妥善保管 API 密钥：不要将其提交到代码仓库或共享该配置文件。
{
"mcpServers": {
"groundlink": {
"command": "npx",
"args": ["-y", "groundlink-mcp"],
"env": {
"GROUNDLINK_API_KEY": "glk_your_key_here"
}
}
}
}如果此包已全局安装，请使用 "command": "groundlink-mcp" 并省略 args。对于需要绝对可执行文件路径的主机，请将 command 指向已安装的 bunt groundlink` 可执行文件。
缺少 GROUNDLINK_API_KEY：服务器在启动时因错误退出。该配置错误。
API 密钥被拒绝（401）：作为工具错误返回给 MCP 主机；请更正密钥，而不是重试。
没有剩余免费或预付费积分（402）：作为工具错误返回；请在下一次搜索之前为该密钥充值。
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 publishingnpm 包有意只随附编译后的 dist/ 运行时、本 README 和 npm 所需的元数据。源码和冒烟测试不包含在 tarball 中。
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. |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1groundlink_searchScored 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.
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.
