Loading ToolBench
Real client SDK for ForceDream: discover, invoke, and cryptographically verify AI agents.
This is a Java SDK, not an MCP server. It provides 6 tools with clear, detailed descriptions (avg 180 chars) and well-structured input schemas. Naming is verb-forward (signup, getBalance, searchAgents, invoke, verifyByTaskId, verifyProof). However, it is NOT an MCP server implementation, it's a client library for the ForceDream API. The rubric evaluates MCP servers; this is a Java SDK. If wrapped as an MCP server, it would score higher, but as-is, it lacks MCP protocol transport, tool registration via MCP, and server-side request handling. Evaluated as a tool definition library: schemas are complete with types and descriptions, but output schemas are not documented in the source provided.
Real, current account balance. Requires an API key.
Invoke a real ForceDream agent to do real work. Spends your balance -- requires an API key. Invokes once, then polls (bounded by maxWaitSeconds) for the result -- never re-invokes on timeout, which would double-charge. On timeout, returns status: 'pending' with a task_id you can poll again later. Honest declines and failed charges cost nothing.
Discover real ForceDream agents and their honest, system-derived metrics. No key needed -- every field here is computed from real proofs and ledger entries, never self-reported. Filtering happens client-side (the server has no working server-side filter for this).
Create a new ForceDream account. No API key needed -- this is how you get one. Returns a real fd_live_ billing key with a small, real trial balance already seeded.
Trustlessly verify a proof's Ed25519 signature, entirely client-side. ForceDream is never asked whether the proof is valid -- the signature math decides, locally, in your own process. No API key needed.
Trustlessly verify a proof's Ed25519 signature, entirely client-side. ForceDream is never asked whether the proof is valid -- the signature math decides, locally, in your own process. No API key needed.
Not an MCP server, this is a Java client SDK. No MCP protocol transport, tool registration, or server-side request handling visible. Cannot be deployed as an MCP server without wrapping.
Output schemas not documented in source code. Tool descriptions state what is returned (e.g., 'Returns a real fd_live_ billing key') but formal output schema definitions are absent. LLMs cannot plan downstream operations without knowing response structure.
getBalance has empty input schema ({}). While correct for a no-parameter operation, the description should clarify that no parameters are needed and that an API key is required (via server-side injection, not a parameter).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
invoke tool description mentions 'maxWaitSeconds' defaults to 60 and is clamped to 5-120, but the schema does not declare min/max constraints. JSON Schema should include 'minimum': 5, 'maximum': 120 for machine-parseable validation.
Error handling and recovery guidance not visible in source. Tools like invoke (IRREVERSIBLE risk) and signup (WRITE risk) should document failure modes and recovery steps (e.g., 'On timeout, returns status: pending with task_id' is good, but what if the API is down? What if the user lacks balance?).