Skip to main content
Glama

지나 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: 로컬 설치

  1. 저장소를 복제합니다

  2. 종속성 설치:

npm install
  1. 서버를 빌드하세요:

npm run build
  1. Claude 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.json

Windows의 경우:

%APPDATA%/Claude/claude_desktop_config.json

디버깅

MCP 서버는 stdio를 통해 통신하므로 디버깅이 어려울 수 있습니다. MCP Inspector 사용을 권장합니다.

npm run inspector

검사기는 브라우저에서 디버깅 도구에 액세스할 수 있는 URL을 제공합니다.

API 응답 유형

모든 도구는 다음을 포함하는 구조화된 JSON 응답을 반환합니다.

  • 상태 코드 및 메타데이터

  • 요청된 출력 유형에 따라 형식화된 콘텐츠

  • 사용 정보(토큰 수)

  • 해당되는 경우: 이미지, 링크 및 추가 메타데이터

자세한 스키마 정보는 schemas.ts 참조하세요.

Available Tools

3 tools
fact_checkC

Fact-check a statement using Jina AI's grounding engine

ParametersJSON Schema
NameRequiredDescriptionDefault
deepdiveNo
statementYes

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
formatNo
no_cacheNo
with_linksNo
with_imagesNo
with_generated_altNo

TDQS

C2.6/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
countNo
queryYes
retain_imagesNonone
return_formatNomarkdown
with_generated_altNo

TDQS

C2.4/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters1/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

  1. 3 tool updatesv1.0.1
    • First observedfact_check
    • First observedread_webpage
    • First observedsearch_web

TDQS

B3.3/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct operation: fact-checking a statement, reading a webpage, and searching the web. No overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: fact_check, read_webpage, search_web.

Tool Count5/5

With three tools, the set is well-scoped for a web and grounding server, covering the core tasks without extraneous tools.

Completeness5/5

The tool surface covers the essential workflow: search, retrieve, and verify. No obvious gaps given the server's apparent purpose.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers