Loading ToolBench
A polite, durable, agent-orchestrated crawler built on SMESH that provides MCP tools for bounded evidence crawling and Wayback Machine changepoint analysis
Three tools with comprehensive schemas and strong descriptions. All tools have detailed parameter documentation with constraints (enums, min/max, patterns). Descriptions are 150-250 chars, well above the 10-char minimum. Input schemas are fully specified with types and constraints. However, output schemas are not explicitly documented in the source code provided, and error handling guidance is minimal. Tool naming follows verb_noun convention (start_*, get_*). The server demonstrates good composition, each tool has a single responsibility. Risk annotations (WRITE, READ_ONLY) are present but not formally mapped to tool annotations in the MCP schema.
Read the status and bounded result of a SMESH crawl or Wayback job by its opaque job ID. Results omit server filesystem paths, credentials, raw bodies, and debug logs. Call until status is succeeded, blocked, failed, or timed_out.
Start a polite, same-origin crawl of a public HTTP(S) site to find exact evidence needles. The deterministic kernel enforces robots.txt, SSRF blocking, redirect and byte limits, pacing, scope, and a 30-page maximum. This enqueues durable local work but does not modify the target site. Repeated identical successful or active requests reuse the existing job.
Start a bounded analysis of public Internet Archive captures for a site's durable semantic transition. Use coarse year or month resolution first, then a narrow change-resolution interval. The job loads at most 36 selected snapshots, returns interval-censored evidence, and never claims an exact deployment instant.
Output schemas not documented in source. Tool descriptions state what is returned (e.g., 'returns interval-censored evidence', 'returns bounded result') but the actual response object structure is not visible in the provided code. LLMs cannot plan downstream tool calls without knowing response field names and types.
Risk annotations (WRITE, READ_ONLY) are declared in comments but not formalized as MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint). The MCP spec expects these as structured metadata in the tool definition, not free-text comments.
Error handling guidance is absent. Tool descriptions do not explain what errors can occur, how to recover, or what the LLM should do if a crawl fails, times out, or is blocked. No recovery hints like 'If blocked, try a different seed_url or reduce max_pages.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Parameter 'use_ai' and 'ai_budget' in start_crawl lack context about what 'the server's bounded OpenRouter semantic worker' means. No description of cost, latency, or when to enable it. LLMs cannot reason about whether to set use_ai=true without understanding the trade-off.
Pagination and result limits are not explicitly documented. start_crawl caps at 30 pages, start_wayback_search at 36 snapshots, but descriptions do not state 'Results are capped at X items' or explain what happens if the user requests more. No next_cursor or offset/limit pattern for iterating large result sets.