Single tool 'extract' has a clear verb-noun name and reasonable description (68 chars). Input schema is well-defined with Zod validation (url required, schema/waitFor/extractionType optional). However, output schema is not documented, the response structure is inferred from code but not formally declared in tool metadata. Parameter descriptions are present but minimal (10-30 chars each). Error handling is implemented server-side but not surfaced in tool documentation. No tool annotations (readOnlyHint, idempotentHint) despite READ_ONLY risk classification. Lacks guidance on when to use extractionType enum values or how to structure custom schemas.

• Add formal output schema documentation: declare that response contains {success: boolean, data: object, metadata: {url, title, model, extractionType, tokensUsed?, processingTimeMs}}. Include field types and descriptions.
• Expand parameter descriptions to 50-100 chars. For 'schema', explain: 'JSON Schema object constraining extracted fields. If omitted, Gemini auto-detects structure. Example: {"type": "object", "properties": {"price": {"type": "number"}}}'.
• Add tool annotations in MCP registration: readOnlyHint=true (no side effects), idempotentHint=true (safe to retry). This signals to LLMs that the tool is safe for exploration.
• Document extractionType enum with per-value descriptions: 'auto: Detect content type automatically', 'article: News, blog posts, long-form text', 'product: E-commerce listings with price/availability', etc.
• Add error recovery guidance to tool description: 'On timeout (>30s), retry with shorter waitFor selector. On network errors, verify URL is publicly accessible. On validation errors, check schema format against JSON Schema spec.'