Five tools with basic verb-noun naming (get_*, search_) and present descriptions (50-80 chars each). All tools have input schemas with typed parameters and descriptions. However, schemas lack output documentation, no return type specifications visible. Parameter descriptions are minimal (10-30 chars), below the 72-char baseline. No error handling guidance, no pagination support despite potential for large result sets, and no tool annotations (readOnlyHint present in metadata but not declared in tool definitions). Mock data suggests API integration but no validation of real API response structure.

• Document output schemas for all tools. Specify that get_vessel_positions returns an array of objects with fields: mmsi (string), latitude (number), longitude (number), speedOverGround (number), courseOverGround (number), msgtime (ISO 8601 string), etc. Use JSON Schema format.
• Expand parameter descriptions to 50-150 chars. For search_vessels, clarify: 'Search query: MMSI (9 digits), vessel name (partial match), or call sign (4 chars). Searches in order of specificity.' For get_vessels_in_area, add: 'Latitude/longitude bounds in decimal degrees (e.g., 59.9 to 60.4 for Oslo region). Returns up to 100 vessels; use limit parameter to reduce.'
• Add pagination: limit (1-100, default 20) and offset (default 0) parameters to get_vessel_positions, get_vessel_static_data, and get_vessels_in_area. Return total_count in response so LLMs know if more results exist.
• Replace silent error handling with structured error responses. On timeout, return: {error: 'timeout', message: 'API request exceeded 30s. Try a smaller geographic area or fewer vessels.', retryable: true}. On auth failure, return: {error: 'auth_failed', message: 'Invalid credentials. Check BARENTSWATCH_USERNAME and BARENTSWATCH_PASSWORD.', retryable: false}.
• Declare tool annotations in FastMCP tool definitions using readOnlyHint=true for all five tools. This signals to MCP clients that these tools do not modify state and can be safely retried.