Skip to main content
Glama
CraigWetzelberger

sumo-mcp-readonly

by CraigWetzelberger
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

sumo-mcp-readonly

A read-only Model Context Protocol (MCP) server for querying Sumo Logic logs. Enables AI-powered coding assistants to search and investigate application logs directly from your editor.

Works with any MCP-compatible client: Kiro, Claude Code, Cursor, VS Code + Copilot, and others.

Why This Project?

As of now July 31, 2026 - Sumo Logic has announced an MCP server as part of their Dojo AI platform (limited beta, focused on security operations), but there is no publicly available, standalone MCP server for general log search. Community options exist but tend to be minimal wrappers around the search API without attention to:

  • Credential safety — this server redacts access keys from all error output and never logs credentials

  • Cookie handling — Sumo's Search Job API requires cookies to be maintained per session; most implementations miss this and get intermittent failures

  • Timestamp format — Sumo rejects ISO-8601 timestamps with milliseconds; this server sends epoch milliseconds correctly

  • Job isolation — only search jobs created by this process can be queried or cancelled, preventing cross-session leakage

  • Opinionated tools — sumo_find_errors and sumo_search_correlation_id encode common investigation patterns so your AI assistant doesn't need to know Sumo query syntax to be useful

If one of the community servers covers your needs, use it. This one prioritizes correctness and security for production use.

Related MCP server: quickwit-mcp

Quick Start

Prerequisites

  • Node.js 20 or later

  • A Sumo Logic account with an Access Key

Install Node.js

macOS (Homebrew):

brew install node@20

Or download from https://nodejs.org (LTS version).

Windows:

Option A — Download the installer from https://nodejs.org (LTS version). Run it and accept defaults.

Option B — Using winget:

winget install OpenJS.NodeJS.LTS

Option C — Using nvm-windows:

nvm install 20
nvm use 20

After installing, open a new terminal and verify:

node --version   # Should show v20.x.x or later
npm --version    # Should show 10.x or later

Linux (Ubuntu/Debian):

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt-get install -y nodejs

1. Create your Sumo Logic Access Key

  1. Log into Sumo Logic

  2. Click your username (bottom-left) and select Personal Access Keys (docs)

  3. Click + Add Access Key

  4. Name it something like "MCP Server"

Access keys can be scoped to limit permissions. When creating the key, select Custom scopes and enable only Log Search — that's the single scope this server needs. No other permissions are required.

The user creating the key must have a role with:

  • A search filter that allows access to the log data you want to query

The built-in Analyst role works. If you want a minimal custom role, grant View Collectors, set the search filter to allow the source categories you need, and leave everything else unchecked.

Note: The Search Job API requires an Enterprise-tier Sumo Logic account. Free, Professional, and Essentials plans will get a 403 error. (docs)

2. Connect to your MCP client

Add the server to your client's MCP configuration. No install command is needed — your MCP client downloads the package automatically on first use.

  • Kiro — .kiro/settings/mcp.json

  • Claude Code — claude_code_config.json

  • Cursor — .cursor/mcp.json

{
  "mcpServers": {
    "sumo-mcp-readonly": {
      "command": "npx",
      "args": ["-y", "sumo-mcp-readonly"],
      "env": {
        "SUMO_ACCESS_ID": "your-access-id",
        "SUMO_ACCESS_KEY": "your-access-key",
        "SUMO_API_BASE_URL": "https://api.sumologic.com/api"
      }
    }
  }
}

Security note: If your client supports environment variable references (e.g., ${SUMO_ACCESS_ID}), prefer those over embedding credentials directly in config files. Set the variables in your shell profile instead.

Tools

Once connected, your MCP client can use these tools:

sumo_search_logs

Run any Sumo Logic query. This is the most flexible tool — anything you can type in the Sumo Logic search bar works here.

{
  "query": "_sourceCategory=prod/api status=500 | count by _sourceHost",
  "lastMinutes": 30,
  "limit": 50
}

Supports explicit time ranges too:

{
  "query": "error | count by _sourceCategory",
  "startTime": "2025-01-15T10:00:00Z",
  "endTime": "2025-01-15T11:00:00Z"
}

sumo_find_errors

Opinionated error search — looks for ERROR, exception, failure, fatal, and stack traces without needing to write the full query.

{
  "sourceCategory": "prod/api",
  "service": "user-service",
  "lastMinutes": 30,
  "text": "NullPointerException"
}

sumo_search_correlation_id

Search for a trace ID, request ID, or correlation ID across your logs. The ID is safely escaped as a literal.

{
  "correlationId": "550e8400-e29b-41d4-a716-446655440000",
  "sourceCategory": "prod/api",
  "lastMinutes": 60
}

sumo_get_search_status

Check the status of a running search job. Only jobs created in the current session can be queried.

{
  "jobId": "IUUQI-DGH5I-TJ045"
}

sumo_cancel_search

Cancel a running search job. Only jobs created in the current session can be cancelled.

{
  "jobId": "IUUQI-DGH5I-TJ045"
}

Configuration Reference

All configuration is via environment variables. Copy .env.example to .env for local development, or pass them via your MCP client's env block.

Variable

Required

Default

Description

SUMO_ACCESS_ID

Yes

—

Sumo Logic Access ID

SUMO_ACCESS_KEY

Yes

—

Sumo Logic Access Key

SUMO_API_BASE_URL

Yes

—

Regional API endpoint (see below)

SUMO_DEFAULT_SOURCE_CATEGORY

No

—

Default _sourceCategory for opinionated tools

SUMO_MAX_QUERY_RANGE_MINUTES

No

1440

Maximum allowed query time range in minutes

SUMO_MAX_RESULT_COUNT

No

1000

Maximum results returned per query

SUMO_QUERY_TIMEOUT_SECONDS

No

120

Timeout waiting for search job completion

LOG_LEVEL

No

info

Log verbosity (debug, info, warn, error)

Determine Your API Endpoint

Your SUMO_API_BASE_URL must match your Sumo Logic deployment region. Look at the URL in your browser when logged into Sumo Logic:

If your URL contains

Your deployment

API Base URL

service.sumologic.com

US1

https://api.sumologic.com/api

service.us2.sumologic.com

US2

https://api.us2.sumologic.com/api

service.eu.sumologic.com

EU

https://api.eu.sumologic.com/api

service.au.sumologic.com

AU

https://api.au.sumologic.com/api

service.jp.sumologic.com

JP

https://api.jp.sumologic.com/api

service.ca.sumologic.com

CA

https://api.ca.sumologic.com/api

service.de.sumologic.com

DE

https://api.de.sumologic.com/api

service.in.sumologic.com

IN

https://api.in.sumologic.com/api

service.fed.sumologic.com

FED

https://api.fed.sumologic.com/api

Custom/vanity URLs (e.g., yourcompany.sumologic.com) are typically on US1. If you get HTTP 301 errors, you're using the wrong endpoint.

Security Model

This server is deliberately minimal and read-only:

  • Read-only — only log search operations are supported

  • No administration — no collector, user, role, token, partition, or source management

  • No content mutation — no creation, deletion, or modification of Sumo Logic resources

  • No shell execution — no arbitrary command execution

  • No persistent storage — query results are not stored to disk

  • Credentials never logged — access keys are redacted from all log output

  • Job isolation — only search jobs created by this process can be queried or cancelled

WARNING: Sumo Logic query results may contain PII, secrets, API keys, or other sensitive data depending on what your applications log. Only use this server with MCP clients connected to AI services you trust with your log data.

Troubleshooting

401 Unauthorized — Your Access ID or Key is wrong, revoked, or expired. Double-check both values.

403 Forbidden — The access key's role doesn't have "Run Log Search" capability.

301 Redirect — Wrong regional API endpoint. See the table above. The URL must NOT end with a trailing slash.

Timeout — Increase SUMO_QUERY_TIMEOUT_SECONDS, narrow your time range, or simplify the query. Large searches can take minutes.

400 Bad Request — Query syntax error. Check your Sumo Logic query syntax and field names.

429 Rate Limited — Sumo Logic allows 4 requests/second per user and 200 concurrent jobs per org. Reduce query frequency.

Credential Rotation

  1. Create a new access key in Sumo Logic (Administration > Security > Access Keys)

  2. Update SUMO_ACCESS_ID and SUMO_ACCESS_KEY in your .env or MCP client config

  3. Restart the MCP server (your client will do this automatically on config change)

  4. Verify with a simple query

  5. Revoke the old key in Sumo Logic

Development

npm run dev          # Run with tsx (no build step needed)
npm run build        # Compile TypeScript
npm test             # Run unit tests (68 tests)
npm run test:watch   # Watch mode
npm run lint         # ESLint
npm run format       # Prettier
npm run format:check # Check formatting without writing

Architecture

src/
  index.ts            — Entry point, config validation, server startup
  server.ts           — MCP server creation and tool registration
  config.ts           — Environment variable validation (Zod)
  logging.ts          — Structured JSON logger (stderr only)
  sumo/
    client.ts         — HTTP client with auth, cookies, error mapping
    auth.ts           — HTTP Basic authentication header
    types.ts          — Sumo Logic API type definitions
    search-jobs.ts    — Search lifecycle orchestration
    errors.ts         — Typed error hierarchy
  tools/
    search-logs.ts    — sumo_search_logs implementation
    find-errors.ts    — sumo_find_errors implementation
    search-correlation-id.ts — sumo_search_correlation_id implementation
    get-search-status.ts     — sumo_get_search_status implementation
    cancel-search.ts         — sumo_cancel_search implementation
  query/
    escaping.ts       — Query literal escaping
    builders.ts       — Opinionated query construction
  security/
    redaction.ts      — Credential redaction for error output
    limits.ts         — Time range and result count enforcement

License

MIT

Available Tools

5 tools
sumo_find_errorsFind Errors in Sumo LogicA

Search for recent errors using an opinionated query that looks for ERROR, exception, failure, fatal, and stack traces.

ParametersJSON Schema
NameRequiredDescriptionDefault
textNoAdditional text to filter for
limitNoMaximum number of results
serviceNoService name to filter by
lastMinutesNoSearch the last N minutes (default: 30)
sourceCategoryNoSource category to search (uses default if omitted)

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description provides the query terms, which is useful. However, it does not mention return format, pagination, rate limits, or other behavioral traits beyond the search itself.

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 concise sentence that front-loads the purpose and includes specific query terms, with no redundant information.

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 search tool with no output schema, the description covers the core behavior and query terms. It is adequate but could mention return results or default behavior more explicitly.

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 parameters are fully documented. The description adds no additional parameter semantics 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 the tool searches for recent errors using an opinionated query with specific error terms (ERROR, exception, failure, fatal, stack traces). This distinguishes it from the general sumo_search_logs sibling.

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

Usage Guidelines3/5

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

The description implies usage for finding errors but does not explicitly compare to sibling tools like sumo_search_logs or state when not to use it. The 'opinionated query' hints at specialization but lacks explicit guidance.

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

sumo_get_search_statusGet Search Job StatusA

Get the current status of a Sumo Logic search job started by this MCP server process.

ParametersJSON Schema
NameRequiredDescriptionDefault
jobIdYesThe search job ID (returned by previous search operations)

TDQS

A3.6/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get the current status' which implies a read-only operation, but it does not mention failure modes, whether it can be called repeatedly, or what happens if the jobId is invalid. This is insufficient transparency for a tool with no structured annotation support.

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 sentence with no redundant words. It is front-loaded with the action and resource, making it easy to parse quickly.

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 status-check tool with one parameter and no output schema, the description is fairly complete. It states what the tool does and clarifies the source of the jobId. However, it does not describe possible return statuses or error behavior, which would be helpful given the absence of an output schema.

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 jobId with 'The search job ID (returned by previous search operations)' at 100% coverage. The description adds the context 'started by this MCP server process', which reinforces that the job must come from this server, but this is largely already implied by the schema. The description does not add significant new meaning 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 uses the specific verb 'Get' and clearly identifies the resource as 'current status of a Sumo Logic search job', which distinguishes it from sibling tools like sumo_cancel_search and sumo_search_logs. The phrase 'started by this MCP server process' adds scope and prevents confusion with jobs from other sources.

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

Usage Guidelines3/5

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

The description implies usage (checking status after starting a search job) but does not explicitly state when to use it versus alternatives. It provides no exclusions or direct references to sibling tools, so the guidance is only implied rather than stated.

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

sumo_search_correlation_idSearch by Correlation IDA

Search for a trace ID, request ID, correlation ID, transaction ID, or similar identifier across logs. The ID is safely escaped as a literal search term.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results
lastMinutesNoSearch the last N minutes (default: 60)
correlationIdYesThe correlation/trace/request ID to search for
sourceCategoryNoSource category to search (uses default if omitted)

TDQS

A3.7/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 discloses that the ID is safely escaped as a literal search term, which is a useful behavioral detail, but it does not mention result format, rate limits, authentication requirements, or page/limit behavior. The description adds some context but remains incomplete.

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 two concise sentences: the first states the core function, the second notes a safety behavior. Both sentences earn their place, with no fluff or redundancy, and the primary action is front-loaded.

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

Completeness3/5

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

The tool has moderate complexity (4 params, no annotations, no output schema). The description plus schema cover the search purpose and parameter details, but the missing output schema and lack of guidance on comparing with sibling tools leave some contextual gaps. Return value expectations and usage nuance are not fully addressed.

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 the baseline is 3. The description adds a few synonyms (transaction ID, etc.) for the correlationId parameter, but this is marginal beyond what the schema already specifies. It does not clarify the meaning of limit, lastMinutes, or sourceCategory beyond their schema descriptions.

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 searches for trace/request/correlation/transaction IDs across logs, which is a specific verb, resource, and scope. It distinguishes itself from sibling tools like sumo_search_logs and sumo_find_errors by focusing on cross-reference identifiers.

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

Usage Guidelines3/5

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

The description implies usage when an identifier is available, but it does not explicitly state when to use this tool over alternatives like sumo_search_logs, nor does it provide exclusions. The context is clear but lacks explicit guidance for tool selection.

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

sumo_search_logsSumo Logic Log SearchA

Run a Sumo Logic log query. Provide either startTime+endTime or lastMinutes, but not both. Defaults to the last 15 minutes.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return
queryYesSumo Logic search query
endTimeNoEnd time in ISO-8601 format (UTC)
startTimeNoStart time in ISO-8601 format (UTC)
lastMinutesNoSearch the last N minutes (alternative to startTime/endTime)
includeRecordsNoInclude aggregate records in results
includeMessagesNoInclude raw log messages in results

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It adds value by stating the default time range ('Defaults to the last 15 minutes') and the mutual exclusion of time inputs. However, it does not state that the tool is read-only, what fields the results contain, or any potential side effects. For a search tool, the behavioral disclosure is decent but incomplete.

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 two sentences long, front-loaded with the core action, and every word contributes. It efficiently communicates the main purpose, key constraints, and a default without extraneous information.

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

Completeness3/5

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

The tool has 7 parameters, no output schema, and no annotations. The description covers only time-related behavior, leaving gaps around expected output format, how the 'query' parameter should be structured, and the effect of flags like includeRecords/includeMessages. While the schema is rich, the lack of output documentation and limited description make the tool moderately, but not fully, contextualized.

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?

The schema already has 100% parameter coverage, so the baseline is 3. The description enhances this by explicitly noting that startTime+endTime and lastMinutes are mutually exclusive ('but not both') and by revealing the default time window. These details go beyond the schema's individual descriptions, clarifying relationship and default behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Run a Sumo Logic log query.' This is a specific verb+resource pair that is distinct from sibling tools like sumo_get_search_status, sumo_cancel_search, or sumo_find_errors. However, it does not explicitly name or contrast these alternatives, so it stops short of full sibling differentiation.

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

Usage Guidelines3/5

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

The description gives concrete usage guidance for time parameters: 'Provide either startTime+endTime or lastMinutes, but not both' and the default window. This is useful for avoiding misuse, but it does not say when to choose this tool over siblings (e.g., when a general search is needed vs. an error-focused search). Thus the guidance is mainly about parameter handling, not tool selection.

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. 5 tool updatesv1.0.2
    • First observedsumo_cancel_search
    • First observedsumo_find_errors
    • First observedsumo_get_search_status
    • First observedsumo_search_correlation_id
    • First observedsumo_search_logs
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored across 5 tools

Disambiguation4/5

The tools have mostly distinct purposes: general search, specialized error search, correlation ID search, status check, and cancel. The two specialized searches could be seen as overlapping with the general search, but their specific intents and query behavior are clearly described.

Naming Consistency4/5

All tools share the 'sumo_' prefix and follow a verb_noun pattern. However, 'sumo_find_errors' uses 'find' instead of 'search', which is a minor deviation from the otherwise consistent use of 'search', 'get', and 'cancel'.

Tool Count5/5

Five tools is well-scoped for a read-only Sumo Logic MCP server. Each tool addresses a distinct need: running searches, managing search jobs, and specialized search shortcuts, without unnecessary bloat.

Completeness3/5

The presence of search, status, and cancel suggests an asynchronous search job lifecycle, but there is no explicit tool to retrieve the actual results of a completed search. This is a notable gap that agents will need to work around, possibly expecting search_logs to return results synchronously, but this is not clearly indicated.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • mcp-sumologic

    giftHEALTH
    F
    license
    B
    quality
    B
    maintenance
    MCP server that integrates with Sumo Logic's API to perform log searches, data discovery, metrics queries, and monitoring.
    15
    6
    -

  • quickwit-mcp

    agarwalvivek29
    A
    license
    Not graded
    quality
    F
    maintenance
    A read-only MCP server that exposes Quickwit log search and aggregations to LLM clients, enabling natural language log investigation.
    Apache 2.0

  • mcp-opensearch

    bunnyiesart
    A
    license
    A
    quality
    A
    maintenance
    A read-only MCP server that enables AI assistants to search, aggregate, and explore OpenSearch log data through 12 tools for connectivity, index discovery, search, and aggregations.
    17
    MIT