Loading ToolBench
Agent-native API discovery and execution layer. Authenticated execution and discovery for AI agents via MCP, CLI, HTTP gateway, or Remote MCP. Provides access to 26,619+ API definitions with 689 source-verified entries and 22 built-in managed providers.
APIClaw MCP server exhibits solid definition quality with 14 well-structured tools. All tools have descriptions and JSON Schema input definitions with parameter details. Naming follows verb_noun conventions (discover_, get_, list_, call_, check_, start_, mission_). Most parameters include type and description fields. However, several tools lack output schema documentation, some descriptions are generic, and error handling guidance is minimal. The server demonstrates good composition patterns with tools designed for specific responsibilities (discovery, execution, status checking). Parameter validation is present but incomplete, no enums for constrained fields like 'provider' or 'category'. Output schema documentation would improve LLM understanding of chaining opportunities.
Get help and a tour of APIClaw's tool surface. Start here if you are new to APIClaw.
Execute a managed provider action through APIClaw's gateway. Provider auth stays server-side.
Check workspace tier, lifetime activation allowance, and verified PAYG status.
Health check for the current workspace (auth state, tier, gating, blockers).
Search APIClaw's catalog of 26,000+ APIs by capability. Use when the user asks 'what API can do X?' or needs provider recommendations.
Search mission templates by natural-language query. Returns ranked templates with slug, version, title, description, paramSchema, and match reasons. Ranking combines keyword relevance with live success-rate signal from providerHealth — templates whose steps call providers that have been degrading in the last 30 days slide down automatically. Use this to find the right template by intent before calling start_mission.
Output schemas not documented. Tools like discover_apis, get_api_details, list_models, start_mission lack explicit return type documentation. LLMs cannot infer what fields to expect for downstream chaining.
Constrained parameters lack enum definitions. 'provider' in call_api and list_models, 'category' in discover_apis should declare valid values as enums rather than relying on free-form strings. This invites hallucinated provider names from LLMs.
Descriptions for discovery/status tools are generic and lack action guidance. 'Get help and a tour of APIClaw's tool surface' and 'Health check for the current workspace' don't explain WHEN or WHY an LLM should call them relative to other tools. Missing dependency hints like 'Call discover_apis first if you need to find an API that can...'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
Full specs, pricing, auth, and usage examples for a specific API.
Browse APIClaw's API catalog by category.
List managed provider adapters ready for execution. Provider keys stay server-side with APIClaw.
List available mission templates and the parameters each accepts.
List recent missions in the current workspace (most recent first).
List the live APIClaw model catalog. Entries identify the model owner, serving source, and compatible gateway endpoint. Catalog presence does not prove execution readiness.
Check status, audit events, cost, and final result for a mission started via start_mission.
Start a mission — a structured, observable orchestration that runs on APIClaw's runtime. Use for multi-step tasks (e.g. 'generate a PRD'). Returns a missionId you can poll with mission_status. Legacy templates run through the hand-coded path; data-driven templates run through the v2 composition runner when template_version is pinned.
Error handling and recovery guidance absent. Tools like call_api (marked WRITE) and start_mission (marked WRITE) do not document what errors can occur, whether they are retryable, or what the LLM should do if they fail. No guidance on idempotency key reuse or conflict resolution.
Destructive operations (call_api with WRITE risk, start_mission with WRITE risk) lack confirmation or dry-run patterns. Agents could accidentally trigger costly API calls or expensive missions without a safety gate.
Parameter descriptions lack format/constraint details. 'idempotency_key' in call_api and start_mission is marked required but no format specified (length, character set, UUID vs free-form string). 'params' object in call_api has no schema or shape definition.