Three tools with complete input schemas and descriptions, but significant gaps in output documentation and error handling. Tool names are action-oriented (scrape, map, search) and descriptions are adequate (50-80 chars). All parameters have type definitions and descriptions. However, output schemas are not formally documented, only inferred from code comments. Error handling returns raw API errors without recovery guidance. The _apiKey parameter violates secret-injection pattern by exposing it as a tool parameter, though the dual-key model mitigates risk by allowing omission.

• Document output schemas formally in tool descriptions or as separate JSON Schema definitions. Example for scrape: 'Returns {url: string, markdown: string (max 100KB), title?: string, description?: string, truncated: boolean}'.
• Remove _apiKey from tool parameters. Instead, configure the MCP server with FIRECRAWL_API_KEY environment variable or accept it via server initialization. If dual-key is required, document it in server setup, not tool signatures.
• Enhance error responses with actionable recovery steps. Wrap firecrawlPost errors: if status 401, return 'Authentication failed. Verify your Firecrawl API key.'; if 429, return 'Rate limited. Wait 60 seconds before retrying.'
• Add pagination to map() and search(). Introduce offset/limit or cursor-based pagination. Return total_count and next_cursor in responses so agents can fetch additional results.
• Clarify truncation behavior in scrape() description: 'Markdown output is capped at 100KB. If truncated=true, use formats=["html"] or call map() to discover sub-pages for full content.'