Loading ToolBench
MCP Server for Crawl4AI - provides web crawling and search capabilities
Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. read_url has a lengthy description (280+ chars) that lists format options but lacks actionable guidance on when to use each. search has reasonable parameter coverage but both tools lack documented output schemas, making it unclear what fields LLMs should expect. No error handling guidance, no parameter constraints (enums), and no indication of which operations are idempotent or destructive. Naming is acceptable (verb_noun pattern), but parameter descriptions are minimal. Neither tool documents what happens on failure or how to recover.
Crawl a webpage and return its content in a specified format. Args: url: The URL to crawl format: The format of the content to return. Options: - raw_markdown: The basic HTML→Markdown conversion - markdown_with_citations: Markdown including inline citations that reference links at the end - references_markdown: The references/citations themselves (if citations=True) - fit_markdown: The filtered/"fit" markdown if a content filter was used - fit_html: The filtered HTML that generated fit_markdown - markdown: The default markdown format
Perform a web search and return results. Args: query: Search query string num_results: Number of results to return, defaults to 10 engine: Search engine to use, options: - "duckduckgo": Use DuckDuckGo search (default) - "google": Use Google search (requires API key configuration)
No documented output schemas. Both tools return strings (JSON or markdown) but LLMs cannot infer what fields to expect. read_url returns markdown variants; search returns JSON results, neither documents the structure, field names, or types.
Missing parameter constraints. search engine parameter accepts 'duckduckgo' or 'google' but is not declared as an enum. LLMs may hallucinate other engine names. format parameter in read_url lists options in description but lacks enum constraint.
No error recovery guidance. Both tools catch exceptions and return error JSON, but descriptions do not tell LLMs what to do next. E.g., if a URL is unreachable, should the agent retry, try a different URL, or use search instead?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | <=2025-11-25 | v2 |
Incomplete parameter descriptions. url parameter in read_url has minimal description. num_results in search lacks range constraints (e.g., 1 - 100). Descriptions do not state expected format, length, or validation rules.
No idempotency or destructiveness hints. read_url and search are read-only, but tool definitions lack toolAnnotations (readOnlyHint) to signal this to clients. Agents cannot determine if a tool is safe to retry.