Two tools with complete Zod schemas and descriptions. Naming follows verb_noun convention (search_articles, search_images). Descriptions are adequate (150-180 chars, within baseline 194 avg). All parameters have type definitions and descriptions. However, output schemas are not documented, LLMs cannot infer response structure. Parameter descriptions lack format constraints (e.g., YYYYMMDDHHMMSS format stated but not validated). No error recovery guidance. Missing tool annotations (readOnlyHint). Moderate gaps prevent higher scores.

• Document output schemas explicitly. Define response structure: { articles: [{ id, title, url, date, tone, ... }], total: number, nextCursor?: string }. Include field types and descriptions.
• Add readOnlyHint annotation to both tools in FastMCP registration: server.addTool({ ..., readOnlyHint: true }).
• Implement input validation in execute handlers. Validate maxRecords ∈ [1,250], parse/validate startDateTime/endDateTime as YYYYMMDDHHMMSS, reject invalid sort enums before API call.
• Enhance error messages with recovery guidance. Catch specific error types (timeout, 404, rate limit) and return: 'API timeout after 30s. Retry with smaller maxRecords or narrower timespan.' instead of generic 'Failed to search'.
• Add pagination support. Return { articles: [...], total: number, nextCursor?: string } and accept optional cursor parameter. Document in tool description: 'Returns up to 50 results; use nextCursor for additional pages.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry