Loading ToolBench
MCP server exposing CTI database search, SIGMA rules, sources, and workflow status as tools for LLM clients. Provides semantic search over threat intelligence articles, SIGMA detection rules, and workflow execution tracking.
The server has 24 tools with mostly present descriptions and parameter schemas. However, there are significant gaps: (1) Parameter descriptions are often minimal or missing type constraints. For example, 'limit' parameters lack min/max specifications; (2) Output schemas are not documented anywhere in the provided code, no tool specifies what fields or structure will be returned; (3) Error handling guidance is absent, tools do not indicate what to do if a search returns no results or a database query fails; (4) Some tool names are generic or unclear (e.g., 'execute_sql', 'list_tables', 'queue_sigma_mutation'); (5) Tool composition shows poor chaining, for instance, 'search_articles' and 'get_article' exist, but output from search is not shown to include article_id; (6) Several WRITE tools lack confirmation or dry-run patterns (delete_annotation, cancel_workflow, request_article_deletion). The server is in the 'fair to good' range, with solid naming conventions and descriptions present, but lacking production-grade rigor in schemas, error guidance, and output documentation.
Cancel an active workflow execution
Create a new annotation on an article
Delete an annotation
Execute a read-only SELECT query directly against the database (permanently read-only)
Retrieve full article content by ID
Retrieve the diagnosis context bundle and extractor contracts for agent-side diagnosis (no server-side LLM call)
Retrieve evaluation run evidence and metadata by label (e.g., v5139a)
Fetch the full YAML and metadata for a SIGMA rule by its UUID
Output schemas are completely undocumented. No tool specifies what fields, types, or structure will be returned. LLMs cannot plan downstream tool calls or extract correct data without knowing response structure.
Numeric parameters (limit, offset) lack min/max constraints and defaults. For example, 'limit' could be 0, 1000000, or unbounded. No guidance on what happens when limit exceeds server capacity.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
List all configured CTI data sources
Get database statistics including article count and SIGMA rule count with RAG embedding coverage
Retrieve detailed workflow execution trace to avoid MCP result-size limits
List recent workflow executions with status
List all available SIGMA rules
Discover the database schema by listing available tables
Mark an article as reviewed in the database
Queue a SIGMA rule mutation for human review and confirmation
Create a pending request for article deletion requiring human confirmation
Retry a failed workflow execution
Save evaluation diagnosis with user confirmation attestation
Semantic search over threat intelligence articles using natural language queries
Search SIGMA detection rules by natural language query
Search both articles and SIGMA rules simultaneously
Enable or disable a CTI data source
Update an existing annotation
Error handling guidance is absent. No tool describes what to do if a search returns zero results, a database query fails, a workflow doesn't exist, or permission is denied. Agents have no recovery path.
Destructive operations lack confirmation or dry-run support. delete_annotation, cancel_workflow, and request_article_deletion can permanently modify state without reversibility hints or confirmation patterns.
Tool names are ambiguous or generic. 'queue_sigma_mutation' (what kind of mutation?), 'list_tables' (for what database?), 'execute_sql' (where is the security gate?), and 'toggle_source' (enable or disable what exactly?) require LLM guesswork.
Parameter descriptions lack format guidance. 'annotation_type' says 'Type of annotation (e.g. comment, tag)' but doesn't state if it's an enum or free-form string. 'mutation_type' similarly lacks constraint definition.
Tool chaining data is unknown. Search tools (search_articles, search_sigma_rules) don't document whether their output includes the IDs needed for downstream get/update tools. This forces agents to guess or make extra discovery calls.
SQL injection and command injection risk. execute_sql accepts arbitrary SQL queries. No validation, sanitization, or guardrail description is documented. If an LLM is tricked into passing a malicious query, database could be compromised.
Pagination not fully specified. list_sigma_rules and list_tables accept offset/limit but don't document total count, next_cursor, or whether results are sorted. Agents cannot reliably paginate or know if they've reached the end.