Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This MCP server exhibits significant quality gaps across naming, descriptions, and schemas. While tool names follow verb_noun conventions (scrape_url, create_heading_1), descriptions are minimal and many parameters lack proper type information. Of the 15 tools assessed, only 2-3 have acceptable descriptions above 20 characters. Most critically, input schemas are present but lack nested parameter descriptions in several tools, the rubric requires descriptions for every parameter. The server mixes concerns (web scraping + Notion integration) without clear separation of responsibilities. Error handling is absent from visible code. The example code provided (Next.js components, package.json) does not correspond to the MCP server implementation, raising questions about code organization clarity.
Parameter descriptions missing or trivial. The 'data' parameter in convert_scraped_data_to_notion_blocks and create_notion_page_structure lacks specificity about required structure. LLMs cannot infer schema from a vague 'object' type.
No documented return/output schemas. Tools like scrape_url and scrape_multiple_urls provide scraped data, but the structure of returned data is not documented. LLMs cannot plan subsequent tool calls without knowing what fields are available.
No error handling or recovery guidance. Code examples and tool descriptions provide no indication of what happens on failure (invalid URL, file write failure, Notion API error). Agents cannot self-correct without actionable error messages.
Recommendations
Add documented output schemas for all tools. For scrape_url, document the structure: {title: string, content: string, links: [{href: string, text: string}], metadata: {url: string, timestamp: string}}. For Notion block creators, specify the block object structure returned.
Expand parameter descriptions to include constraints and examples. Instead of 'スクレイピング対象のURL', write: 'Target URL to scrape. Must start with http:// or https://. Timeouts after 30 seconds. Returns error if page cannot be loaded or content cannot be parsed.'
Mark optional parameters explicitly in the schema with 'required: false' and indicate default behavior. For save_to_json, document: 'filename: optional string. If omitted, generates filename as timestamp_<hash>.json in current directory.'
Add error recovery guidance. For scrape_url, document: 'Returns error_code='invalid_url' if URL is malformed (offer regex validation hint). Returns error_code='timeout' if page takes >30s (retry with smaller page or use scrape_multiple_urls with batch size 1). Returns error_code='parse_failed' if HTML structure unexpected (check if site uses JavaScript rendering, consider using selenium variant).'
Separate web scraping concerns from Notion integration. Create two logical tool groups: web_scraper (scrape_url, scrape_multiple_urls, save_to_json variants) and notion_builder (convert_scraped_data_to_notion_blocks, create_heading_1, ..., create_callout, save_notion_blocks_to_json). Document the expected workflow chain: scrape → convert → create_blocks → save.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Mixed concerns across tool set. Web scraping (scrape_url, scrape_multiple_urls), file I/O (save_to_json, save_multiple_to_json), and Notion integration (convert_scraped_data_to_notion_blocks, create_heading_1, etc.) are all exposed as a single tool set. This violates single-responsibility principle and makes composition difficult.
Optional parameters not marked as such. 'filename' in save_to_json and save_multiple_to_json is marked optional ('指定しない場合は自動生成' in description = 'auto-generated if not specified'), but JSON schema does not indicate required: false. Schema must reflect optionality.
Notion block creation tools (create_heading_1 through create_callout) lack context about how output chains into save_notion_blocks_to_json. What is the return type? Is it a single block object or a list? How does an LLM collect multiple created blocks before saving?
Add tool composition hints. Document in create_heading_1 description: 'Creates a single H1 heading block. Return value is a block object compatible with save_notion_blocks_to_json. Call create_heading_1, create_paragraph, create_bulleted_list_item in sequence, then pass results array to save_notion_blocks_to_json.' This guides LLM planning.
Specify default values and constraints. For page_size in scrape_multiple_urls (if such a parameter exists), document: 'Batch size for parallel scraping (default 5, range 1-20). Larger values faster but risk rate limiting.'
Add natural identifier support. If scrape_url currently requires full URLs, consider accepting common formats: 'Accepts full URL (https://example.com) or domain shorthand (example.com → https://example.com). Automatically appends https:// if protocol omitted.'
Document timeout and retry behavior. Every tool that calls external services must declare: 'Timeout: 30 seconds. On timeout, returns error code 'timeout' with retry guidance.' This prevents LLM from hanging.
Add batch operation hints. Note in scrape_multiple_urls: 'Preferred over calling scrape_url N times. Returns array of results with per-URL success/failure. If 3 of 10 URLs fail, returns partial results with error details per URL.' This encourages efficient agent behavior.