MCP server providing access to Octoparse web scraping templates and workflows for data extraction tasks
Single tool 'search_templates' has a well-structured input schema with 4 parameters (id, slug, category, language), each with type and description. However, the tool description is minimal (58 chars) and lacks critical context: WHEN to use it, WHAT it returns, and HOW results are structured. No output schema is documented, LLMs cannot plan downstream calls or extract fields. Parameter descriptions are present but generic ('Template ID to fetch', 'Template slug to search by'). No error handling guidance, no pagination info despite the catalog containing ~100+ templates. The tool is read-only (low risk), but the definition quality falls short of production standards. Baseline: avg tool description 194 chars (p10=34, p90=392); this is 58 chars, below median. No documented return type violates pattern:tool baseline (100% of A+ tools have documented return types).
Search and retrieve Octoparse template metadata and schemas
No output schema documented. LLMs cannot infer what fields search_templates returns, preventing downstream tool chaining and forcing agents to guess field names.
Tool description is 58 characters, below the 10 - 1024 character guideline and well below the 194-char baseline for production tools. Lacks WHEN to use it, WHAT it returns, and prerequisites.
No pagination guidance despite catalog containing ~100+ templates. Large result sets will blow context windows. Missing limit/offset parameters and total count in response.
Parameter descriptions are generic and lack format/constraint details. 'Template ID to fetch' does not explain valid ID ranges, format, or how to discover valid IDs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2025-06-18+ | v2 |
No error handling guidance. If a template ID is invalid or slug not found, LLMs receive no recovery hints (e.g., 'Try search_templates(category=...) to discover valid templates').