MCP server

Search1API runs a hosted MCP server at:

https://mcp.search1api.com/mcp

Point an OAuth-aware MCP client at it and Search1API will advertise the authorization flow automatically. Clients that do not support OAuth discovery can continue using an API key. Either way, the model can search the web, read pages and check what's trending without you writing an integration.

Tools it exposes

Connect your client

OAuth 2.1 (preferred)

For a client that supports OAuth discovery, start with the endpoint only:

{
  "mcpServers": {
    "search1api": {
      "url": "https://mcp.search1api.com/mcp"
    }
  }
}

The exact outer configuration key varies by client, but the server URL is the same. On the first connection, the server returns a WWW-Authenticate challenge pointing to:

https://mcp.search1api.com/.well-known/oauth-protected-resource/mcp

The client can then discover Search1API's authorization server, dynamically register, and use Authorization Code + PKCE. The account owner signs in and approves access in the browser. A client that requests offline_access can refresh its access token for long-running sessions.

API key fallback

Create a key at dashboard.search1api.com, then use the configuration for your client. The dashboard's MCP page can generate these examples with the key filled in.

claude mcp add --transport http search1api https://mcp.search1api.com/mcp \
  --header "Authorization: Bearer YOUR_SEARCH1API_KEY"

{
  "mcpServers": {
    "search1api": {
      "url": "https://mcp.search1api.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_SEARCH1API_KEY"
      }
    }
  }
}

{
  "mcpServers": {
    "search1api": {
      "url": "https://mcp.search1api.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_SEARCH1API_KEY"
      }
    }
  }
}

{
  "servers": {
    "search1api": {
      "type": "http",
      "url": "https://mcp.search1api.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_SEARCH1API_KEY"
      }
    }
  }
}

{
  "mcpServers": {
    "search1api": {
      "serverUrl": "https://mcp.search1api.com/mcp?apiKey=YOUR_SEARCH1API_KEY"
    }
  }
}

https://mcp.search1api.com/mcp?apiKey=YOUR_SEARCH1API_KEY

Install via Smithery (optional)

Prefer a one-click install? Search1API is listed on Smithery, which supports 20+ MCP clients (Claude Code, Codex, Cursor, Windsurf, Gemini CLI, and more). A search1api agent skill is also available for hosts that support skills.

How auth works

The hosted server accepts either an OAuth access token or a Search1API API key in the Authorization: Bearer <credential> header. OAuth tokens and API keys use the same Search1API account credits, billing, and rate limits.

When no credential is present, the server returns a 401 challenge with its protected-resource metadata URL. Invalid or expired OAuth tokens return the same challenge with error="invalid_token", allowing a compatible client to refresh or repeat authorization.

For legacy clients that cannot send headers, the server also accepts an API key in the ?apiKey=<key> query parameter. The header wins when both are present.

Query-parameter auth means your key travels in a URL, where it can end up in logs and shell history. Prefer OAuth or a bearer header whenever the client supports one of them.

Protocol support

The hosted server implements the Model Context Protocol revision 2026-07-28, published on 28 July 2026. That revision removes protocol-level sessions and the initialize handshake: every request carries its own protocol version and client capabilities in _meta, and the server identifies itself in each result.

A request on 2026-07-28 needs two things beyond the ordinary JSON-RPC body:

• an Mcp-Method header matching the method in the body;
• a _meta object carrying io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientInfo, and io.modelcontextprotocol/clientCapabilities.

Call server/discover to read the supported versions, capabilities, and server identity before sending anything else:

curl -sS -X POST https://mcp.search1api.com/mcp \
  -H "Authorization: Bearer YOUR_SEARCH1API_KEY" \
  -H "Mcp-Method: server/discover" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "server/discover",
    "params": {
      "_meta": {
        "io.modelcontextprotocol/protocolVersion": "2026-07-28",
        "io.modelcontextprotocol/clientInfo": { "name": "my-client", "version": "1.0.0" },
        "io.modelcontextprotocol/clientCapabilities": {}
      }
    }
  }'

It answers with the supported revisions and the server identity:

{
  "result": {
    "supportedVersions": ["2026-07-28"],
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": { "listChanged": true }
    },
    "resultType": "complete",
    "_meta": {
      "io.modelcontextprotocol/serverInfo": {
        "name": "search1api-server",
        "version": "0.5.1"
      }
    }
  }
}

Swap the Mcp-Method header and the method field for tools/list and the same envelope returns the tools above.

Running it locally instead

The server also runs over stdio, straight from npm:

{
  "mcpServers": {
    "search1api": {
      "command": "npx",
      "args": ["-y", "search1api-mcp"],
      "env": {
        "SEARCH1API_KEY": "YOUR_SEARCH1API_KEY"
      }
    }
  }
}

The local stdio package currently uses an API key. There is no network hop to us for the MCP protocol itself, but its API calls still go to api.search1api.com.

Billing

MCP tool calls are ordinary API calls: they spend the same credits at the same rates as calling the endpoints yourself. See Credits and limits.

Source: github.com/superagents-lab/search1api-mcp