Loading ToolBench
MCP server for Drools rule engine integration, providing tools for DRL validation, execution, definition management, and agentic workflow orchestration
This server has 14 tools with mixed quality. Tool naming is generally action-oriented (validateDRLStructure, runDRLWithExternalFacts, addDefinition, removeDefinition), but descriptions vary significantly in depth and clarity. Most tools have reasonable parameter descriptions, though several lack critical constraint documentation (e.g., maxActivations has no bounds specified). Input schemas are present for all tools with proper type declarations, but output schemas are entirely undocumented, critical for agent composition. The server follows basic MCP structure but lacks error handling guidance, permission gates, and idempotency documentation. This is a domain-specific (Drools rule engine) tool that is functional but not production-grade for agentic use.
Add a single Drools definition (declared type, function, global, import, etc.) to the storage. If a definition with the same name already exists, it will be replaced.
Clear all facts from the shared knowledge base session
Execute rules multiple times with different fact sets in batch mode
Execute rules with JSON facts using the shared knowledge base
Generate complete DRL code from all stored definitions with optional package name
Get a list of all stored Drools definitions with their names, types, and summary information.
Get a specific definition by name, including its full content.
No output schemas documented for any tool. Agents cannot plan downstream calls or extract fields. LLMs must parse unstructured responses, wasting tokens and increasing hallucination risk.
Numeric parameters lack bounds. 'maxActivations' appears in 3 tools but has no documented min/max constraints. LLMs can pass absurd values (negative, zero when disallowed, extreme values) causing unpredictable behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Get a summary of all stored definitions organized by type
Get status and information about the shared knowledge base
Enhance and expand the knowledge base with new business logic based on detailed specifications. This tool analyzes domain requirements and implements sophisticated decision-making capabilities.
Remove a stored definition by name
Executes Drools DRL code with external facts provided as JSON and returns all facts in working memory after rule execution. Use this when you have DRL rules that need to process specific data objects. The DRL should contain rules but may not need data creation rules since facts are provided externally. External facts should be provided as JSON objects with a '_type' field to specify the object type. Returns JSON-formatted list of all facts in working memory after rule execution.
Executes external facts against all stored DRL definitions and returns all facts in working memory after rule execution. This uses the combined DRL from all stored definitions (declared types, functions, globals, imports, and rules) to process the external facts. External facts should be provided as JSON objects with a '_type' field to specify the object type. Returns JSON-formatted list of all facts in working memory after rule execution.
Validates the Drools DRL code is correctly structured
Generic/minimal descriptions on 6 tools. 'Get a list of all stored Drools definitions' (getAllDefinitions) and 'Get a summary of all stored definitions' (getDefinitionsSummary) don't explain when to use one vs the other, what the difference is, or what format is returned.
Destructive operations lack error classification and recovery guidance. removeDefinition and clearFacts provide no dry-run capability, confirmation steps, or guidance on what to do if the operation fails.
No permission checks or scope declarations documented. Tools that delete definitions or clear working memory should verify authorization. No audit trail guidance for compliance.
Complex parameter relationships undocumented. 'runDRLWithExternalFacts' has both 'drlCode' and 'externalFactsJson', the description doesn't clarify what happens if drlCode declares types that don't match externalFactsJson, or error recovery if JSON parsing fails.
No idempotency guarantees documented. If an agent retries 'addDefinition' with the same name, does it replace (idempotent) or error (not)? 'improveKnowledgeBase' may generate different rules on retries, unclear if it's safe to retry on timeout.
Error handling lacks actionable guidance. No tool documents what errors are retryable, what require user input, or what information to return when validation fails (e.g., DRL syntax errors, JSON parse failures).