Loading ToolBench
MCP server providing access to Sumo Logic Cloud SIEM (CSE) and Core Intelligence Platform (CIP) APIs for detection engineering workflows
This server provides 4 tools for Sumo Logic content library management. Tool naming follows verb-noun convention (list, get, create, delete) which is good. However, descriptions are minimal (13-27 words each), parameter schemas are basic, and there is no documented output schema. Input schemas are present but lack depth, no enums, no min/max constraints, minimal per-parameter descriptions. No error handling guidance, no recovery patterns, and no tool annotations (readOnlyHint/destructiveHint). The tools are functional but significantly under-documented for LLM reasoning.
Create a folder in the Sumo Logic content library for organizing saved searches and other content.
Delete a folder from the Sumo Logic content library.
Get a content library folder by ID. Returns folder details and its children (subfolders and content items).
List folders in the Sumo Logic content library.
Output schemas completely undocumented. No specification of what fields are returned by any tool. LLMs cannot plan downstream calls or extract chaining IDs without knowing response structure.
Descriptions are too brief (13-27 words). They state WHAT but not WHEN to use or what the tool returns. 'List folders in the Sumo Logic content library' lacks context for LLM selection when multiple tools exist.
cip_list_folders and cip_create_folder have no per-parameter descriptions for limit/token and description fields respectively. Parameter descriptions are mandatory per pattern, LLMs infer meaning from descriptions, not names alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
No enums, min/max, or format constraints on parameters. 'limit' has no min/max declaration (description says 'max: 1000' in text, but not in schema). 'parent_folder_id' and 'folder_id' have no format hint (UUID? string format?). Free-form parameters invite hallucinated values.
No tool annotations (readOnlyHint, destructiveHint). cip_delete_folder is marked DESTRUCTIVE in Risk but has no schema annotation. cip_list_folders and cip_get_folder are READ_ONLY but unmarked. Annotations enable agents to understand reversibility and plan safely.
No error handling or recovery guidance. If a folder_id is invalid or a parent_folder_id does not exist, the tool provides no guidance on what to do next (e.g., 'Try cip_list_folders to discover valid folder IDs'). Error responses must guide LLM recovery.
cip_create_folder lacks confirmation/dry-run. This is a write operation but has no pre-flight check or rollback guidance. Per pattern, irreversible operations should support dry-run or confirmation.
cip_delete_folder is destructive but has no protection or guidance. No mention of what happens to child items, whether deletion is reversible, or confirmation requirement. Agents need to understand consequences before triggering.
Parameter 'token' for pagination is unexplained. Is it a cursor? An offset? An opaque string? Description says 'Pagination token from previous response' but the cip_list_folders tool does not document what field in the response contains the next token. Broken pagination chains.