Loading ToolBench
MCP server for LimaCharlie security operations platform, providing tools for case management, detection engineering, AI-powered workflows, exfil rules, and more
LimaCharlie MCP server demonstrates solid definition quality with comprehensive tool coverage (20 tools) across AI sessions, memory management, case management, and exfil rules. All tools have descriptions and explicit input schemas via mark3labs/mcp-go framework. Tool naming follows verb_noun convention consistently. However, several parameter descriptions lack specificity (e.g., enum constraints for status fields are not formally declared), and output schemas are not documented in the visible source. Error handling guidance is minimal, most tools return generic error messages without recovery hints. The server exhibits the discipline of a production system but falls short of excellence in LLM-optimization and constraint clarity.
Create a new SOC case (via ext-cases). Optionally seed it with a detection, severity and summary.
Delete a single AI memory entry from an agent record (sends a null value so the merge hook drops just that entry; other memories are preserved)
Delete an exfil rule. Use rule_type to select event or watch (default: event)
Get details of a specific org AI chat
Get the conversation history of an org AI chat
Get details of a specific org AI session
Parameter enum constraints not formally declared in JSON Schema. Status fields (session status, case status, classification) accept free-form strings instead of constrained enums. LLMs will hallucinate invalid values like 'pending' instead of selecting from 'running'/'starting'/'ended'.
Output schemas are not documented in the source. The visible tool definitions show input schemas via mcp.NewTool() builders, but return types and response structures are not specified. LLMs cannot predict what fields to expect from list_cases, get_ai_session, or get_case responses, forcing them to guess field names for downstream operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | 2024-11-05+ | v1 |
Get the conversation history of an org AI session
Get details of a specific org AI usage record
Get a single case by its case number, including the full event timeline.
List org AI chats
List the organization's AI sessions (one page)
List org AI usage records
List cases with optional filters, sorting and pagination.
List all exfil event and watch rules
Create or replace a single AI memory entry on an agent record (partial merge; other memories are preserved)
Create or update an exfil event rule (selects which event types are forwarded)
Create or update an exfil watch rule (forwards an event when a value matches at a path)
Start an AI agent session using an ai_agent Hive definition as a template. This spends AI budget.
Terminate a running org AI session
Update fields on a case (status, severity, assignees, classification, summary, conclusion, tags). Only provided fields are changed.
start_ai_session description lacks clarity on when to use overrides vs defaults. The description states 'spends AI budget' but does not explain budgeting strategy, cost implications, or when allowed_tools/denied_tools should override the definition. LLM cannot decide whether to filter tools or trust the template.
Error handling guidance is absent. Tool handlers return generic errors ('failed to set AI memory', 'failed to get organization') without recovery hints. If set_ai_memory fails due to invalid key format or permission denial, the LLM has no guidance on retry strategy or alternative actions.
Pagination results lack structure guarantees. list_cases, list_ai_sessions, list_ai_usages, and list_ai_chats all accept 'limit' and 'cursor' but the responses do not explicitly declare what fields (total_count, next_cursor, has_more) will be returned. LLM cannot reliably determine when to fetch the next page.
Parameter descriptions for complex types are incomplete. create_case accepts a 'detection' object but does not document its structure (what fields? required? format?). update_case accepts 'fields' as an arbitrary object without specifying which fields are valid (status, severity, assignees, classification, summary, conclusion, tags are listed in description but not as formal schema constraints).
Idempotency not declared. start_ai_session offers 'idempotent_key' parameter but the tool definition and description do not explicitly state: 'Passing the same idempotent_key twice returns the original session without creating a duplicate.' LLM may not trust idempotency or may misunderstand when to apply it.