Skip to main content
Glama
x15907982411

exa-mcp-server-for-operit

by x15907982411
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

Exa MCP Server（Operit 适配版）

version license

本仓库是 exa-labs/exa-mcp-server v3.4.0 的 Operit 平台适配版。

原版 Exa MCP Server 用于将 Exa 的搜索能力（web search / code search / company research）接入 AI 助手；本适配版在保持全部功能不变的前提下，修复了 Exa MCP 与 Operit 平台（旧版 Kotlin MCP SDK / Zod schema 校验）握手失败的问题，使 web_search_exa / web_fetch_exa 等工具可在 Operit 中稳定加载与调用。

为什么需要适配（背景）

Operit 使用的 MCP 客户端 SDK 版本较旧，其 Zod 校验要求 serverInfo 响应中不允许出现 icons 字段：

现象

原因

MCP 插件一直"卡在加载"

客户端发起 initialize 后，服务端返回的 serverInfo 携带 icons，旧 SDK 校验报 invalid_type，握手失败

工具列表拉不到 / 工具不可用

握手未完成，tools/list 无法正常返回

本仓库将 src/stdio.ts 中 McpServer 构造参数的 icons 字段移除，并使源码与构建产物（dist/stdio.cjs）保持一致，构建可复现。

注：dist/stdio.cjs 中仍保留 SDK 库内部的 IconSchema/IconsSchema 定义（用于校验客户端传入字段的 schema 声明），这与 serverInfo 响应中的 icons 无关，不影响兼容性。

Related MCP server: Exa MCP Server

与原仓库的差异（全部）

文件

修改

说明

src/stdio.ts

移除 McpServer 的 icons 参数

兼容 Operit 旧 SDK 的 Zod 校验（修复根因）

src/stdio.ts / package.json

版本号 3.4.0 → 3.4.0-operit.1

发布版本可识别，serverInfo 回显该版本

除此之外，工具集、API、skills、测试、Dockerfile、vercel 配置等均与上游 v3.4.0 完全一致。

快速开始

1. 构建（可复现）

npm ci                    # 安装依赖（国内可换 npmmirror 加速：npm config set registry https://registry.npmmirror.com）
npm run build:stdio       # esbuild 打包 → dist/stdio.cjs（自包含，约 2.2MB）

⚠️ npm 11+ 默认阻止 postinstall 脚本，若报 esbuild: command not found，执行：

npm approve-scripts esbuild   # 或 npm approve-builds
node node_modules/esbuild/install.js

2. 验证握手（initialize）

node dist/stdio.cjs <<'EOF'
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}
EOF

预期 serverInfo 响应（无 icons 字段）：

{
  "name": "exa-search-server",
  "title": "Exa",
  "version": "3.4.0-operit.1",
  "websiteUrl": "https://exa.ai"
}

3. 部署到 Operit

  1. 将本仓库（或仅 dist/ 目录）放入 Operit 的 MCP 插件目录：

    • Android 源目录：/sdcard/Download/Operit/mcp_plugins/<pluginId>/

    • Linux 运行目录：~/mcp_plugins/<shortName>/（含 dist/stdio.cjs）

  2. 在 mcp_config.json 注册（示例）：

{
  "mcpServers": {
    "exa": {
      "command": "node",
      "args": ["dist/stdio.cjs"],
      "env": {
        "EXA_API_KEY": "<your-exa-api-key>",
        "EXA_TOOL_ENABLES": "web_search_exa,web_fetch_exa"
      }
    }
  }
}

  1. 重启 MCP 服务（Operit 内触发 restart_mcp_with_logs），验证 ping_mcp 可列出工具。

可用工具

  • web_search_exa — 默认启用，Exa 语义搜索

  • web_fetch_exa — 默认启用，任意 URL 转 Markdown

  • web_search_advanced_exa 等高级工具 — 需在 EXA_TOOL_ENABLES 中追加工具名后启用

详见上游 Full Documentation。

详细适配说明

构建细节、踩坑记录与适配前后对比见 README-OPERIT.md。

上游信息

License

MIT — 保留上游 exa-labs/exa-mcp-server 版权声明，详见 LICENSE。

Available Tools

2 tools
web_fetch_exaA
Read-onlyIdempotent

Read a webpage's full content as clean markdown. Use after web_search_exa when highlights are insufficient or to read any URL.

Best for: Extracting full content from known URLs. Batch multiple URLs in one call. Returns: Clean text content and metadata from the page(s).

ParametersJSON Schema
NameRequiredDescriptionDefault
urlsNoURLs to read. Batch multiple URLs in one call.
maxCharactersNoMaximum characters to extract per page (default: 3000)

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds behavioral context beyond annotations, such as the ability to batch multiple URLs in one call and the return of clean text plus metadata.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose. It uses a clear structure with 'Best for' and 'Returns' sections, and each sentence serves a distinct purpose without unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a relatively simple read-only tool, the description covers the essential context: what it does, when to use it, batching capability, and return value type. The annotations handle safety, and the schema covers parameters, leaving no significant gaps for an agent to select and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (urls and maxCharacters) are fully documented in the schema. The description reinforces batching behavior for the urls parameter but adds no new semantic details beyond the schema.

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 'Read a webpage's full content as clean markdown', which is a specific verb+resource combination. It also distinguishes itself from sibling web_search_exa by focusing on fetching full content from URLs rather than searching.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use after web_search_exa when highlights are insufficient or to read any URL', providing a direct usage context and alternative. The 'Best for' note further clarifies when to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

web_search_exaA
Read-onlyIdempotent

Search the web for any topic and get clean, ready-to-use content.

  Best for: Finding current information, news, facts, people, companies, or answering questions about any topic.
  Returns: Clean text content from top search results.

  Query tips:
  describe the ideal page, not keywords. "blog post comparing React and Vue performance" not "React vs Vue".
  Use category:people / category:company to search through Linkedin profiles / companies respectively.
  If highlights are insufficient, follow up with web_fetch_exa on the best URLs.
ParametersJSON Schema
NameRequiredDescriptionDefault
queryNoNatural language search query. Should be a semantically rich description of the ideal page, not just keywords. Optionally include category:<type> (company, people) to focus results — e.g. 'category:people John Doe software engineer'.
numResultsNoNumber of search results to return (default: 10).

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds behavioral/return context: 'Returns: Clean text content from top search results' and query tips describing ideal-page phrasing. No contradiction with annotations.

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?

Description is multi-paragraph but well-structured with labeled sections (Best for, Returns, Query tips) and front-loaded with the core purpose. It's slightly longer than minimal, but each section provides useful operational guidance without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter search tool with no output schema, the description covers the use case, return format, query strategy, and the relationship to web_fetch_exa. It doesn't specify pagination or error behavior, but that's not required given the tool's simplicity and annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers both parameters with descriptions (100% coverage), so baseline is 3. The description adds extra semantics for the query parameter: examples of natural language phrasing and category:people/category:company syntax, which goes beyond the schema's property description.

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 opens with 'Search the web for any topic and get clean, ready-to-use content' – a specific verb+resource+outcome. It also distinguishes from the sibling web_fetch_exa by explicitly mentioning follow-up with that tool on URLs, clarifying that this tool searches rather than fetches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names 'Best for' use cases (current information, news, facts, people, companies) and gives direct alternative guidance: 'If highlights are insufficient, follow up with web_fetch_exa on the best URLs.' This clearly tells when to use this tool versus the sibling.

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. 2 tool updatesv3.4.0-operit.1
    • First observedweb_fetch_exa
    • First observedweb_search_exa
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

Scored across 2 tools

Disambiguation5/5

web_search_exa and web_fetch_exa have clearly distinct purposes: one searches the web and returns highlights, the other fetches full page content. There is no overlap in functionality, and their complementary nature is explicitly described.

Naming Consistency5/5

Both tools follow the same verb_noun pattern with a consistent shared prefix: web_search_exa and web_fetch_exa. The naming is predictable and reflects the action each tool performs.

Tool Count4/5

Two tools is minimal but appropriate for a server focused on web search and retrieval. The pair forms a complete workflow (search then fetch), and adding more tools for a simple utility like this could be overkill. The count feels slightly thin but not insufficient for the stated purpose.

Completeness4/5

The server covers the core lifecycle of web content retrieval: searching for relevant pages and fetching full content from known URLs. Minor gaps exist, such as no findSimilar or advanced filtering, but the essential use case is fully supported.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

  • exaA
    ai.exa

    Fast, intelligent web search and web crawling. New mcp tool: Exa-code is a context tool for coding

    SearchWeb ScrapingDeveloper Tools
    294,963
  • Remote MCPA
    com.remote-mcp.mcp

    The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.

    Developer ToolsSearchAgent Orchestration
    13
  • OpenRouterAOAuth
    ai.openrouter.mcp

    The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.

    AI & Machine Learning
    221
  • ExaA
    io.github.pipeworx-io

    Exa MCP — neural/semantic web search + content retrieval (exa.ai)

    SearchRAG Systems
    342

Related MCP Servers

  • ReActMCP Web Search

    mshojaei77
    A
    license
    Not graded
    quality
    C
    maintenance
    An MCP server that integrates real-time web search capabilities into AI assistants using the Exa API, providing both basic and advanced search functionality with formatted markdown results.
    143
    MIT

  • Exa MCP Server

    MrunmayS
    F
    license
    A
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI assistants like Claude to perform real-time web searches using the Exa AI Search API in a safe and controlled manner.
    2
    19,692
    -

  • mcp-exa

    daedalus
    A
    license
    B
    quality
    C
    maintenance
    Exposes the Exa web search API as an MCP server, providing tools for web searching, content retrieval, and similar page discovery. It also supports advanced features like AI-generated answers and automated research task management.
    9
    MIT