Loading ToolBench
MCP Server that generates Master Content Plans (MCPs) based on topics. Searches for relevant resources on the web, organizes them into structured learning paths, and returns complete MCPs in JSON format.
This HTTP-based MCP server exposes 7 tools with mixed quality. Most tools have descriptions and basic parameter schemas, but several critical quality issues reduce the score: (1) Tool names lack clear action verbs in some cases (health_check is acceptable, but list_tasks, get_task_status, get_cache_stats, clear_cache are generic utility functions not core to the learning-path domain); (2) Parameter descriptions are present but minimal (10-30 chars in many cases, below the 72-char baseline); (3) Output schemas are defined in Pydantic models (MCP, TaskInfo, TaskCreationResponse) but not explicitly documented in tool responses; (4) Error handling exists (HTTPException with 404, 400, 500 status codes) but lacks actionable recovery guidance (e.g., no suggestions on what to try next); (5) The two primary tools (generate_mcp, generate_mcp_async) have identical parameter sets, suggesting potential composition/duplication issues. Positive signals: Proper FastAPI schema validation with constraints (min_length, ge/le bounds), CORS middleware in place, sensible caching strategy, async/background task support. However, the server is primarily a utility wrapper around web scraping/content sourcing, not a full agentic toolkit.
Clear the cache. This endpoint allows clearing the cache based on a pattern. Use with caution as it will remove cached data.
Generate a Master Content Plan (MCP) for a given topic. This endpoint: 1. Searches for relevant resources on the web 2. Organizes them into a structured learning path 3. Returns a complete MCP in JSON format
Generate a Master Content Plan (MCP) for a given topic asynchronously. This endpoint: 1. Creates a background task to generate the MCP 2. Returns immediately with a task ID 3. The client can check the task status using the /status/{task_id} endpoint
Get cache statistics. This endpoint returns statistics about the cache, including the number of items in the cache and information about the domain method cache that stores which scraping method works best for each domain.
Get the status of a task.
Health check endpoint to verify the server is running.
Primary domain tools (generate_mcp, generate_mcp_async) are duplicates with identical parameter signatures. This violates the single-responsibility principle, split sync/async into separate concerns or pick one canonical approach.
Utility tools (health_check, get_task_status, list_tasks, get_cache_stats, clear_cache) lack meaningful descriptions and serve operational/maintenance purposes rather than user-facing learning-path tasks. They dilute the tool namespace and increase LLM reasoning overhead when selecting the primary generate_mcp tool.
Parameter descriptions are too brief (10-40 chars vs. 72-char baseline). Examples: get_task_status 'task_id' = 'The ID of the task to check' (30 chars), list_tasks has empty input schema. Descriptions lack context on when/why to use these utilities and what they return.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
List all tasks.
Error responses use raw HTTP status codes (404, 400, 500) with generic HTTPException messages ('No resources found', 'Error generating MCP'). No recovery guidance provided to the agent, e.g., 'No resources found for topic X. Try: (1) broadening the topic, (2) using a different language, (3) checking internet connectivity.'
Output schemas (MCP, TaskInfo, TaskCreationResponse) are defined in schemas.py but not documented in tool docstrings or responses. LLM has no visibility into field names, types, and meaning without reading Pydantic definitions. Response structure must be explicit in tool descriptions.
The async workflow (generate_mcp_async → get_task_status in a loop) is not idempotent. If an agent retries generate_mcp_async with the same topic, it may create duplicate tasks instead of returning the cached result. No task deduplication or idempotency key mechanism is documented.
Cache clearing (clear_cache) has no permission checks and accepts a glob pattern, making it a footgun for accidental data loss. No confirmation step or dry-run mode. An agent could wipe the entire cache with pattern='*' before realizing the impact.
Tool naming inconsistency: 'generate_mcp' and 'generate_mcp_async' both start with the same verb but differ only in async suffix. Standard MCP pattern is to expose async as the default and let the client decide on timeout/polling strategy. Current design forces the agent to reason about which to choose.