Jina AI Remote MCP Server: 22 Tools Behind One Hosted Endpoint

The problem: retrieval tools eat context before the model does any work

An MCP client registers every tool a server advertises. Each registration costs tokens: the tool name, its description, and its JSON schema all sit in the context window before the first user message. The README states this plainly, noting that registering all 22 tools can consume significant space for models with limited context windows. That is the problem this project addresses, and it addresses it in two ways. First, the heavy lifting (page extraction, web search, embeddings, reranking) happens on Jina's infrastructure, so the client carries no scraping or vector code. Second, tools can be filtered server-side through query parameters on the endpoint URL, so excluded tools are never registered with the client at all. The audience is anyone wiring an MCP-capable assistant to live web content: coding agents that need to read documentation pages, research assistants that need arXiv or SSRN, and pipelines that need reranking or deduplication over text and images.

What the 22 tools actually do, and which ones need a key

The tool table splits into three groups by backing API. Reader-backed tools handle the web: read_url converts a page to markdown, capture_screenshot_url takes screenshots, guess_datetime_url infers last-update or publish dates with confidence scores, and search_web, search_arxiv, search_ssrn, search_images and expand_query all route through Reader. Reranker-backed tools include sort_by_relevance and the passage-scoring step inside search_web_deep. Embeddings-backed tools are classify_text, deduplicate_strings and deduplicate_images, the last two using submodular optimization to pick semantically unique items. A separate set needs no key at all: primer, guess_datetime_url, search_jina_blog and search_bibtex. The parallel_ variants (parallel_read_url, parallel_search_web, parallel_search_arxiv, parallel_search_ssrn) fan out the same operations concurrently. The most interesting entry is search_web_deep, which the README describes as searching the web, reading each result page, then scoring every passage against the query in one listwise Reranker call using jina-reranker-v3.5, returning the best paragraph-length passage from each page. The stated latency is typically 2 to 20 seconds. That is a real cost, and it is the honest number to plan around.

Architecture: one hosted endpoint, Streamable HTTP, /sse kept as an alias

This is a remote server, not a local process. The client points at https://mcp.jina.ai/v1 and the tool execution happens on Jina's side. The README notes the server uses Streamable HTTP transport under MCP spec 2025-03-26, and that the /sse endpoint is retained as an alias for backward compatibility. The project ships a FAQ entry explaining why the endpoint is still called /sse while using Streamable HTTP, which suggests the naming has caused confusion. Authentication is a Bearer token in the Authorization header, and the README marks it optional in the JSON config, matching the tool table where several tools work without a key but face rate limits. Tool filtering sits in the URL itself: exclude_tools, include_tools, exclude_tags and include_tags are comma-separated query parameters appended to /v1. Because filtering happens before registration, the client and the model never see the removed tools. That is a cleaner mechanism than client-side allowlists, which typically still pay the schema cost.

Getting it running: three config shapes and one Claude Code command

For clients with native remote MCP support, the config is a url plus an optional header block: mcpServers.jina-mcp-server with url https://mcp.jina.ai/v1 and headers.Authorization set to Bearer ${JINA_API_KEY}. For clients without remote support, the README points to mcp-remote as a local proxy, configured with command npx, args mcp-remote https://mcp.jina.ai/v1 --header "Authorization: Bearer ${JINA_API_KEY}". Claude Code gets a single command: claude mcp add -s user --transport http jina https://mcp.jina.ai/v1 --header "Authorization: Bearer ${JINA_API_KEY}". OpenAI Codex uses ~/.codex/config.toml with an [mcp_servers.jina-mcp-server] table that also shells out through npx -y mcp-remote. Two warnings in the README matter operationally. Some clients do not support environment variables, so ${JINA_API_KEY} must be replaced with a literal jina_ key, which means the secret sits in a config file. And anyone upgrading from the old /sse setup must run claude mcp remove -s user jina before re-adding with --transport http.

Where it breaks: key handling, latency, and the wrong-client case

The env-variable warning is the sharpest edge. If your client cannot interpolate ${JINA_API_KEY}, you hardcode a real key into a JSON or TOML file, and that file may be synced, committed, or shared. There is no mention of an alternative such as a secrets manager integration. The second limit is latency. search_web_deep is documented at 2 to 20 seconds because it reads every result page before scoring; an agent that calls it in a loop will feel that. The parallel_ tools exist precisely to compress that, but they multiply the number of upstream requests rather than removing the wait. Third, this is the wrong tool if you need an offline or air-gapped setup: every tool call leaves your machine for Jina's infrastructure, so page content, queries and PDFs go to a third party. Teams with data residency rules or confidential documents should treat that as a blocker, not a configuration detail. Finally, the optional tools still hit rate limits without a key, so a keyless deployment is viable for demos and unreliable for production volume.

The self-hosted alternative, and what changes if you pick it

The obvious alternative is a local MCP server that runs the retrieval stack on your own machine, for example a fetch or filesystem server paired with a self-hosted search index and a local embedding model. The difference is not features, it is where the work happens. A self-hosted setup keeps page content on your hardware and has no per-call rate limit, but you own the scraper, the JavaScript rendering problem, the embedding model, the reranker, and the index refresh. Jina's server collapses all of that into one URL and one key, at the cost of network dependency and third-party data flow. There is also a middle path visible in the repository: jina-ai/cli is linked from the README as a CLI version, which suggests the same capabilities are reachable without an MCP client at all. If your use case is a script rather than an agent, that link is worth following before you adopt the server.

Licence, maintenance and what the repository does not tell you

The code is Apache-2.0, which permits commercial use, modification and redistribution with the usual notice and patent-grant terms; it does not grant rights to the Jina APIs themselves, which are a separate service governed by Jina's own terms and rate limits. That distinction matters: the licence covers the server code, not the retrieval capacity behind it. On maintenance, the repository is not archived and the last push shown is 2026-08-26, with no releases retrieved in the material provided. That absence is worth noting rather than interpreting: a project can be actively pushed without tagged releases, and this one has no release history to read. The README also does not state whether the server can be self-hosted from this repository, what the uptime expectation for mcp.jina.ai is, or how the include_tags and exclude_tags parameters map to the individual tools, since the parameter table is truncated in the supplied material. Verify the tag names against the live endpoint before you rely on tag-based filtering in a config.

Editorial conclusion

Adopt jina-ai/MCP if your client speaks Streamable HTTP or can run mcp-remote, and if you want web reading, search and reranking without hosting retrieval infrastructure. Skip it if you need an offline or self-hosted MCP server, or if you cannot send page content to a third party. Before rolling it out, verify three things: that your client accepts the Authorization header rather than requiring a hardcoded key, which of the 22 tools need a Jina API key, and whether the server-side include_tools or exclude_tools filter trims the tool list far enough for your model's context window.

Official sources

1. Issues
2. jina-ai/MCP on GitHub
3. License: Apache-2.0
4. Project website
5. README