Loading ToolBench
A web application and API platform for managing AletheiaDB clusters, handling billing, authentication, and proxying requests to a Rust-based vector database engine
This server exposes 19 tools via HTTP but lacks critical definition quality. Most tools have descriptions (good), but parameter schemas are incomplete or missing type information. No input schemas visible for most tools, only descriptions and parameter names. Parameters lack descriptions in many cases. No output schemas documented. Error handling is minimal. Tool names are reasonable but some are ambiguous (e.g., 'hero_demo_store' vs 'hero_demo_recall' should be 'store_demo_memory' and 'query_demo_memory'). The api_proxy tool is a catch-all that violates single-responsibility principle. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). This is a typical community server with functional tools but poor LLM-readiness.
Activates a provisioned cluster by setting its endpoint URL and status to active (admin-only operation)
Proxies API requests to the AletheiaDB Rust engine with API key validation, rate limiting, billing checks, and namespace isolation for fractional tier users
Assembles context from a template by querying a cluster and populating template variables
Creates a Stripe checkout session for purchasing dedicated VM clusters with monthly subscription billing
Creates a Stripe customer portal session for managing subscriptions and billing
Initiates a Stripe checkout session for purchasing prepaid tokens in three packages (Starter, Growth, Scale)
Retrieves graph edges representing relationships between entities and terms in a cluster's stored memories
No input schemas visible in source code. Tools declare parameter names and descriptions but lack formal JSON Schema with type definitions. This prevents LLMs from validating inputs before calling tools.
No output schemas documented. LLMs cannot predict what fields will be returned, forcing them to guess at downstream tool chaining and data extraction.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2026-07-28+ | v2 |
Retrieves hardware statistics (CPU, memory, disk) for a cluster
Retrieves operational statistics for a cluster (requests, queries, ingests, graph operations)
Retrieves the current status of a cluster (active, provisioning, failed, etc.)
Retrieves storage statistics and table information for a cluster
Retrieves usage statistics for a cluster including daily request counts and operation totals
Retrieves status of all clusters owned by the current user
Retrieves the current user's subscription details including tier and status
Queries the demo AletheiaDB engine for memories matching a textual query, returning hits with observation blocks
Stores a message as memories in the demo AletheiaDB engine, splitting it into facts and ingesting them
Performs a health check on the demo AletheiaDB engine to warm it up and measure latency
Submits a cluster provisioning request to Azure via Supabase Edge Function
Proxies Sentry error reporting envelopes to the Sentry API
api_proxy violates single-responsibility principle. It is a catch-all that proxies arbitrary requests to the Rust engine, combining multiple concerns (auth, rate limiting, billing, namespace isolation). This should be split into domain-specific tools or wrapped with clear constraints.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe read operations from destructive writes without explicit hints. Tools like 'activate_cluster', 'provision_cluster', 'buy_tokens', and 'billing_checkout' should be marked destructiveHint=true.
Ambiguous tool naming: 'hero_demo_store' and 'hero_demo_recall' use the same prefix and differ only in action parameter. Should be renamed to 'store_demo_memory' and 'query_demo_memory' for clarity. Similarly, 'hero_warmup' is vague, should be 'check_demo_engine_health' or 'warmup_demo_engine'.