MCP Reference
MCP Authentication
How the SearchX MCP server authenticates requests, and the security model behind it.
Credentials
You need two values from the dashboard at admin.searchxengine.ai:
- API key: from your application's API Keys section.
- Application ID: your application's unique id, shown on the same page.
Keys are application-scoped
Each API key belongs to a single application, so the key alone identifies which catalog the assistant searches. Treat it like a password, since anyone with it can search that catalog. Regenerate it from the dashboard if it leaks.
Headers
Every connection sends two headers:
| Header | Value |
|---|---|
Authorization | Bearer <your API key> |
X-SearchX-App-Id | <your application id> |
The key is the trust boundary; the application id is a fail-fast cross-check, so the API verifies it matches the key's application and rejects a mismatch.
Clients without custom headers
If your client can only send a single bearer token (for example, the Claude Messages API connector), pass the application id in the URL query instead: https://mcp.searchxengine.ai/mcp?app_id=YOUR_APP_ID.
Errors
| Status | Meaning |
|---|---|
401 | Missing or invalid API key. |
403 | The key is valid but does not match the provided application id, or the application is suspended. |
429 | Rate limit exceeded. Retry after the Retry-After interval. |
Security model
- The API key is the only trust boundary. It is application-scoped and forwarded to the SearchX API, which enforces the same per-organization access and rate limiting as the SDK. The MCP server stores no secrets of its own.
- No direct data access. It only calls the authenticated SearchX API, never your database or the search engine directly.
- Nothing leaks. Internal fields are removed before any result reaches the model.
- Per-application. Each key reaches only its own application's catalog. To search multiple catalogs, connect each application's key separately.