Loading ToolBench
Model Context Protocol (MCP) server that integrates AgentQL data extraction capabilities.
Single tool 'extract-web-data' has a clear, action-verb name and reasonable description (119 chars, within baseline range). Input schema is present with type definitions and parameter descriptions. However, the tool lacks output schema documentation, LLMs cannot see what fields to expect from the extraction result. No error handling guidance for common failures (invalid URL, API errors, timeout). No mention of pagination, limits, or data shape constraints. The tool description does not explain when to use it vs alternatives, prerequisite conditions (URL must be public), or what structures are returned. Parameters lack format/length constraints. No idempotency guidance. This is a functional but minimally-documented tool suitable for internal use; production-grade tools would include output schema, error recovery guides, and richer parameter descriptions.
Extracts structured data as JSON from a web page given a URL using a Natural Language description of the data.
Output schema not documented. Tool returns 'data' field as a plain object with no type or field definitions. LLMs cannot reason about the structure or plan downstream tool calls without knowing what fields/types are in the response.
Error handling lacks recovery guidance. If AgentQL API fails, the error message is 'AgentQL API error: {statusText}', no indication whether to retry, what caused the failure, or how to fix it. Per pattern:recovery-guide, errors must tell the LLM what to do next.
Parameter descriptions lack format/constraint details. 'url' param description does not specify format (must be http/https, must be reachable, etc.). 'prompt' param has no guidance on length, language, or clarity requirements. Per review:param-validation-rules, constraints should be explicit in descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Tool description lacks WHEN-to-use guidance. No explanation of prerequisites ('URL must be publicly accessible'), use cases, or disambiguation vs similar data-extraction tools. Per pattern:tool-description, descriptions must state WHAT, WHEN, and prerequisites.
No idempotency or rate-limit guidance. If the same extraction is requested twice, will the tool return consistent results? Are there rate limits? Agents may retry on transient failures, lack of idempotency guarantees invites unintended duplicate API calls.