Loading ToolBench
MCP server for Proof of Data. Lets an AI agent find data missions, collect the data and get paid in $POD for verified rows.
Server has 7 well-named tools with clear descriptions and complete input schemas. Naming follows verb_noun convention (list_, get_, accept_, submit_, run_). Descriptions are detailed (100-250 chars) and explain WHEN to call each tool. However, critical gaps exist: (1) NO output schemas documented, LLMs cannot predict response structure for chaining; (2) parameter descriptions lack format/constraint details (e.g., 'slug' has no explanation of valid format); (3) no error handling guidance, tools return generic 'Error: {message}' with no recovery hints; (4) submit_delivery's 'items' parameter accepts generic objects with no field validation rules; (5) no pagination support on list_missions/list_models despite potentially large result sets. Baseline: 194 chars avg description (this server: ~150 chars, acceptable); 100% of A+ tools have output schemas (this server: 0%). Per-tool scores range 55-70.
Claim a mission for the operator so it shows up as in progress. Optional: submit_delivery accepts a mission on its own if you skip this.
Read the full brief for one mission: what to collect, the exact fields every item needs, the quality bar that gets a row rejected, example items, and how much is left in the bounty. Read this before collecting anything.
Check whether there is any data work available. Returns the open missions on Proof of Data with their reward per item, how many items are still needed, and the fields each item must have. Call this first.
Models published on Proof of Data, each trained on verified mission data, with the rows behind them.
The operator wallet, $POD balance, lifetime earnings, and the status of every delivery made so far.
Run a published model on hosted compute and get its output.
No output schemas documented. LLMs cannot predict response structure, field names, or types. Breaks tool chaining, agent cannot extract IDs for downstream calls without trial-and-error.
submit_delivery 'items' parameter accepts generic objects with no field validation. Description says 'Keys must match mission fields exactly' but provides no schema, enum, or format constraint. LLM cannot validate before submission.
No pagination support on list_missions and list_models. If result sets are large, responses blow context window. No limit, offset, or cursor parameters documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Submit collected data for review. ONLY call this after the human operator has seen the rows and explicitly approved them. Returns an AI pre-review score and the review URL. Accepted rows pay $POD to the operator wallet.
Error handling returns generic 'Error: {message}' with no recovery guidance. No categorization (retryable vs fatal), no actionable next steps, no invalid-value echoing for self-correction.
Parameter descriptions lack format/constraint details. 'slug' appears in 4 tools but has no explanation of valid format (alphanumeric? hyphens?). 'content_type' enum values listed in description, not as JSON Schema enum.