Two well-defined tools with clear naming (get_boundaries, get_geometry), complete input schemas with proper enums and descriptions, and thoughtful parameter validation. Descriptions are detailed and explain constraints (e.g., 4 MB geometry cap, ADM level restrictions). However, output schemas are not formally documented, responses are inferred from code. Error handling is present but generic. No tool annotations (readOnlyHint, idempotentHint). Naming follows verb_noun pattern correctly. Parameters have types and descriptions. Composition is clean: each tool has one responsibility.

• Add formal output schema documentation to both tools. Example for get_boundaries: 'Returns {boundaryType, boundaryISO, boundaryYear, boundarySource, boundaryLicense, gjDownloadURL, simplifiedGeometryGeoJSON, tjDownloadURL, staticDownloadURL, admUnitCount}'. Example for get_geometry: 'Returns {iso3, adm, product, source, license, admUnitCount, geojson: FeatureCollection}'.
• Add tool annotations to inputSchema: set readOnlyHint: true and idempotentHint: true for both tools. This signals to agents that these are safe, repeatable calls.
• Enhance error messages with recovery guidance. When a combination is not found (404), catch the error and return: 'ISO3 "XXX" or ADM level "YYY" not found for product "ZZZ". Verify ISO3 is valid (e.g., USA, FRA, KEN) and ADM level is supported for this country.'
• Document the 4 MB geometry cap in get_geometry's description more explicitly: 'Fetches simplified GeoJSON (typically 0.5 - 3 MB). Refuses payloads over ~4 MB to prevent context overflow; for larger geometries, use get_boundaries and download the URL directly.'
• Add a meter/cost field to callTool responses (already present in export: meter: {credits: 1}). Consider documenting cost per tool if different (e.g., get_geometry costs more due to network fetch).