어떤 Model Context Protocol (MCP) 호스트에서든 Groundlink의 인용 정보가 포함된 웹 검색 결과를 사용하세요. 이 서버는 groundlink_add라는 하나의 집중된 도구를 제공하며, 이 도구는 Groundlink에 쿼리를 보내고 출처가 포함된 결과(title, url, snippet, source)를 반환합니다. 모델이 추측이 아니라 근거가 필요할 때 사용할 수 있습니다.
Groundlink는 현재 Wikipedia와 DuckDuckGo 결과를 결합합니다. 각 Groundlink API 키에는 100개의 무료 테스트 쿼리가 포함됩니다. 이후에는 선불 사용 요금이 쿼리당 $0.001 (쿼리당 1크레딧)입니다.
패키지:
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 서버는 의도적으로 가볍게 유지됩니다. 쿼리를 Groundlink HTTPS API에 전달하고 API 응답을 MCP stdio를 통해 반환합니다.
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 포트를 열지 않고 표준 출력에 일반적인 출력을 인쇄하지 않습니다. 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를 설치된 groundlink-mcp 바이너리를 가리키도록 설정하세요.
GROUNDLINK_API_KEY 누락: 서버가 시작 시 명확한 설정 오류와 함께 종료됩니다.
API 키 거부됨(401): 도구 오류로 MCP 호스트에게 반환됩니다. 키를 수정해야 하며 재시도하지 마세요.
무료 또는 선불 크레딧이 남아 있지 않음(402): 도구 오류로 반환되며, 검색 전에 키를 충전해야 합니다.
검색 소스 중단(502): 도구 오류로 반환되며, 짧은 재시도가 도움이 될 수 있습니다.
Groundlink — 인용 기반 웹 검색 for 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.
