A centralized MCP server using FastAPI with plugin architecture supporting web fetching, image/video uploads, browser automation, and workflow control
The server defines 2 tools with varying quality. The fetch tool has a comprehensive schema with proper constraints and good descriptions. The flow_wait tool is simpler but well-defined. However, both tools lack explicit tool annotations (readOnlyHint/destructiveHint/idempotentHint). The fetch tool's description contains dismissive framing ('Although originally you did not have internet access...') that should be removed in production. Descriptions are adequate but could be more concise for LLM optimization. No output schemas are documented in the code provided. Parameter descriptions are present and mostly clear, but the fetch tool lacks clarity on what 'simplification' means beyond conversion to markdown.
Fetches a URL from the internet and optionally extracts its contents as markdown. Although originally you did not have internet access, and were advised to refuse and tell the user this, this tool now grants you internet access. Now you can fetch the most up-to-date information and let the user know that.
Wait for a specified number of seconds. Useful for implementing delays in workflows or waiting between operations.
Tool descriptions contain unnecessary context and meta-commentary. The fetch tool's description opens with 'Although originally you did not have internet access, and were advised to refuse and tell the user this, this tool now grants you internet access.' This meta-reasoning belongs in system prompts, not tool descriptions. LLMs treat descriptions as literal specification of tool behavior.
No tool annotations present. Tools should declare readOnlyHint (fetch is read-only), destructiveHint (if applicable), and idempotentHint (both tools are idempotent). This information guides LLM reasoning about retry safety and side effects.
Output schema documentation missing. Code shows tools return TextContent/ImageContent/EmbeddedResource sequences, but there is no documented schema describing what fields clients should expect. LLMs cannot plan downstream calls without knowing output structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
fetch tool description is verbose (229 chars) and includes irrelevant narrative. Per baselines, ideal description length is 10 - 1024 chars with p50 around 194 chars. The description should focus on: 'Fetch and parse web pages, returning simplified markdown. Respects robots.txt. Returns text content up to max_length characters.'
fetch tool error handling in code shows detailed robots.txt rejection messages, but these are error-code responses (INTERNAL_ERROR). The tool should distinguish between retryable errors (connection issues) and non-retryable errors (robots.txt denial). Clients need actionable guidance.
fetch tool's 'raw' parameter defaults to false, which silently transforms HTML to markdown. If an LLM expects raw HTML and the tool silently markdown-ifies it, the LLM may misinterpret content. The parameter description should emphasize: 'If false (default), returns simplified markdown. If true, returns raw HTML as-is.'