Provides tools for searching Sumo Logic logs (raw and aggregate), querying metrics, managing monitors, and discovering data sources such as collectors, sources, partitions, fields, and scheduled views.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-sumologic search logs for 'error' in the last 24 hours"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that integrates with Sumo Logic's API to perform log searches.
Search Sumo Logic logs using custom queries
Configurable time ranges for searches
Error handling and detailed logging
stdio transport by default (works with MCP clients and docker run -i)
Optional Streamable HTTP transport for remote deployments
Related MCP server: vmware-aria-logs
SUMO_API_ID=your_api_id # Required
SUMO_API_KEY=your_api_key # Required
ENDPOINT=https://api.us2.sumologic.com/api/v1 # Optional (defaults to gifthealth US2)
PORT=3006 # Optional (HTTP mode only)Pull and run the published image from GHCR:
docker run -i --rm \
-e SUMO_API_ID=... \
-e SUMO_API_KEY=... \
ghcr.io/gifthealth/mcp-sumologic{
"mcpServers": {
"sumologic": {
"command": "docker run -i --rm -e SUMO_API_ID -e SUMO_API_KEY ghcr.io/gifthealth/mcp-sumologic",
"env": {
"SUMO_API_ID": "...",
"SUMO_API_KEY": "..."
}
}
}
}The server supports two transports, selected by CLI argument:
Mode | Command | Use case |
stdio (default) |
| MCP clients, |
http |
| Remote HTTP/SSE deployment on port 3006 |
Clone the repository
Install dependencies:
npm installCreate a .env file with SUMO_API_ID and SUMO_API_KEY
Build the project:
npm run buildStart the server:
npm start # stdio (default)
npm run start:http # HTTP on port 3006docker build -t ghcr.io/gifthealth/mcp-sumologic .
docker run -i --rm \
-e SUMO_API_ID=... \
-e SUMO_API_KEY=... \
ghcr.io/gifthealth/mcp-sumologicdocker run -p 3006:3006 --env-file .env \
ghcr.io/gifthealth/mcp-sumologic \
node dist/index.js httpOr use Docker Compose (runs HTTP mode on port 3006):
docker-compose up --build -dAll tools are read-only. Search tools accept optional from/to ISO timestamps and limit (default 100).
Tool | Description |
| Raw log messages (non-aggregation queries) |
| Aggregation records ( |
Example — list source categories:
query: _sourceCategory=* | count by _sourceCategory | sort by _count descUse search_aggregate for the above; use search_logs for raw log lines.
Tool | Description |
| List collectors |
| Get collector by ID |
| List sources for a collector |
| List partitions (index/source category routing) |
| List configured fields |
| List scheduled views |
Tool | Description |
| Run a metrics query ( |
Tool | Description |
| Search monitors |
| Get monitor by ID |
| List health events |
Tool | Description |
| Get library content by path |
| Get personal content folder |
| Get folder by ID |
The server includes comprehensive error handling and logging:
API errors are caught and logged with details
Search job status is monitored and logged
Network and authentication issues are properly handled
To run in development mode:
npm run dev # stdio (default)
npm run dev:http # HTTP on port 3006For testing:
npm test # run Vitest suite once
npm run test:watch # watch modeCommon tasks are available via make:
Command | Description |
| Install dependencies |
| Build the project |
| Start the server (stdio) |
| Start in development mode (auto-reload) |
| Remove |
| Run ESLint |
| Run tests |
| Build Docker image |
| Run container with |
| Start services via Docker Compose |
| Stop Docker Compose services |
Get a Sumo Logic collector by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| collectorId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden but fails to disclose behavior such as error handling (e.g., when collector ID is not found), authentication needs, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, appropriate for a simple tool, though it could include a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema and lack of output schema, the description is somewhat adequate but missing behavioral context and parameter semantics, leaving the agent with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only restates the parameter 'by ID' without adding meaning like where to obtain the collector ID or its expected format beyond the schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'Sumo Logic collector by ID', clearly distinguishing from siblings like 'list_collectors' that retrieve multiple collectors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as 'list_collectors' for listing or other get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Sumo Logic library content by path.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details beyond the basic operation. It does not mention whether the operation is a read, if it requires special permissions, or what the output looks like. With no annotations, this is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified. While it is short, it sacrifices essential information for brevity. A concise description would include key details without being verbose, but this lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description fails to provide a complete picture. It does not explain the return format, behavior for missing paths, or any other contextual information needed for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the 'path' parameter beyond what the schema provides. Schema coverage is 0%, and the description merely repeats 'by path', which is already in the tool name. No parameter constraints, example values, or format hints are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets library content by path, using a specific verb and resource. However, it does not differentiate from sibling tools like get_collector or get_folder, which might also retrieve content by path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description only states what it does, not the context or prerequisites. Without annotations, the agent has no hints about when to invoke this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Sumo Logic content folder by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| folderId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits such as permissions required, error handling, or return format. With no annotations, the description carries full burden but offers minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is extremely concise, but it omits important details. While not verbose, it could include additional context without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description does not explain what the tool returns or how the folder can be used, leaving agents uncertain about its output and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only mentions 'by ID' without adding any semantic detail about the folderId parameter (e.g., format, example, or constraints). It provides little meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (Get) and resource (Sumo Logic content folder) with the identifier (by ID), distinguishing it from sibling tools like get_collector or get_monitor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_content_by_path, get_personal_folder). The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Sumo Logic monitor by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| monitorId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It fails to mention read-only nature, idempotency, error handling, or any side effects. The single sentence does not provide behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description covers the basic purpose but lacks completeness. It does not describe the response format, error cases (e.g., monitor not found), or any prerequisites like authentication, which are important for a production tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage (no descriptions for parameters), and the tool description adds no semantic value beyond the schema. It does not explain the format, constraints, or expected values for 'monitorId'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('Sumo Logic monitor'), and the method ('by ID'). It distinguishes from sibling tools like 'search_monitors' which is for searching rather than direct retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as 'search_monitors'. The usage is only implied by the description (get by ID), but no contextual cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the personal content folder for the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read operation ('Get') and that authentication is needed ('for the authenticated user'), but lacks details on idempotency, permissions, error conditions, or rate limits. Adequate for a simple getter but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (no parameters), the description does not mention the return value or format, which is relevant since there is no output schema. It is complete enough for a minimal tool but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100% (vacuously). Per guidelines, baseline 4 is appropriate since the description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action 'Get' and the resource 'personal content folder for the authenticated user'. It distinguishes itself from siblings like 'get_folder' by specifying 'personal' and 'authenticated user', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_folder' or 'get_content_by_path'. There is no mention of use cases, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Sumo Logic collectors.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose pagination behavior, authentication requirements, rate limits, or data freshness. For a list endpoint, pagination details are critical but omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It lacks structured information that would aid the agent, such as listing parameters or describing output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 optional params, no output schema), the description is incomplete. It fails to cover pagination, result ordering, or response format, and offers no comparison to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning of 'limit' and 'offset' (e.g., pagination cursor, page size). The parameter names and constraints are minimal, leaving ambiguity about their function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (collectors). It is specific and unambiguous, but does not differentiate from siblings like 'get_collector' which retrieves a single collector.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_collector for a single collector, list_sources for sources within a collector). No when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured Sumo Logic fields.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must cover behavioral traits. It only says 'configured fields' without discussing authentication, rate limits, or expected results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, appropriately concise for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple list operation, but lacks details on what 'fields' entails or output structure, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds 'configured', hinting at selection scope, which adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (Sumo Logic fields), distinguishing it from sibling list tools that operate on other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For a simple list operation, basic context would help an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Sumo Logic health events.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the action without mentioning read-only nature, pagination, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (4 words) but under-specified, lacking necessary information despite being concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema or annotations, the description should explain what health events are or the scope of listing, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the 'limit' parameter or any other parameter details, failing to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List Sumo Logic health events' specifies verb and resource clearly, but does not differentiate from sibling tools like list_collectors or list_partitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Sumo Logic partitions (useful for discovering index and source category routing).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| token | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It fails to disclose behavioral traits such as pagination, rate limits, or required permissions, merely stating 'list' without security or side-effect context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core purpose, but it could be improved by explaining parameter use or output format without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is insufficiently complete. It omits the return format, pagination details, and any prerequisites, which are critical for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning to the two parameters ('limit' and 'token'). It does not explain their purpose (e.g., pagination or filtering), leaving the agent without crucial input understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'Sumo Logic partitions' with a specific use case for discovering index and source category routing, leaving no ambiguity about what the tool does and distinguishing it from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only a vague usability hint ('useful for discovering index and source category routing') but lacks explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Sumo Logic scheduled views.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states 'List', implying a read-only operation, but provides no details about pagination, output format, authentication requirements, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no superfluous words. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is minimally adequate. However, it lacks completeness by not describing the return value format or how it differs from similar list tools, which would help an agent decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds meaning by identifying the specific resource (scheduled views), which is not evident from the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and resource 'Sumo Logic scheduled views', clearly indicating the action and target. However, it does not differentiate from sibling list tools like 'list_collectors' or 'list_partitions', which have similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about scenarios where listing scheduled views is appropriate or when sibling tools should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sources for a Sumo Logic collector.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| collectorId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. However, it does not disclose behavior like pagination, error handling, or what happens if the collector ID is invalid. Only a basic listing action is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but it is under-specified. While short, it sacrifices necessary detail, making it less effective. Not optimally front-loaded with critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema, no annotations, and 3 parameters (1 required), the description is severely lacking. It fails to describe return values, pagination behavior, or any preconditions, making it inadequate for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not elaborate on any parameters (collectorId, limit, offset). It provides no semantic meaning beyond the raw schema, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'sources for a Sumo Logic collector'. It distinguishes from sibling tools like 'list_collectors' and 'get_collector' by targeting a specific child resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., if only collector ID is known, or to get sources for a specific collector). No when-not-to-use or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Sumo Logic metrics query. Returns time-series data for the given metric query.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| query | Yes | ||
| rowId | No | ||
| rollup | No | ||
| quantization | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states it returns time-series data but offers no details on authentication, rate limits, idempotency, or other behavioral traits. The description is basic but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences, front-loaded with the purpose. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and no output schema or annotations. The description omits parameter descriptions, constraints, and return format details, making it insufficient for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 6 parameters (query, from, to, rowId, rollup, quantization). It adds no value beyond the schema, failing to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a Sumo Logic metrics query and returns time-series data. It distinguishes itself from log or aggregate search tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for metrics queries but provides no explicit guidance on when to use it versus siblings like search_logs or search_aggregate, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Sumo Logic aggregation query and return records (e.g. count by, group by).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose important behavioral traits such as required authentication, rate limits, or the time range behavior (e.g., default time range for from/to parameters). The limit parameter's maximum of 1000 is only in the schema, not mentioned in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but it is too brief and lacks essential details. It is not front-loaded with the most critical information for an agent to invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with 0% schema coverage, no output schema, and no annotations, the description is severely incomplete. An agent cannot determine how to construct a valid query or interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 4 parameters. It does not explain what the query should contain, the format of from/to, or the purpose of limit beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a Sumo Logic aggregation query and returns records, with examples like 'count by, group by'. This distinguishes it from sibling tools like search_logs which likely perform non-aggregation searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as query_metrics or search_logs. The description implies it's for aggregation, but no when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Sumo Logic log search and return raw messages. Use for non-aggregation queries.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It states the tool returns 'raw messages', which is a basic behavioral trait but lacks details on pagination, error handling, or authentication. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one stating the action and output, another for usage guidance. There is no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is too brief. It fails to explain parameter formats (e.g., timestamps for from/to), query syntax, pagination, or response structure, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it does not explain the meaning of any parameter (query, from, to, limit), leaving the agent without guidance on format or usage beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run a Sumo Logic log search and return raw messages' with a specific verb and resource. It distinguishes from siblings by specifying 'Use for non-aggregation queries', contrasting with the sibling tool search_aggregate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for non-aggregation queries', providing clear context for when to use this tool. It implicitly suggests not to use it for aggregation, and the sibling list includes search_aggregate, so an agent can infer the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Sumo Logic monitors.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only says 'search,' implying a read operation, but lacks details on pagination, query format, rate limits, or result structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. However, it lacks any front-loading of key behavioral or usage details, making it minimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description is too sparse. It does not specify query format, return type, or pagination behavior, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter explanations. Parameter names are somewhat self-explanatory, but the description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search Sumo Logic monitors,' clearly indicating the verb and resource. However, it does not distinguish from sibling tools like get_monitor or search_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No mention of context, prerequisites, or when to prefer other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_collectorget_content_by_pathget_folderget_monitorget_personal_folderlist_collectorslist_fieldslist_health_eventslist_partitionslist_scheduled_viewslist_sourcesquery_metricssearch_aggregatesearch_logssearch_monitorsAll 15 tools target distinct resources or actions: get_*, list_*, search_*, query_metrics. No overlap; each tool has a clear, unique purpose.
All tool names follow the verb_noun pattern in snake_case consistently. Even compound nouns like 'personal_folder' and 'health_events' are uniform.
15 tools cover a comprehensive range of Sumo Logic operations without being overwhelming. The count is well-scoped for the platform's query and management needs.
The toolset is strong for reading and querying (get, list, search, query) but lacks any create, update, or delete operations. This is a notable gap for a management server, limiting agents to read-only scenarios.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI access to Swagger by SmartBear.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
Syslog receiver and MCP server for homelab log intelligence.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/giftHEALTH/mcp-sumologic'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
