Which integrations are available for this server?

Enables GitHub Copilot to perform web3-focused web searches via the OptimAI External Search API, providing tools to start, retrieve, list, and cancel searches.

How do I use OptimAI Search MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OptimAI Search MCP search for latest DeFi trends on Ethereum" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

OptimAI Search MCP

Official

by OptimaiNetwork

Overview Schema Related Servers Score Discussions

TypeScript

Remote

@optimai-network/search-mcp

MCP (Model Context Protocol) server that wraps the OptimAI External Search API, enabling any MCP-compatible AI host to run Web3-focused web searches.

Tools

Tool	Description
`optimai_start_search`	Start a search and return the search ID immediately. Searches commonly take 60-90 seconds; call `optimai_get_search` with the ID to fetch progress/results.
`optimai_search`	Convenience search that waits briefly for results. If still running, returns the search ID for `optimai_get_search`.
`optimai_get_search`	Fetch current status/result of a past search by ID
`optimai_list_searches`	List recent searches (filterable by status, date)
`optimai_cancel_search`	Cancel a running or pending search

Related MCP server: qsearch

Setup

Environment variables

Variable	Required	Description
`OPTIMAI_API_KEY`	✅	Your OptimAI External API key (`X-API-Key`)

Create or manage API keys at https://search.optimai.network/api-keys.

The API base URL is hardcoded to https://api-onchain.optimai.network.

MCP Integrations

Codex CLI

export OPTIMAI_API_KEY="sk-..."

codex mcp add optimai-search \
  --env OPTIMAI_API_KEY="$OPTIMAI_API_KEY" \
  -- npx -y @optimai-network/search-mcp

Then restart Codex and run /mcp to confirm optimai-search is enabled.

Claude Desktop, Cursor, and other stdio hosts

For a published npm install, add this to your MCP host configuration:

{
  "mcpServers": {
    "optimai-search": {
      "command": "npx",
      "args": ["-y", "@optimai-network/search-mcp"],
      "env": {
        "OPTIMAI_API_KEY": "sk-your-key-here"
      }
    }
  }
}

Claude Desktop uses the same format in ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows.

Cursor can use the same format in .cursor/mcp.json in your project or in the global Cursor MCP config.

GitHub Copilot CLI

You can add the server interactively with /mcp add, or edit ~/.copilot/mcp-config.json:

{
  "mcpServers": {
    "optimai-search": {
      "type": "local",
      "command": "npx",
      "args": ["-y", "@optimai-network/search-mcp"],
      "env": {
        "OPTIMAI_API_KEY": "sk-your-key-here"
      },
      "tools": ["*"]
    }
  }
}

GitHub Copilot cloud agent

Add an environment secret or variable named COPILOT_MCP_OPTIMAI_API_KEY, then add this MCP configuration in the repository's Copilot cloud agent settings:

{
  "mcpServers": {
    "optimai-search": {
      "type": "local",
      "command": "npx",
      "args": ["-y", "@optimai-network/search-mcp"],
      "env": {
        "OPTIMAI_API_KEY": "$COPILOT_MCP_OPTIMAI_API_KEY"
      },
      "tools": [
        "optimai_start_search",
        "optimai_get_search",
        "optimai_list_searches"
      ]
    }
  }
}

Use tools: ["*"] if you want to expose every tool, including optimai_search and optimai_cancel_search.

Smoke Test (MCP Inspector)

OPTIMAI_API_KEY=sk-... npx @modelcontextprotocol/inspector npx -y @optimai-network/search-mcp

Tests

npm test

npm test only starts the MCP server and validates the tool schema. It does not call live OptimAI API tools.

To intentionally run a live backend smoke test:

OPTIMAI_API_KEY=sk-... npm run test:live

Architecture Notes

Recommended reliable flow: optimai_start_search creates a search and returns immediately with an ID. Use optimai_get_search to check progress and retrieve the completed answer.
Blocking convenience flow: optimai_search creates a search then polls GET /:id every 2s until terminal status or local timeout. It defaults to 45s and is capped at 55s to stay below common MCP client request timeouts.
Future streaming: src/client.ts has a TODO: streamSearch() stub. Upgrading to SSE only requires implementing that method and adding a new optimai_search_stream tool — the blocking tool is unaffected.
Auth: API key is read from env at startup. Never logged or exposed in tool responses.

Available Tools

5 tools

optimai_cancel_searchA

Cancel a running or pending search by its ID. Completed, failed, or already-cancelled searches cannot be cancelled.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The search ID to cancel

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It provides the behavioral constraint that only running/pending searches can be cancelled, which is useful. However, it doesn't disclose what happens on success, failure, or whether cancellation is irreversible, leaving some gaps.

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 a single, direct sentence with no redundant words or fluff. It conveys the action and key constraint efficiently.

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 1-parameter tool with no output schema, the description covers the action and key state constraint. It doesn't describe return values or error handling, but given the low complexity, this is adequate and mostly complete.

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?

The schema documents the single parameter 'id' fully ('The search ID to cancel'). The description adds no additional meaning beyond the schema, so the baseline score of 3 applies due to 100% schema coverage.

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 uses a specific verb 'cancel' and identifies the resource as a search by ID. It clearly distinguishes from sibling tools like optimai_search, optimai_get_search, optimai_list_searches, and optimai_start_search.

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

Usage Guidelines4/5

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

It states the tool applies to running or pending searches and explicitly lists non-cancellable states (completed, failed, already-cancelled), giving clear applicability boundaries. It doesn't mention alternatives but the context is sufficient for when to use this tool.

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

optimai_get_searchA

Retrieve the current status and result of a previously created search by its ID. Useful for checking on a search that was started earlier or is still in progress.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The search ID returned by optimai_search or optimai_list_searches

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the transparency burden. It communicates a read-only nature via 'retrieve' and notes it returns 'status and result', but does not explicitly state non-destructive behavior, error handling, or whether the response is immediate. This is minimal but adequate for a simple retrieval tool.

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?

Two sentences, front-loaded with the primary purpose, and no wasted words. The second sentence adds practical usage context, earning a perfect score.

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 single-parameter, no-output-schema tool, the description is sufficiently complete. It explains what the tool does and when to use it, and hints at polling behavior for in-progress searches. It does not specify response format or error scenarios, but these are less critical given the simple scope.

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 coverage is 100%, and the schema already describes the 'id' parameter as the search ID returned by optimai_search or optimai_list_searches. The description's phrase 'by its ID' adds no new semantic detail, so the baseline of 3 is appropriate.

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 tool retrieves the current status and result of a previously created search by ID. It uses specific verbs ('retrieve') and identifies the resource ('search'), effectively distinguishing it from sibling tools like optimai_search, optimai_list_searches, and optimai_cancel_search.

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

Usage Guidelines4/5

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

The description provides clear context: it's useful for checking a search that was started earlier or is still in progress. It implies when to use this tool over listing all searches, though it does not explicitly name alternatives or exclusions.

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

optimai_list_searchesA

List recent searches made with this API key. Supports filtering by status, date range, and pagination.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Number of results to return (1–100, default 10)
`offset`	No	Pagination offset (default 0)
`status`	No	Filter by search status
`created_after`	No	ISO 8601 datetime — only return searches created after this
`created_before`	No	ISO 8601 datetime — only return searches created before this

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full transparency burden. It clearly indicates a read-only listing operation ('List recent searches made with this API key') but does not disclose additional behavioral details such as ordering of results, whether full search objects or summaries are returned, or any API-specific constraints beyond the API key scoping.

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 exactly two sentences, front-loads the core action ('List recent searches'), and uses no unnecessary words. It efficiently conveys the essential operation and the key supported filtering options.

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?

The description covers the core purpose, resource scope, and filtering/pagination capabilities. However, without an output schema, it does not specify the return format or ordering, and it does not explicitly distinguish itself from optimai_get_search beyond the plural vs. singular contrast. Still, for a straightforward list endpoint, the information is sufficient for selection and invocation.

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?

All five parameters are documented with descriptions in the input schema, achieving 100% coverage, so the baseline is 3. The description's summary of 'filtering by status, date range, and pagination' adds no new semantic detail beyond what the schema already provides for each parameter.

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 uses the specific verb 'List' with the resource 'recent searches' and scopes it to 'this API key', making the operation unambiguous. It also mentions filtering by status, date range, and pagination, which clearly distinguishes this from sibling tools like optimai_search, optimai_get_search, optimai_cancel_search, and optimai_start_search.

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

Usage Guidelines4/5

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

The description establishes a clear context for use: listing recent searches for the current API key. While it does not explicitly name alternatives (e.g., 'use optimai_get_search for a single search'), the plural 'searches' and the mention of pagination and filtering implicitly differentiate it from the single-search retrieval tool.

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

optimai_searchA

Run a Web3-focused AI search on the OptimAI decentralised network. Waits briefly for results and returns a structured answer with citations when ready. If the search is still running, it returns the search ID so optimai_get_search can fetch it later. Use this when the user wants up-to-date information about crypto, DeFi, NFTs, blockchain projects, or any on-chain topic.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	The search query to run on the OptimAI network
`timeout_seconds`	No	Max seconds to wait for results (10-55, default 45)
`poll_interval_ms`	No	Polling interval in ms (default 2000)

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and does well by disclosing key behaviors: it 'waits briefly for results,' returns a 'structured answer with citations when ready,' and returns the search ID if the search is still running. This goes beyond a simple statement of action and gives the agent important expectations about response patterns.

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?

Three sentences, front-loaded with the primary action, then behavioral detail, then usage guidance. Every sentence earns its place with no redundancy or padding.

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?

The tool has moderate complexity and no output schema, so the description must explain return values—and it does, covering both the ready-result case (structured answer with citations) and the async case (search ID). It also references the logical follow-up tool. It could be even more explicit about error conditions or the exact shape of citations, but the core is covered.

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 coverage is 100%, so the schema already documents all three parameters with meaningful descriptions. The tool description adds minimal extra meaning about parameters themselves; it only frames the query as Web3-focused. This meets the baseline for schema-heavy coverage but doesn't go further.

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 a specific verb and resource: 'Run a Web3-focused AI search on the OptimAI decentralised network.' It clearly differentiates from siblings by explaining its wait-and-return behavior and how it relates to optimai_get_search, making the tool's unique role obvious.

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

Usage Guidelines4/5

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

The description provides clear usage context: 'Use this when the user wants up-to-date information about crypto, DeFi, NFTs, blockchain projects, or any on-chain topic.' It also implicitly contrasts with optimai_get_search by noting that if the search is still running, it returns the search ID for later fetching. However, it doesn't explicitly state when NOT to use this tool or mention alternatives like optimai_start_search.

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

optimai_start_searchA

Start a Web3-focused AI search on the OptimAI decentralised network and return immediately with a search ID. Use this because searches commonly take 60-90 seconds or the MCP host has short tool-call timeouts. Call optimai_get_search with the returned ID to check progress and fetch the final answer.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The search query to start on the OptimAI network

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the tool is asynchronous (returns immediately), provides a search ID for polling, and notes the expected search duration. This is strong behavioral context, though it omits details like ID expiration or error conditions.

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?

Two tightly worded sentences. The first states purpose and outcome; the second explains why and what to do next. No filler, all information earns its place.

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 one-parameter async tool, the description covers the key behavioral flow: start, get ID, poll with get_search. It lacks an explicit return field name (e.g., 'search_id') and error-handling notes, but these are minor given the tool's low complexity.

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?

The single parameter 'query' is already well-documented in the schema (100% coverage). The description adds Web3/decentralized context but does not materially expand on the schema's 'The search query to start on the OptimAI network'. Baseline 3 is appropriate.

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 uses a specific verb ('Start'), identifies the resource ('Web3-focused AI search on the OptimAI decentralised network'), and clarifies the immediate outcome ('return immediately with a search ID'). This clearly distinguishes it from sibling tools like optimai_get_search, which fetches results.

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?

The description explicitly states when to use this tool ('searches commonly take 60-90 seconds or the MCP host has short tool-call timeouts') and directs the user to the next step ('Call optimai_get_search with the returned ID'). This provides clear context and a named alternative, satisfying the highest bar.

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. Dates show when Glama detected each change.

5 tool updatesv0.1.1Aug 7, 2026
- First observedoptimai_cancel_search
- First observedoptimai_get_search
- First observedoptimai_list_searches
- First observedoptimai_search
- First observedoptimai_start_search

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation2/5

The tools optimai_search and optimai_start_search are nearly identical in purpose: both initiate a search and return a search ID if the search is not complete. The only difference is that optimai_search waits briefly for results, but in typical long-running searches, they behave the same. This overlap creates significant ambiguity for an agent deciding which tool to use.

Naming Consistency4/5

The naming pattern is mostly consistent with the optimai_ prefix and verb_noun structure: get_search, list_searches, cancel_search, start_search. However, optimai_search is a bare verb and does not follow the verb_noun pattern, standing out as a deviation. This is a minor inconsistency but does not severely hinder readability.

Tool Count5/5

Five tools is well-scoped for a search API, covering initiation, retrieval, listing, and cancellation without unnecessary bloat. Each tool serves a distinct lifecycle function, and the count feels appropriate for the domain.

Completeness5/5

The tool set provides complete lifecycle coverage for asynchronous searches: start a search (start_search, or the combined optimai_search), check status/results (get_search), list past searches (list_searches), and cancel in-progress ones (cancel_search). No important operations are missing, and the composite optimai_search covers the synchronous wait case.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

MESSORA A
dev.messora
Scrape, crawl and search the web for AI agents via MCP.
Web Scraping Browser Automation Search
51
seltz-ai-seltz-mcpOAuth
ai.seltz
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Search Browser Automation Web Scraping
2
Not Human Search A
ai.nothumansearch
Search the agentic web. 4,100+ sites, 11 tools incl. check_url + verify_mcp for probe-before-use.
Search Browser Automation Web Scraping
143
pixserp A
com.pixserp
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
Search Browser Automation
12

Related MCP Servers

websearch-skill
Search Web Scraping Browser Automation
hec-ovi
A
license
A
quality
B
maintenance
Enables AI agents to perform multi-engine web search, fetch web pages, and extract clean Markdown content via MCP, with no API keys required.
Updated 24 days ago (2026-08-13 14:14 UTC)
3
5
MIT
qsearch
Search RAG Systems Knowledge & Memory
theYahia
A
license
Not graded
quality
B
maintenance
Enables AI agents to perform web searches with full content retrieval and multi-engine provenance, including trust scoring and local corpus persistence, via MCP integration.
Updated 3 days ago (2026-09-03 04:54 UTC)
3
2
Apache 2.0
agent-web-search-mcp
Search Web Scraping Browser Automation
blueewhitee
F
license
A
quality
C
maintenance
Enables MCP-compatible agents to perform web searches via the agent-web-search engine, returning ranked results with sources.
Updated a month ago (2026-08-01 16:37 UTC)
1
-
mcp-web-search-server
Search Browser Automation Web Scraping
am24check
A
license
Not graded
quality
C
maintenance
Enables MCP clients to perform web searches and fetch web pages over HTTP, using Exa and Parallel AI as search providers without requiring API keys.
Updated 16 days ago (2026-08-21 13:21 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/OptimaiNetwork/optimai-search-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server