Loading ToolBench
MCP server for RIGEL Engine providing multi-LLM orchestration tools, system operations, RSS feed parsing, web scraping, and user-defined custom tools via FastMCP
Rigel Tool Server has significant definition quality gaps. While 10 tools are defined with names and basic descriptions, most lack comprehensive schemas, parameter descriptions are minimal, and error handling is absent. The tool set exhibits concerning security issues (execute_command, create_temp_program) without permission gates or destructive operation warnings. Many tools have descriptions under 50 characters. Parameter objects show type declarations but lack individual parameter descriptions. No output schemas are documented. The server appears to expose command execution and file system access as bare MCP tools without safeguards.
Create and execute a temporary program in one operation.
Create a temporary program file with the given content.
Create a new tool for a tenant
Delete a tool for a tenant
Execute a system command safely with timeout and output capture.
Execute a temporary program with optional arguments and interpreter.
Get the code for a specific tool
Tool 'create_and_execute_program' combines multiple responsibilities (create AND execute) in a single tool, violating single-responsibility principle. This forces the LLM to either always use both steps or decompose the tool mentally.
DESTRUCTIVE operations (execute_command, execute_temp_program, create_and_execute_program, delete_tool) expose system-level command execution without destructiveHint annotations, permission gates, or confirmation patterns. An agent can delete all tools or execute arbitrary commands without safeguards.
Output schemas are completely undocumented for all 10 tools. LLMs cannot infer what fields a tool returns, making it impossible to chain tools (e.g., if create_tool returns a tool_id, that ID must be documented so agents can pass it to get_tool_code).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Get all tools for a specific tenant
Send a desktop notification using notify-send
Update an existing tool
Parameter descriptions are either missing or trivial (under 20 characters) for ~80% of parameters. E.g., 'Directory to execute command in' lacks details on path format, symbolic links, or permission requirements. LLMs cannot validate input without explicit constraints.
Tool descriptions are often too brief (under 50 chars) and lack actionable context. E.g., 'Get all tools for a specific tenant' (31 chars) does not explain pagination, response structure, or when to call this vs. get_tool_code.
No error handling or recovery guidance. Tools return success/failure with no context on why a call failed or what the agent should do next. E.g., if delete_tool fails, is it because the tool is in use? Does not exist? Permission denied?
Parameters lack enums and constraints. E.g., 'interpreter' in execute_temp_program is a free-form string but should be constrained to known interpreters (python, node, bash). 'File extension' in create_temp_program allows any string but should suggest valid extensions.
Tool 'execute_command' accepts 'env' as an object parameter but does not document format, what keys/values are valid, or security implications of allowing agents to set arbitrary environment variables (e.g., PATH manipulation, secret injection).
No tool annotations present. None of the destructive tools (execute_command, delete_tool, etc.) are tagged with destructiveHint=true. No read-only operations are tagged with readOnlyHint=true. Idempotent operations are not tagged. This makes it impossible for agents to reason about side effects.
No pagination support documented for 'get_tools_for_tenant' which may return many tools. If a tenant has 1000 tools, returning all of them in one response wastes tokens and risks context exhaustion. Missing: limit, offset/page, total_count fields.
Tools referencing tools (e.g., get_tool_code) require tenant_id and tool_id, but get_tools_for_tenant response schema is undocumented. Does it return tool_id? Name? Description? Without knowing the output format, agents cannot chain get_tools_for_tenant → get_tool_code.
No default values provided for optional parameters. E.g., timeout in execute_command mentions 'defaults to self.max_execution_time' but this is vague and undocumented. Missing: explicit default value in schema or parameter description.