Loading ToolBench
This server exhibits severe deficiencies across naming, descriptions, parameter clarity, and schema documentation. While 22 tools are registered with @mcp.tool() decorators, most lack production-grade specifications. Tool names fail to follow verb_noun patterns consistently (e.g., 'lithops_function_executor', 'lithops_severless_executor', unclear what action they perform). Descriptions exist but are often generic docstring dumps that read like API documentation, not LLM-optimized guidance. Parameter schemas are visible but critically underdeveloped: most tools accept a single 'args: dict' with no type specificity, no nested schema definitions, and vague descriptions ('Dictionary containing mode, config, config_file, backend, storage, monitoring, log_level, and other kwargs'). This forces LLMs to guess what keys 'args' should contain. Return schemas are completely undocumented, no tool declares what it returns. Error handling is absent: no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Composition is poor: executors (tools 1 - 4) modify global state (fexec) with no transaction support; storage tools (9 - 22) operate on implicit cloud_objects lists without clear input/output contracts.
For running one function execution asynchronously.
Creates a bucket if not exists.
Delete a CloudObject from storage.
Delete multiple CloudObjects from storage.
Removes object from the storage backend.
This operation enables you to delete multiple objects from a bucket using a single HTTP request. If you know the object keys that you want to delete, then this operation provides a suitable alternative to sending individual delete requests, reducing per-request overhead.
Executor abstract class that contains the common logic for the Localhost, Serverless and Standalone executors
Parameter schemas use generic 'args: dict' with no nested type definitions. LLMs cannot determine what keys 'args' must contain or their types. E.g., lithops_function_executor accepts 'args: dict' but the description lists 10+ optional keys without JSON Schema constraints.
No output schemas documented for any tool. LLMs have no way to know what fields will be in the response, breaking downstream tool composition and forcing wasteful discovery calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | 2026-07-28+ | v2 |
Get a CloudObject's content from storage.
Retrieves objects from the storage backend.
Retrieves the configuration of this storage handler.
This operation is useful to determine if a bucket exists and you have permission to access it. The operation returns a 200 OK if the bucket exists and you have permission to access it. Otherwise, the operation might return responses such as 404 Not Found and 403 Forbidden.
The HEAD operation retrieves metadata from an object without returning the object itself. This operation is useful if you're only interested in an object's metadata.
Similar to list_objects(), it returns all of the object keys in a bucket. For each object, the list contains only the names of the objects (keys).
Returns all of the object keys in a bucket. For each object, the list contains the name of the object (key) and the size.
Initialize a LocalhostExecutor class. / Bases : FunctionExecutor
Spawn multiple function activations based on the items of an input list.
Map the map_function over the data and apply the reduce_function across all futures.
Put a CloudObject into storage.
Adds an object to a bucket of the storage backend.
Initialize a ServerlessExecutor class. / Bases : FunctionExecutor
Initialize a StandaloneExecutor class. / Bases : FunctionExecutor
An Storage object is used by partitioner and other components to access underlying storage backend without exposing the implementation details.
Executor tools (1 - 4) modify global variable 'fexec' without transaction semantics. Concurrent calls or agent retries risk state corruption. No idempotency guarantee.
Tool names inconsistently prefixed with 'lithops_' but lack clear action verbs. 'lithops_function_executor' is ambiguous, does it create, initialize, or configure an executor? Compare to 'create_executor' or 'initialize_localhost_executor'.
Typo in tool name: 'lithops_severless_executor' (should be 'serverless'). Agents may fail to match the tool if provided a correct spelling in instructions.
Map/call_async tools operate on implicit global 'future' list with no clear ownership or isolation. Concurrent agents or multi-turn scenarios risk cross-contamination.
Storage tools (lithops_delete_cloudobject, lithops_delete_cloudobjects, lithops_delete_object, lithops_delete_objects) accept DESTRUCTIVE operations with no confirmation step, dry-run option, or recovery guidance.
lithops_get_storage_config has no input parameters but input schema is empty ({}). No documentation of what fields will be returned.
No error handling guidance in any tool description. LLMs have no way to know if a failure is retryable, user-fixable (missing parameter), or fatal. No recovery paths suggested.
Tool descriptions read like raw API docstrings rather than LLM-optimized prompts. They don't answer: 'When should I call this instead of a similar tool?' or 'What are the prerequisites?' Example: 'Spawn multiple function activations based on the items of an input list' doesn't explain whether to use lithops_map or lithops_map_reduce.
Parameters like 'func' and 'map_function' accept string code ('func: str') that is then exec()'d. No validation against code injection. If an LLM is tricked into passing malicious Python, it will execute in the server process.