Loading ToolBench
The official Python library for the Arcade API - a client SDK for interacting with Arcade tools and toolkit management
This is a Python SDK client library, not an MCP server. It provides 4 tools (list, authorize, execute, get) for interacting with the Arcade API remotely. The tools have schemas and descriptions, but they are thin API wrappers exposing remote tool management functionality rather than implementing agentic patterns for end-user tasks. Naming is clear (verb_noun style). Descriptions are present but generic. Schemas are well-formed with typed parameters and descriptions. However, the tools serve API administration (discovery, authorization, execution) rather than domain-specific tasks. Error handling and idempotency guidance are absent. This scores as a competent but narrow client library rather than a rich agentic toolkit.
Authorizes a user for a specific tool by name
Executes a tool by name and arguments
Returns the arcade tool specification for a specific tool
Returns a page of tools from the engine configuration, optionally filtered by toolkit
Tools are thin API wrappers, not agentic implementations. They expose Arcade API management (list tools, authorize, execute) rather than implementing domain tasks. An agent using these tools still requires knowledge of tool names, versions, and input structures to call execute() correctly.
execute() description lacks guidance on retryability, idempotency, and error recovery. The parameter 'include_error_stacktrace' is exposed but the tool description does not explain what errors to expect, when to retry, or how to interpret failures.
execute() input parameter is 'additionalProperties:true' with no schema for the tool-specific input. The description says 'JSON input to the tool, if any' but does not guide the agent on how to structure or validate this input. This invites malformed payloads.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
list() description says 'Returns a page of tools' but does not document pagination semantics (e.g., what is the total count? is there a next_cursor?). The limit defaults to 25; without a documented upper bound, LLMs might request 10,000 tools.
authorize() 'next_uri' parameter description says 'the user will be redirected' but does not clarify the authorization flow (OAuth redirect? Modal? Polling?). LLMs cannot infer whether to wait for a callback or return control to the user.
get() and list() share 'include_format' parameter. The description says 'Comma separated tool formats' but the schema declares it as an array of enums. Enum is correct; description is misleading (arrays are not comma-separated strings).
No tools document what permissions they require (e.g., 'read:tools', 'write:authorizations'). Agents cannot reason about least-privilege configuration or scope declarations.
Output schemas are not documented in the tool definitions. The code references ExecuteToolResponse and ToolDefinition types but these are not visible in the provided source. Agents cannot predict what fields to expect (e.g., does execute() return 'result' or 'output'? is there a status field?).