WebQuest MCP exposes 5 read-only web search and scraping tools via FastMCP. All tools are explicitly registered with @mcp.tool() decorators and have basic descriptions. However, critical issues severely limit quality: (1) Input parameters are opaque Pydantic request objects (AnyArticleRequest, DuckDuckGoSearchRequest, etc.) with NO visible schema documentation in the MCP server code, the actual field names, types, defaults, and constraints are hidden in the external 'webquest' package, making it impossible for LLMs to understand valid inputs; (2) Output schemas are also undocumented, responses return Pydantic objects but their structure is not declared to MCP clients; (3) Descriptions are generic and lack guidance on when to use each tool or how they differ; (4) No parameter descriptions at all, LLMs see only type names like 'AnyArticleRequest' with no hint of what fields to pass; (5) No error handling guidance, rate limits, or recovery patterns; (6) Transport is STDIO-only, hard-capping protocol readiness. The server delegates all logic to an external 'webquest' library, providing no control over schema documentation or error responses.

• CRITICAL: Document input schemas inline. For each tool, create a JSON Schema that describes the request object's fields. Example for 'duckduckgo_search': define the DuckDuckGoSearchRequest as {type: 'object', properties: {query: {type: 'string', description: 'Search query (required)'}, max_results: {type: 'integer', min: 1, max: 100, description: 'Max results to return (default 20)'}}, required: ['query']}. Use FastMCP's schema generation or Pydantic integration to expose these schemas to MCP clients.
• CRITICAL: Document output schemas. For each tool, add a docstring or annotation describing the response structure. Example: '@mcp.tool() async def duckduckgo_search(...) -> DuckDuckGoSearchResponse:\n """Search the web using DuckDuckGo. Returns: {results: [{title, url, snippet}], total: int}"""'
• HIGH: Enhance tool descriptions to be LLM-optimized (50-200 chars, action-oriented). Replace generic descriptions with context-aware ones. Example: 'any_article: Fetch and parse the full text content of a web article from a URL. Use this when you need article body text, not just a search result snippet. Returns: title, content, publish_date, authors.' This signals WHAT the tool does, WHEN to use it (vs search results), and WHAT it returns.
• HIGH: Add parameter descriptions for the 'request' parameter. Document what fields the request object expects. Example for duckduckgo_search: 'request: DuckDuckGoSearchRequest with fields: query (required, string), max_results (int, 1-100, default 20), region (string, e.g. 'us-en').' This is CRITICAL because without this, LLMs cannot call the tool correctly.