sumo-mcp-readonly
Related Servers
Alternatives to sumo-mcp-readonly
No user-submitted related servers found.
Related Servers
- AlicenseAqualityAmaintenanceAn MCP server that gives coding agents programmatic access to Sumo Logic logs via the Search Job API, enabling issue triage in preview deployments and production without leaving the editor.1420Apache 2.0
- AlicenseAqualityAmaintenanceA 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.17MIT
- AlicenseNot gradedqualityFmaintenanceA read-only MCP server that exposes Quickwit log search and aggregations to LLM clients, enabling natural language log investigation.Apache 2.0
- AlicenseAqualityDmaintenanceA read-only MCP server that gives AI assistants natural language access to Elasticsearch/Kibana logs for querying and analysis.7MIT
- FlicenseBqualityBmaintenanceMCP server that integrates with Sumo Logic's API to perform log searches, data discovery, metrics queries, and monitoring.156-
- FlicenseNot gradedqualityBmaintenanceRead-only MCP server that converts Elasticsearch logs into citable evidence for AI agents, offering deterministic log summarization and search tools.-
TDQS
Scored across 5 tools
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.
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'.
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.
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.