Jina AI Remote MCP Server

CLI version

A remote Model Context Protocol (MCP) server that provides access to Jina Reader, Embeddings and Reranker APIs with a suite of URL-to-markdown, web search, image search, and embeddings/reranker tools:

Optional tools work without an API key but have rate limits. For higher rate limits and better performance, use a Jina API key. You can get a free Jina API key from https://jina.ai

Usage

For client that supports remote MCP server:

{
  "mcpServers": {
    "jina-mcp-server": {
      "url": "https://mcp.jina.ai/v1",
      "headers": {
        "Authorization": "Bearer ${JINA_API_KEY}" // optional
      }
    }
  }
}

For client that does not support remote MCP server yet, you need mcp-remote a local proxy to connect to the remote MCP server.

{
  "mcpServers": {
    "jina-mcp-server": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.jina.ai/v1",
        "--header",
        "Authorization: Bearer ${JINA_API_KEY}"
      ]
    }
  }
}

For Claude Code:

claude mcp add -s user --transport http jina https://mcp.jina.ai/v1 \
  --header "Authorization: Bearer ${JINA_API_KEY}"

For OpenAI Codex: find ~/.codex/config.toml and add the following:

[mcp_servers.jina-mcp-server]
command = "npx"
args = [
    "-y",
    "mcp-remote",
    "https://mcp.jina.ai/v1",
    "--header",
    "Authorization: Bearer ${JINA_API_KEY}"]

Related MCP server: Sentinel Core Agent

Tool Filtering before Registering

Every MCP tool requires the LLM to pre-allocate tokens in its context window for the tool's name, description, and schema. For LLMs with limited context windows, registering all 22 tools can consume significant space before any actual work begins.

By filtering tools server-side via query parameters on the endpoint URL (/v1?...), excluded tools are never registered with the MCP client. The client and LLM never see them, saving context window for what matters.

Query Parameters

Available Tags

Precedence

Filters are applied in this order (highest to lowest priority):

1. exclude_tools - Always excludes specified tools

2. exclude_tags - Excludes tools in specified tags

3. include_tools - Includes specified tools

4. include_tags - Starts with only tools in specified tags

Examples

Exclude parallel tools (saves ~4 tools worth of context tokens):

{
  "mcpServers": {
    "jina-mcp-server": {
      "url": "https://mcp.jina.ai/v1?exclude_tags=parallel",
      "headers": {
        "Authorization": "Bearer ${JINA_API_KEY}"
      }
    }
  }
}

Only include search and read tools:

{
  "mcpServers": {
    "jina-mcp-server": {
      "url": "https://mcp.jina.ai/v1?include_tags=search,read",
      "headers": {
        "Authorization": "Bearer ${JINA_API_KEY}"
      }
    }
  }
}

Exclude specific tools:

{
  "mcpServers": {
    "jina-mcp-server": {
      "url": "https://mcp.jina.ai/v1?exclude_tools=search_images,deduplicate_images",
      "headers": {
        "Authorization": "Bearer ${JINA_API_KEY}"
      }
    }
  }
}

Troubleshooting

I got stuck in a tool calling loop - what happened?

This is a common issue with LMStudio when the default context window is 4096 and you're using a thinking model like gpt-oss-120b or qwen3-4b-thinking. As the thinking and tool calling continue, once you hit the context window limit, the AI starts losing track of the beginning of the task. That's how it gets trapped in this rolling context window.

The solution is to load the model with enough context length to contain the full tool calling chain and thought process.

I can't see all tools.

Some MCP clients have local caching and do not actively update tool definitions. If you're not seeing all the available tools or if tools seem outdated, you may need to remove and re-add the jina-mcp-server to your MCP client configuration. This will force the client to refresh its cached tool definitions. In LMStudio, you can click the refresh button to load new tools.

Claude Desktop says "Server disconnected" on Windows

Cursor and Claude Desktop (Windows) have a bug where spaces inside args aren't escaped when it invokes npx, which ends up mangling these values. You can work around it using:

{
  // rest of config...
  "args": [
    "mcp-remote",
    "https://mcp.jina.ai/v1",
    "--header",
    "Authorization:${AUTH_HEADER}" // note no spaces around ':'
  ],
  "env": {
    "AUTH_HEADER": "Bearer <JINA_API_KEY>" // spaces OK in env vars
  }
},

Cursor shows a red dot on this MCP status

Likely a UI bug from Cursor, but the MCP works correctly without any problem. You can toggle off/on to "restart" the MCP if you find the red dot annoying (fact is, since you are using this as a remote MCP, it's not a real "server restart" but mostly a local proxy restart).

My LLM never uses some tools

Assuming all tools are enabled in your MCP client but LLM still never uses some tools or favors some over others, this is pretty common when an LLM is trained with a specific set of tools. For example, we rarely see parallel_* tools being used organically by LLMs unless they are explicitly instructed to do so. Some research says LLMs must be trained to use parallel_*. Models like Qwen3-Next natively prefer to call the singleton version but with multiple queries in an array to achieve parallelism (which our MCP also support now). Either way, in Cursor, you can add the following rule to your .mdc file:

---
alwaysApply: true
---

When you are uncertain about knowledge, or the user doubts your answer, always use Jina MCP tools to search and read best practices and latest information. Use search_arxiv and read_url together when questions relate to theoretical deep learning or algorithm details. Use search_ssrn for social sciences, economics, law, and finance research. search_web, search_arxiv, and search_ssrn cannot be used alone - always combine with read_url or parallel_read_url to read from multiple sources. Remember: every search must be complemented with read_url to read the source URL content. For maximum efficiency, use parallel_* versions of search and read when necessary.

Why is my content truncated?

Claude Code, Claude Desktop, and Cursor enforce a fixed 25k token limit on MCP tool responses. To stop these clients from rejecting a large response outright, this server applies a token guardrail to read_url and parallel_read_url.

Items are kept whole in their original order while they fit. The first item that does not fit is cut to a prefix that does, and anything after it is dropped. A short [jina-mcp] ... note is appended saying what was truncated or omitted, so the model knows it is looking at a partial document rather than a complete one. At least one item always survives, even if that item alone is over budget.

The server deliberately aims under the limit rather than exactly at it. It has to: the server counts tokens with cl100k while the client counts with its own tokenizer, the cut is a proportional character estimate, and the client measures the serialized JSON payload rather than the raw text. On top of the token budget the server therefore enforces a hard ceiling of 3 bytes per allowed token, which holds regardless of tokenizer for both ASCII prose (~3.6 bytes/token) and CJK (~3 bytes/token). A rejected response delivers nothing, so erring low is the cheaper mistake.

Any client can set its own budget with max_tokens on the endpoint URL (for example https://mcp.jina.ai/v1?max_tokens=50000), and max_tokens=0 disables truncation entirely. Clients with configurable limits, such as OpenAI Codex (tool_output_token_limit), are otherwise left alone.

Using parallel tools vs singleton tools with arrays

Claude Code recently started preferring parallel_* tools (like parallel_search_web, parallel_read_url) for concurrent operations. However, models like Qwen3-Next prefer calling singleton tools with multiple queries in an array. Both approaches work: the singleton versions (search_web, search_arxiv, search_ssrn, read_url) accept either a single string or an array of strings for the query/url parameter. When given an array, these tools automatically execute all queries in parallel internally, producing the same concurrent behavior as explicitly calling parallel_* tools. Use whichever style your model prefers. Arrays are capped at 5 entries, the same limit the parallel_* tools enforce.

Why is the endpoint called /sse but using Streamable HTTP?

The /sse endpoint URL is kept for backward compatibility with existing users. The recommended endpoint is now /v1. Both use the same Streamable HTTP transport (the new MCP standard from spec 2025-03-26), not the deprecated SSE transport.

This works seamlessly because:

• Claude Desktop, Cursor, Windsurf use mcp-remote which defaults to http-first strategy (tries Streamable HTTP first)

• Claude Code has native support for both transports

• LM Studio supports direct connection to Streamable HTTP endpoints

The response streaming still uses SSE format (Content-Type: text/event-stream), but the protocol layer (session management, initialization) follows Streamable HTTP spec. All major MCP clients are compatible.

Client-side tool filtering with mcp-remote

If you're using mcp-remote as a local proxy, you can also filter tools client-side using its --ignore-tool flag:

{
  "mcpServers": {
    "jina-mcp-server": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.jina.ai/v1",
        "--header",
        "Authorization: Bearer ${JINA_API_KEY}",
        "--ignore-tool", "parallel_search_web",
        "--ignore-tool", "parallel_search_arxiv",
        "--ignore-tool", "parallel_read_url"
      ]
    }
  }
}

This approach filters tools at the proxy level before they reach the MCP client. However, server-side filtering via query parameters (see Tool Filtering) is more efficient as it reduces token usage from the source.

Reading a page with a question in mind

By default read_url returns the whole page, and the model pays for every token of it to answer one question. Pass question and the page is instead split into passages and scored with Reranker v3.5, and only the top-ranked passages come back — literally the same pipeline search_web_deep runs on its result pages, now available on a URL you already have.

All three are optional and question gates the other two, so existing calls are byte-for-byte unchanged.

// full page: 13,713 bytes, 233 ms
{ "url": "https://jina.ai/news/what-late-chunking-really-is-and-what-its-not-part-ii/" }

// one passage: 756 bytes (5.5%), 569 ms
{ "url": "https://jina.ai/news/what-late-chunking-really-is-and-what-its-not-part-ii/",
  "question": "Which embedding models support late chunking?", "topk": 2 }

A question-grounded response carries question, snippets and snippet_source: content, and omits content. When extraction cannot run — an empty page, an unreadable one, or no API key to rank with — the full body is returned with snippet_source: full_content and a note saying so, rather than a prefix masquerading as a ranked answer.

Three things worth knowing before tuning:

• The score doubles as a confidence signal. Asking a page a question it does not answer scores an order of magnitude lower than a genuine hit (measured: 0.02 against 0.51–0.81). A low top score means "this page does not say", not "ranking failed".

• Code blocks and tables are stripped before ranking. The chunker removes them along with nav furniture, which is what stops boilerplate from winning on lexical overlap. The trade-off is that install commands and spec tables are not eligible passages, so "how do I install X" is a weak fit for this parameter.

• Latency is roughly double a plain read, since the passage extraction runs alongside the fetch and adds a rerank call. parallel_read_url raises its own timeout floor to 60s when any entry has a question.

What is the difference between search_web and search_web_deep?

search_web returns the snippet the search engine picked — around 20 words, often a keyword-bearing fragment that never answers the question. search_web_deep also reads each page via Reader, splits it into ~100-word passages at sentence boundaries, and scores every passage from every page in one listwise Reranker call, so any page's passage can outrank any other's. snippet_source=auto (the default) enters each page's engine snippet as one more candidate and the snippet_source field on each result says which won; content never enters it and omits pages it could not read, so it may return fewer than num.

Top 5 per mode from the live server. Snippets keep their start and end, middle replaced by (...n chars...) so length stays visible:

English — what is the latest model from jina ai

Chinese — jina ai 最新的模型是什么

• The engine snippet is sometimes the better answer. The top three English auto results came back as serp — short, and the first answers the query more directly than any extracted passage, while content promotes jina.ai homepage navigation instead. Prefer auto unless something downstream needs full passages.

• The reranker scores relevance, not freshness. Both Chinese deep runs rank a 2023 jina-embeddings-v2 article first for a query asking which model is latest. Bound the window with tbs, or check each result's date.

• Passages are not uniformly ~100 words. Navigation-heavy pages lack the sentence punctuation to split on, so the first two English content results run to ~2,000 characters — the per-passage ceiling.

Developer Guide

Local Development

# Clone the repository
git clone https://github.com/jina-ai/MCP.git
cd MCP

# Install dependencies
npm install

# Start development server
npm run start

Deploy to Cloudflare Workers

This will deploy your MCP server to a URL like: jina-mcp-server.<your-account>.workers.dev/v1