Loading ToolBench
MCP server for scraping and searching web documentation
web-docs-mcp has 2 tools with visible definitions in src/index.ts. Both tools have minimal descriptions (24-36 chars), documented input schemas using Zod, but lack critical metadata. The schemas are present but use plain object structures rather than proper JSON Schema format. No output schema documentation is provided. Parameter descriptions are minimal. No error handling guidance, no pagination support for search results, and missing several quality patterns for production use. The tool definitions are directly visible (not inferred), but the overall quality is below community baseline due to sparse descriptions and incomplete schema documentation.
Get the full content of a specific document
Search through documentation
Tool descriptions are too short (24-36 chars) and lack context. 'Search through documentation' does not explain when to use this tool vs alternatives, what format the query should be, or what constitutes a good result. Minimum recommended: 50-200 chars with WHAT, WHEN, and any prerequisites.
Input schema format uses Zod plain objects (SearchQuerySchema = { query: z.string(), ... }) rather than proper JSON Schema with explicit type declarations and descriptions per parameter. LLMs cannot reliably parse this format. Parameter 'limit' has description 'Maximum number of results to return' but no mention of valid range (1-100?) or default behavior impact. Parameter 'query' has no guidance on format, length, or special characters.
No output schema documentation. LLMs do not know what fields search_docs returns or how to interpret the 'relevanceScore' field. Return structure shows JSON stringified content, but this is not documented. Agents cannot reliably extract or chain results without explicit schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
search_docs returns results as a flat JSON string with no pagination. If the documentation site has 50+ pages matching a query, all results are returned in a single response, potentially exhausting context window. No limit enforcement, no next_cursor, no offset/page parameters documented.
No error handling guidance. If search_docs returns 0 results, the JSON response includes 'resultCount: 0' but no suggestion like 'Try a shorter query or search for a related term.' If get_document receives an invalid ID, the response is plain text ('Document with ID "..." not found'), inconsistent with successful responses (JSON) and provides no recovery path.
Parameter 'limit' in search_docs has a default (5) but no mention of min/max constraints. Agents may infer they can request 1000 results; the tool will return all of them, risking context explosion. Baseline: limit should be constrained (e.g. 1-50, default 5).
Tool names are action verbs (search_docs, get_document) but lack clarity on scope. 'search_docs' could mean search across all docs, search within one doc, or search doc metadata. Add a suffix or clarify in description: 'search_all_docs' or 'search_docs_by_query'.
search_docs response includes 'preview' field (first 150 chars) but no guidance on whether to display preview or fetch full doc. If agent needs full content, it must call get_document separately. Consider documenting this as a multi-step workflow or adding a 'fetch_full' parameter.
get_document returns full document content as JSON-stringified text, not as structured fields (title, url, content). This forces LLMs to parse nested JSON, wasting tokens and increasing hallucination risk. Return structured output: { title: string, url: string, content: string }.