This server exhibits severe definition quality issues. Tool schemas are largely undocumented, descriptions are minimal, and the implementation lacks the structure expected of production-grade MCP servers. Tool 1 ('execute_skill_action') has a generic one-liner description with no visible input schema in the source code. Tool 2 ('scrape_url') has a basic description but the parameter documentation is sparse and lacks critical context around anti-bot techniques, error handling, or security considerations. The implementation shows only stub methods returning hardcoded mock data, suggesting the server is incomplete. Parameter descriptions fail to explain constraints, expected formats, or when/why to use optional flags. No error categorization or recovery guidance is present. Output schemas are not formally documented. The codebase does not show proper tool registration patterns or request/response handling compliant with MCP standards.
Tool 'execute_skill_action' description is 52 chars ('Execute web scraping anti-bot bypass skill action'), generic, does not explain WHAT happens, WHEN to use it, or what it returns
Tool 'scrape_url' parameter 'use_proxy' lacks explanation of why/when proxy is needed, what happens when false, and any associated risks or side effects
Rename 'execute_skill_action' to a specific, verb-noun pattern that reflects the actual operation (e.g., 'bypass_antibot_protection', 'detect_antibot_service', or 'simulate_human_browser' depending on intent). The current name is too abstract for LLM reasoning.
Add a 50 - 150 character description to 'execute_skill_action' that explains: What anti-bot service does it target? What does it return? When should it be called vs 'scrape_url'? Example: 'Detect and bypass anti-bot protections (Cloudflare, reCAPTCHA, etc.) on a target domain. Returns protection type, bypass method, and confidence score. Call this before scrape_url to understand the threat model.'
Expand 'target_url' parameter description: 'Full HTTP/HTTPS URL of the target page. Must be a valid, absolute URI (e.g., https://example.com/path?query=value). Relative URLs, file:// schemes, and data: URIs are not supported.'
Expand 'use_proxy' parameter description: 'If true, route requests through a rotating residential proxy pool to evade IP-based rate limits. Adds ~500ms latency but increases bypass success rate from ~60% to ~95%. Default: true. Set to false only if the target allows direct access or if latency is critical.'
Score history
Overall score trend
First recorded score · v2 rubric
21/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-23
F
21
2026-07-28+
v2
Tool 'scrape_url' does not describe error conditions: What happens if target_url is malformed? If anti-bot detection fails? If proxy fails? No recovery guidance provided.
Tool 'scrape_url' parameter 'target_url' has no format constraint, validation rule, or example of accepted URL schemes (http, https only?). LLMs will guess.
No security model documented: Who is authorized to call these tools? What credentials/API keys are used for anti-bot bypass? Are they injected server-side or exposed as params? Credentials in params leak into logs.
'execute_skill_action' name is too generic. Verb-noun pattern ('execute_skill_action') is vague, what skill? What action? An LLM cannot disambiguate from the name alone.
execute_skill_action
Add error handling guidance as a separate field or section: 'Possible errors: (1) target_url is malformed → return 400 with suggestion to check URL syntax; (2) anti-bot protection blocked request → return 403 with detected protection type (Cloudflare, reCAPTCHA, etc.); (3) proxy pool exhausted → return 429 with retry-after and guidance to try again in 30s; (4) timeout after 30s → return 504 with guidance to retry with use_proxy=false for lower latency.'
Add security model documentation: Describe how credentials (API keys, proxy credentials) are injected. If credentials are secrets, never expose them as tool parameters. Use environment variables or a secret manager server-side.
Document the relationship between 'execute_skill_action' and 'scrape_url': Is execute_skill_action a prerequisite? Can they be called in any order? Recommend calling execute_skill_action first to understand the threat, then scrape_url with appropriate settings.
Add permission checks and logging: Document that calls are logged with timestamp, caller ID, target URL, and result. Specify what permissions are required (e.g., 'web-scraping:read', 'proxy:use') so the LLM knows if it's authorized.
For 'scrape_url', define output limits: 'Returns up to 1MB of extracted HTML in markdown format. For very large pages, consider using pagination or filtering the request (e.g., query a specific CSS selector) to keep response size manageable.'