Loading ToolBench
MCP server for Weld web scraping API — enables AI agents (Claude, OpenClaw, etc.) to scrape social platforms
Weld MCP Server demonstrates solid tool definitions with consistent naming, complete parameter schemas, and descriptive text. All 8 tools follow verb_noun patterns (list_, create_, get_, cancel_). Input parameters are well-typed using Zod and include descriptions. However, output schemas are not formally documented, responses are returned as JSON text blobs without explicit schema declarations. Error handling guidance is minimal. Tool descriptions are adequate (100-300 chars) but lack prerequisite clarity and dependency hints. The server shows evidence of professional production intent but falls short of A-grade polish.
Cancel a pending or processing scrape job. Credits will be refunded. Cannot cancel completed or failed jobs.
Create a new web scraping job. Provide a scraper slug (from list_scrapers) and an array of input objects. Each input typically has a 'url' field. Returns the job ID and credits reserved. The job runs asynchronously — use get_job to check status.
Check your current Weld credit balance. Credits are consumed when scrape jobs complete. Use this to verify you have enough credits before creating a job.
View your credit transaction history (purchases, deductions, refunds).
Get the status and details of a scrape job. Use this to check if a job is complete before fetching results. Status values: pending, processing, completed, partial, failed.
Output schemas are not formally documented. All tools return JSON text responses via content[].text without explicit return type declarations. LLMs cannot parse expected fields, risks hallucination when chaining tools.
Error handling lacks actionable recovery guidance. No tool descriptions specify what to do on failure (e.g., 'If job not found, call list_jobs to verify job ID'). HTTP errors bubble up as plain text.
Tool descriptions lack dependency hints. create_scrape_job says 'Get available slugs from list_scrapers' but does not specify when a user should call list_scrapers first (always? only if unknown?). Agents may not plan the discovery step.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Fetch the scraped data results from a completed job. Returns an array of result objects with the extracted data. Only call this after get_job shows status 'completed' or 'partial'.
List your recent scrape jobs. Optionally filter by status. Returns job summaries with IDs, status, and scraper info.
List all available Weld scrapers. Returns scraper slugs, platforms, descriptions, credit costs, and output fields. Call this first to discover what data you can extract.
No idempotency hints or confirmation pattern for reversible operation cancel_job. Tool description says 'Credits will be refunded' but does not clarify whether repeated cancellations are safe or risk double-refund bugs.
Pagination patterns inconsistent. list_jobs and get_job_results accept limit but do not document cursor/offset patterns, total counts, or when results are truncated. Agents cannot reliably iterate large result sets.
Missing rate limiting and quota guidance. No tool documents credit consumption rates, rate limits, or quota exhaustion behavior. Agents could be surprised by sudden failures when credits run out.