This GIS format conversion server provides 9 tools with consistent naming (verb_noun pattern), complete JSON schemas for all tools, and reasonable descriptions. However, there are significant gaps: (1) output schemas are not documented, LLMs cannot predict what fields to expect in responses, (2) parameter descriptions are generic and lack format/constraint guidance, (3) error handling provides no recovery guidance, (4) no tool annotations (readOnlyHint/idempotentHint), and (5) no evidence of input validation or security checks. The tool set is well-scoped (each does one thing), but the definitions would benefit from stronger LLM-optimized descriptions and explicit output documentation.
Output schemas are not documented. LLMs cannot predict what fields the response will contain, forcing them to guess or retry on parsing errors. E.g., does wkt_to_geojson return {"geojson": {...}} or just {...}? Does csv_to_geojson include an error count?
Parameter descriptions lack actionable format/constraint guidance. E.g., 'delimiter (default is comma)' does not explain whether it can be any single character, whether it must be a single char, or what happens if the delimiter appears in data. 'Quantization parameter for simplification (0 to disable)' lacks units or valid range.
csv_to_geojsongeojson_to_topojsongeojson_to_kml
HIGH
Recommendations
Add explicit output schema documentation to all tools. In the server code, augment the tool definition with an 'outputSchema' field. Example: {name: 'wkt_to_geojson', ..., outputSchema: {type: 'object', properties: {geojson: {type: 'object', description: 'Converted GeoJSON object'}, success: {type: 'boolean'}}, required: ['geojson', 'success']}}. This lets LLMs predict and parse responses correctly.
Enhance parameter descriptions with explicit constraints. Replace 'CSV delimiter (default is comma)' with 'Single-character CSV delimiter (e.g., comma, semicolon, tab). Default: ",". If the delimiter appears in data, ensure fields are quoted.' Replace 'Quantization parameter' with 'Quantization factor for TopoJSON simplification: 0 = no simplification, 10000 = strong simplification. Valid range: 0 - 100000. Default: 10000.'
Add error-handling logic that categorizes failures and returns actionable guidance. Wrap each tool handler in a try-catch that: (1) catches specific errors (CSV parse error, KML parse error, etc.), (2) classifies as retryable or fatal, (3) returns a helpful message. Example: 'CSV parse failed: missing latitude field. Available fields: [lon, lat, elevation]. Did you mean latfield="lat"?'
Add tool annotations to all tools. Set readOnlyHint: true and idempotentHint: true for all conversion tools (they do not modify state). This signals to agents that these tools are safe to retry and do not have side effects. Example: {name: 'wkt_to_geojson', description: '...', readOnlyHint: true, idempotentHint: true, inputSchema: {...}}.
No error handling or recovery guidance. The code catches errors and returns them as text, but does not categorize them (retryable vs. fatal) or explain to the LLM what to do next. E.g., if csv_to_geojson fails due to a missing latitude field, the LLM receives a raw error with no suggestion to check field names or retry.
Tool descriptions are generic and do not explain when to use one tool over another (e.g., when would an agent choose geojson_to_wkt vs. geojson_to_csv?). Descriptions lack dependencies or prerequisites (e.g., csv_to_geojson does not mention that latitude/longitude fields must exist in the CSV).
No tool annotations (readOnlyHint, idempotentHint, destructiveHint) are declared. All 9 tools appear to be read-only and idempotent, but LLMs cannot infer this without explicit hints. Tool annotations enable safer agent planning and retry logic.
Input validation is missing. The server accepts parameters but does not validate them against constraints before processing. E.g., csv_to_geojson does not check that latfield and lonfield exist in the CSV; kml_to_geojson does not validate KML syntax; coordinates_to_location does not validate latitude/longitude ranges (must be -90..90 and -180..180). LLMs receive cryptic runtime errors.
Implement input validation before processing. In csv_to_geojson, parse the CSV header and verify latfield/lonfield exist; return a clear error if missing. In coordinates_to_location, validate latitude ∈ [-90, 90] and longitude ∈ [-180, 180]; reject invalid ranges with guidance. In kml_to_geojson, wrap KML parsing and return a syntax error message if parsing fails.
Expand descriptions to 100-150 characters and explain when to use each tool. Example: 'Convert WKT (Well-Known Text) format to GeoJSON. Use this when you have geography data in WKT format (POINT, POLYGON, etc.) and need to work with it in GeoJSON. Requires valid WKT syntax.' This helps LLMs decide which conversion tool to invoke.
Add pagination/limit guidance. If any tool could return very large results (e.g., a GeoJSON with thousands of features), document a reasonable limit and explain how to handle large datasets in the description.
Document what happens when input is invalid or empty. E.g., 'If CSV is empty or has no rows, returns an empty GeoJSON FeatureCollection. If latitude/longitude values are non-numeric, the conversion will fail with a clear error message.'