Loading ToolBench
AI-Driven RPA Orchestration server for Automation Anywhere Control Room integration using FastMCP
This server exhibits severe definition quality gaps across all dimensions. Tools lack proper parameter descriptions, input schemas are incomplete or missing entirely, and descriptions are minimal. The 'run_bot' tool has a single parameter with a description, but 'list_bots' and 'Auth_AA' have no documented input schemas. Output schemas are completely undocumented. Error handling is absent, exceptions are caught and re-raised without actionable guidance. Tool naming follows some conventions (verb_noun pattern) but lacks clarity about preconditions and side effects. This is a personal learning project that would not meet production standards.
Authenticate with the Automation Anywhere Control Room.
List Automation Anywhere bots names available in Control Room.
Deploy and run a bot on a main device.
Critical: list_bots() has NO input schema defined. The function signature accepts no explicit parameters, yet makes a POST request with a complex payload (filter, sort, page). The schema is entirely missing from the tool registration.
Critical: Auth_AA() has NO input schema. Function accepts no parameters and returns a string. No description of what happens, why an LLM would call it, or what 'successful' authentication means. Description is 27 chars, below the 50-char minimum for LLM decision-making.
High: run_bot input schema defines only 'bot_id' as a string with generic description 'The file ID of the bot to deploy and run'. No constraints documented (format, length, pattern). Missing: what happens if bot_id is invalid? What is the expected return? Is this call idempotent?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 24 | - | v1 |
High: NO output schemas documented for any tool. list_bots() returns (response, bot_id), tuple unpacking is unclear for LLMs. run_bot() and Auth_AA() return values without documented structure. LLMs cannot plan downstream operations without knowing response fields.
High: No error handling with recovery guidance. Bare 'except Exception as e: raise' is common throughout. LLMs see only a raw exception. No categorization of errors as retryable, user-fixable, or fatal. No actionable error messages like 'Invalid bot_id. Call list_bots() to see available bots.'
High: Credentials exposed in environment variables without secret injection pattern. CR_USER, CR_PASS, CR_BASE_URL, MACHINE_ID loaded via dotenv at module level. While not directly exposed as tool parameters, they are accessed globally and logged to stderr (see logging in ControlRoomClient). This violates secret-injection best practices and audit-trail separation.
Medium: Tool naming ambiguity. 'Auth_AA' uses uppercase acronym and does not follow standard verb_noun pattern (should be 'authenticate_controlroom' or similar). No clear distinction between manual auth via Auth_AA vs automatic auth triggered by other tools. LLMs may call it redundantly.
Medium: list_bots description does not document pagination or result limits. Internal payload specifies 'page.offset: 0, page.length: 0' (unbounded). No mention of how many bots are returned or how to iterate if more exist. Result could exceed context window.
Medium: run_bot description does not state that this call has WRITE/destructive intent. Description says 'Deploy and run a bot' but does not clarify: Is this idempotent? Will running the same bot twice cause duplicate executions? Should confirmation be required?