Hosted OpenSearch MCP: query your logs from any MCP-compatible AI assistant

You have a timeout in your application logs and a question in your AI assistant: what happened to this request? Hosted OpenSearch MCP works with any MCP-compatible AI client or model. Claude Desktop and Cursor are examples. This guide covers the Basic-auth prerequisite, client configuration and a first log search you can verify against records you already recognise.

The short answer

Hosted OpenSearch MCP gives any MCP-compatible AI assistant a managed, read-only HTTPS connection to your Logit.io logs. Your choice of client or model is up to you; the client must support the remote connection and Authorization header described below. MCP is included in the 14-day free trial; on paid plans, it is available on Business and Custom.

The goal here is a search result you can check against your own logs. Choose a known event before setup so you can distinguish a working connection from an answer that merely sounds plausible. Once you have that baseline, use it when comparing clients or changing models.

How a question reaches your logs

Your assistant connects to the hosted MCP server for one enabled stack. That server provides read-only access to the stack's OpenSearch data. You ask a question, the client makes tool calls, and the returned search results give the assistant evidence for its answer. Logit.io hosts the MCP server, so you do not need to run a local MCP server process.

The connection does not make a vague question precise. If you ask why production is broken without identifying the logs or time window, the assistant still needs those details. Treat it as a search partner: give it the symptom you observed, let it discover the available indexes, and require it to distinguish what the log records show from what it suspects.

For context, read Introducing Hosted OpenSearch MCP and AI-assisted log investigation on Logit.io today. This guide focuses on setup and verification: establish a known log baseline, connect your chosen client and inspect the evidence returned by its first search.

Check the stack before connecting

Start with a Logs stack running OpenSearch, or an OpenSearch stack, containing logs you can already search. Pick a recent event you recognise: a timeout message, a service startup or a failed request. Record approximately when it happened and which stack received it. This gives you a known search target before you introduce another client.

You need permission to enable MCP: the quickstart names a stack administrator or account owner/admin. MCP is enabled separately on each stack. Connecting an assistant to one stack does not make the logs in your other stacks appear in that connection. If you maintain separate environments, confirm which stack holds the production logs before copying its configuration.

MCP currently needs the stack in Basic (Username and Password) mode. Set this on Settings → Endpoints. Stack administrators can switch between API Key and Basic there; allow about 30 seconds for a mode change to apply before connecting.

Before leaving Dashboards, note the event's exact index, timestamp, message and any request identifier. Include the timezone and a short window around the event. Use an event within your stack's retention period. A screenshot of an old alert can point to logs that have already expired, which makes it a poor target for checking a new connection.

The Hosted OpenSearch MCP feature page describes the connection, while the pricing page lets you compare plans after your trial.

Enable MCP and copy the connection details

Open the chosen stack's Settings page. Under Access, find OpenSearch MCP and select Enable. Logit.io provisions https://{stack-id}-mcp.logit.io and generates a dedicated MCP API key.

Copy the populated block from Settings → Endpoints, under OpenSearch MCP (read-only).

Here {base64-encoded-credentials} represents the Base64 encoding of {stack-id}-mcp:{mcp-api-key}. The MCP key is separate from the OpenSearch -es stack key. The Hosted OpenSearch MCP quickstart is the reference for enablement and connection details.

Configure your chosen AI client

Use any MCP-compatible AI client or model with Hosted OpenSearch MCP. In the client, add a remote MCP server using the URL and Authorization header above. Check that the client supports remote MCP over HTTPS with custom headers; that connection capability is required regardless of which model you select.

Clients expose server settings differently. Some accept a JSON configuration file; others provide separate URL and header fields. Preserve the endpoint exactly as supplied, without adding a /mcp path. If the client has separate fields, enter Authorization as the header name and the complete Basic {base64-encoded-credentials} value. Select the Logit.io server for the conversation where you will run your search.

The following Cursor and Claude Desktop configurations are examples of the same connection. Use the equivalent remote-server settings in your preferred client. Changing the model does not change the stack endpoint or its dedicated MCP credentials.

Example: connect Cursor with mcp.json

In Cursor, open Settings → MCP, or edit the MCP configuration file, for example .cursor/mcp.json. The documented server entry is named logit-opensearch. If the file already contains other servers, merge this entry into the existing mcpServers object instead of replacing their configuration.

{
  "mcpServers": {
    "logit-opensearch": {
      "url": "https://{stack-id}-mcp.logit.io",
      "headers": {
        "Authorization": "Basic {base64-encoded-credentials}"
      }
    }
  }
}

Save the populated configuration. If Cursor asks you to approve use of the server or a search tool, review the request so the assistant can run the search you intend.

If you maintain several project configurations, check which one Cursor loaded for the current workspace. Give connections to different stacks distinct names so a production investigation does not accidentally use a development stack.

Example: connect Claude Desktop

Claude Desktop uses the same documented JSON shape. Paste the populated configuration from Endpoints into its MCP server settings. Restart the client if your version requires it.

{
  "mcpServers": {
    "logit-opensearch": {
      "url": "https://{stack-id}-mcp.logit.io",
      "headers": {
        "Authorization": "Basic {base64-encoded-credentials}"
      }
    }
  }
}

Check remote HTTPS and custom-header support in your installed version. If those settings are unavailable, use a compatible version or another MCP-compatible client. Keep the same known event as your search target when comparing clients, so you can attribute different results to a specific configuration or query change.

Verify a real log search

Use this sequence once your chosen client has saved the connection: confirm that the Logit.io server connects and exposes tools, ask it to list indexes, then search a returned index for your known event. Avoid beginning with an assumed pattern such as logs-*: your stack may store the logs under a different name.

Use the connected Logit.io MCP server to list indexes on this stack.
Show the names returned by the tool. Do not guess an index pattern.

Next, search the selected index for the recent event you chose before setup. In the prompt below, replace INDEX_FROM_THE_LIST with the returned index name and replace the example time window with the one containing your event. The word timeout is an example search target, not a requirement for how your application writes logs.

Search INDEX_FROM_THE_LIST for logs containing timeout between
2026-11-02T09:00:00Z and 2026-11-02T09:15:00Z.
Return up to five matching records and the query you used.
Identify the timestamp and message fields from the actual records.
If the search fails, show the failure instead of inferring a result.

Watch for tool calls against the stack and inspect the returned hits. A successful search with no matches shows that the request completed, but does not establish that your target event is absent from every index or time range. An assistant explaining how it would search logs has not yet supplied a result from your stack.

For a positive match, compare the returned timestamp, message and request identifier with your Dashboards baseline. Check that the index belongs to the intended environment. A similar error from another service is useful evidence for a different question; it does not verify that you found the event you selected.

Inspect the query and its scope

Read the actual tool arguments alongside the assistant's answer. Confirm that the search used the selected index, the intended timestamp field and both time boundaries. Use explicit UTC dates when possible. A local time copied from an alert can shift the search by an hour or more if you omit the timezone. Ask the assistant to show any conversion it made.

Inspect a sample record before requesting filters on service, severity or request ID. Applications use different field names, and an ingestion pipeline may nest or rename them. Ask which returned field supports each filter. If the assistant proposes a field that does not appear in the sample, inspect the available mapping before relying on that filter.

Finally, tighten the time window around the known event or use a more specific phrase from its message. Compare the returned records with the original search. Record the index, query, absolute time range and one matching record as your baseline. This gives you a compact, repeatable check for another client without preserving an entire conversation.

Optional: check direct OpenSearch connectivity

A direct OpenSearch REST API check can establish whether you can reach the stack independently of the assistant. In Basic mode, the OpenSearch username is {stack-id} and the password is {stack-api-key}. These are the stack credentials, separate from the MCP username and key.

curl -X GET "https://{stack-id}-es.logit.io:443/_cluster/health?pretty" \
  -u "{stack-id}:{stack-api-key}"

Use the OpenSearch values from Endpoints before running this command locally. A cluster-health response verifies the direct API connection; it does not prove that the AI client has connected through MCP. If this request works while the client fails, focus on MCP enablement, its dedicated credentials and the client's connection settings. See Connect directly to your OpenSearch cluster for the API connection reference.

Ask focused log investigation questions

After the first verified hit, keep each question small enough to check. The prompts here are investigation suggestions, not promises of particular tool names or a fixed log schema. Replace the index, dates, service name and message text with values present in your own logs, and use the tools your client actually lists.

Find a recurring error message

Begin with an error phrase you have seen in a ticket or alert. Ask for a few matching records within an explicit window, then read the surrounding fields. A repeated phrase can identify a useful lead, but identical text alone does not tell you whether the records came from one request, several hosts or unrelated failures.

In INDEX_FROM_THE_LIST, find up to five logs containing
"connection refused" from 2026-11-02T09:00:00Z to 2026-11-02T09:30:00Z.
Show the search query and the returned timestamps and messages.
Report service or host fields only if they exist in the records.

Use the response to choose your next filter. If every sample names the same service, search that service explicitly after confirming the field that contains it. If the samples differ, keep the uncertainty visible. Ask the assistant which parts of its explanation are supported by the returned records before accepting a single cause.

Follow one request through the logs

If your application records a request identifier, use a value from an actual hit. The identifier and its field name must come from your data. This is useful when one error message is shared by many requests and you need to see what happened to a particular operation.

Using the request identifier and field from the log record we just found,
search the same index and time window for related records.
Return a small sample in timestamp order where the available tools allow it.
Separate the observed sequence from any explanation you infer.

Read that sequence as log evidence. Missing stages can mean a process did not log them, the chosen window excluded them or the related records sit elsewhere. Ask the assistant to name those gaps explicitly. A coherent narrative is easier to trust when you can see exactly which events support it.

Check whether new logs arrived

For a newly connected service, search for its actual service name and a recent message you expect. This is a search for evidence in indexed logs. Keep the question on what arrived, which fields carry the service identity and whether the timestamps match the period when the application ran.

Search the selected log index for records from my service in the last
15 minutes. First confirm which field contains its name from sample records.
Show up to five matches, including their timestamps and messages.
If there are no matches, state the index and filters that returned none.

For the instrumentation workflow that leads up to this check, read Instrument with an AI prompt, then check with OpenSearch MCP. For a longer incident example after setup, continue with Investigating production logs with OpenSearch MCP.

Troubleshoot the connection

If the client cannot connect, revisit the Basic-mode prerequisite and the saved remote-server settings. Copy the populated block from Settings → Endpoints. For HTTP errors, tool-discovery failures and the read-only tool boundary, use the introduction's troubleshooting reference instead of changing the investigation prompt.

When a tool call completes but the expected event is missing, compare its query with your baseline. Check the exact index, date boundaries, timezone and message text. If you filtered on a service or severity field, temporarily remove that filter and inspect a few records around the event. A field mismatch can exclude the target even when the message and timestamp are correct.

For an event near midnight, check whether it landed in a neighbouring daily index. For a newly connected service, allow for ingestion delay and compare the indexed records with what the application emitted. Change one search condition at a time and retain the query that returned no hits. This gives you useful evidence if you need help, instead of an untestable statement that the assistant could not find anything.

Read-only access and credentials

Hosted MCP exposes read-only searches. Keep the populated client configuration private: its encoded Authorization value is a credential, even though it does not look like the original key. Share the index, query, time range and relevant records when reviewing an investigation, and remove credentials from screenshots or transcripts.

Rotate the dedicated MCP API key on Endpoints when necessary and replace the saved configuration in clients using the old key. Disable MCP from the stack's Access card to remove its public MCP route. After a credential change, use your saved baseline search to check the updated client.

FAQ

Which AI clients or models can I use?

Hosted OpenSearch MCP works with any MCP-compatible AI client or model. Claude Desktop and Cursor are examples. The client needs remote MCP over HTTPS and custom Authorization headers; check those capabilities in the version you use.

Does one MCP connection cover all my stacks?

No. There is one MCP endpoint per enabled stack. Enable MCP separately on each stack you need and name the client connections clearly. Check the selected stack when two environments have similarly named indexes or services.

Keep a verified search for your next investigation

A saved query and a recognised record make future setup changes easier to assess. For a live investigation, update the dates and keep questions specific: which records contain the error, what happened to one request, or whether the latest service logs arrived. Review the returned evidence before accepting an explanation.

The Hosted OpenSearch overview explains the managed platform behind the connection. Start with logs you already know, then use your preferred MCP-compatible assistant to explore the next question.