mcp-jina-ai
지나 AI MCP 서버
Claude를 통해 Jina AI의 강력한 웹 서비스에 접근할 수 있는 MCP 서버입니다. 이 서버는 세 가지 주요 도구를 구현합니다.
웹 페이지 읽기 및 콘텐츠 추출
웹 검색
사실 확인/접지
특징
도구
read_webpage
LLM에 최적화된 형식으로 웹 페이지에서 콘텐츠를 추출합니다.
다양한 출력 형식(기본값, 마크다운, HTML, 텍스트, 스크린샷, 페이지샷)을 지원합니다.
링크 및 이미지 포함 옵션
이미지에 대한 대체 텍스트를 생성하는 기능
캐시 제어 옵션
search_web
Jina AI의 검색 API를 사용하여 웹을 검색하세요
구성 가능한 결과 수(기본값: 5)
이미지 보존 및 대체 텍스트 생성 지원
다양한 반환 형식(마크다운, 텍스트, HTML)
제목, 설명 및 콘텐츠가 포함된 구조화된 결과를 반환합니다.
fact_check
Jina AI의 접지 엔진을 활용한 사실 확인 진술
사실성 점수와 뒷받침 증거를 제공합니다.
더욱 철저한 분석을 위한 선택적 심층 분석 모드
주요 인용문과 지지/모순 분류를 포함한 참조를 반환합니다.
Related MCP server: sysauto Ask MCP Server
설정
필수 조건
이 서버를 사용하려면 Jina AI API 키가 필요합니다. https://jina.ai/ 에서 무료로 받으세요.
설치
이 서버를 사용하는 방법은 두 가지가 있습니다.
Smithery를 통해 설치
Smithery를 통해 Claude Desktop에 Jina AI를 자동으로 설치하는 방법:
지엑스피1
옵션 1: NPX(권장)
Claude Desktop 구성 파일에 다음 구성을 추가하세요.
{
"mcpServers": {
"jina-ai-mcp-server": {
"command": "npx",
"args": [
"-y",
"jina-ai-mcp-server"
],
"env": {
"JINA_API_KEY": "<YOUR_KEY>"
}
}
}
}옵션 2: 로컬 설치
저장소를 복제합니다
종속성 설치:
npm install서버를 빌드하세요:
npm run buildClaude Desktop 구성에 다음 구성을 추가하세요.
{
"mcpServers": {
"jina-ai-mcp-server": {
"command": "node",
"args": [
"/path/to/jina-ai-mcp-server/dist/index.js"
],
"env": {
"JINA_API_KEY": "<YOUR_KEY>"
}
}
}
}구성 파일 위치
MacOS의 경우:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows의 경우:
%APPDATA%/Claude/claude_desktop_config.json디버깅
MCP 서버는 stdio를 통해 통신하므로 디버깅이 어려울 수 있습니다. MCP Inspector 사용을 권장합니다.
npm run inspector검사기는 브라우저에서 디버깅 도구에 액세스할 수 있는 URL을 제공합니다.
API 응답 유형
모든 도구는 다음을 포함하는 구조화된 JSON 응답을 반환합니다.
상태 코드 및 메타데이터
요청된 출력 유형에 따라 형식화된 콘텐츠
사용 정보(토큰 수)
해당되는 경우: 이미지, 링크 및 추가 메타데이터
자세한 스키마 정보는 schemas.ts 참조하세요.
Available Tools
3 toolsfact_checkC
Fact-check a statement using Jina AI's grounding engine
| Name | Required | Description | Default |
|---|---|---|---|
| deepdive | No | ||
| statement | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action. It does not disclose whether the tool returns a verdict, an explanation, or requires additional context. No mention of side effects or limitations.
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?
Extremely concise, single sentence, front-loaded with the main purpose. However, it sacrifices informative details that could be added without much length.
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?
Given no output schema, no annotations, and 2 parameters, the description lacks details on return values, error cases, and parameter behavior. It is insufficient for an agent to fully understand the tool's usage.
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 coverage is 0%, and the description adds no meaning to parameters. The 'deepdive' boolean parameter is not explained. The description only mentions 'statement' implicitly.
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 clearly states the verb 'fact-check', the resource 'a statement', and the specific engine 'Jina AI's grounding engine'. It distinguishes itself from sibling tools 'read_webpage' and 'search_web' by focusing on verification rather than retrieval.
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?
No guidance on when to use this tool versus alternatives. For instance, it does not clarify that fact-check should be used for verifying claims while search_web or read_webpage are for general information gathering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_webpageC
Extract content from a webpage in a format optimized for LLMs
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| format | No | ||
| no_cache | No | ||
| with_links | No | ||
| with_images | No | ||
| with_generated_alt | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks disclosure of caching, rate limits, error behavior, or format implications. 'Optimized for LLMs' is vague.
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?
Very concise single sentence but at cost of completeness. Front-loads purpose but does not earn its place with meaningful detail.
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?
Given 6 parameters, no output schema, and no annotations, the description is severely incomplete. Does not cover return values, parameter details, or behavioral aspects.
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 0%. Description does not explain any of the 6 parameters (e.g., format, no_cache, with_links). Fails to compensate for missing schema descriptions.
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?
Description clearly states verb 'extract', resource 'content from a webpage', and purpose 'optimized for LLMs'. It distinguishes from siblings like 'fact_check' and 'search_web'.
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?
No guidance on when to use vs siblings or when not to use. Lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_webC
Search the web using Jina AI's search API
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| query | Yes | ||
| retain_images | No | none | |
| return_format | No | markdown | |
| with_generated_alt | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It only states 'search the web' without disclosing behavioral traits like rate limits, result count limits, or idempotency. The minimal info does not cover core behavioral expectations.
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 a single sentence, which is concise but overly minimal. It lacks structure and does not effectively organize details; brevity here sacrifices completeness.
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?
Given 5 parameters, no output schema, no annotations, and sibling tools, the description is incomplete. It fails to explain return format, parameter effects, or differentiate from related tools, leaving significant gaps for an agent.
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?
The input schema has 5 parameters with 0% description coverage. The description adds no meaning beyond the schema fields. Parameters like 'count', 'retain_images', and 'return_format' are left unexplained, forcing the agent to guess their semantics.
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 clearly states the tool searches the web using Jina AI's API, identifying the verb and resource. However, it does not differentiate from sibling tools like fact_check or read_webpage, missing an opportunity to clarify scope.
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?
No guidance is provided on when to use this tool versus alternatives. The description lacks explicit context or exclusions, leaving the agent to infer usage independently.
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.
3 tool updates
v1.0.1- First observed
fact_check - First observed
read_webpage - First observed
search_web
TDQS
Scored across 3 tools
Each tool targets a distinct operation: fact-checking a statement, reading a webpage, and searching the web. No overlap in purpose.
All tool names follow a consistent verb_noun pattern using snake_case: fact_check, read_webpage, search_web.
With three tools, the set is well-scoped for a web and grounding server, covering the core tasks without extraneous tools.
The tool surface covers the essential workflow: search, retrieve, and verify. No obvious gaps given the server's apparent purpose.
Maintenance
Related MCP Connectors
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
An MCP server that integrates with Discord to provide AI-powered features.
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
Related MCP Servers
- AlicenseAqualityDmaintenanceAn MCP server that enables Claude to perform web searches using Perplexity's API with intelligent model selection based on query intent and support for domain and recency filtering.64MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that integrates with Sonar API to provide Claude with real-time web search capabilities for comprehensive research.7 npmMIT
- AlicenseDqualityFmaintenanceMCP server that provides Claude AI assistants with the ability to search the web, get news, and perform research using the You.com API.42MIT
- AlicenseNot gradedqualityBmaintenanceMCP server that bridges ChatGPT Plus/Pro to Claude Code, enabling chat, deep research, and image generation via your own account.172 PyPI50MIT