Single tool 'geoaoi_scan' has a basic description (127 chars, within 10-1024 range) but critical gaps: input schema is minimal (only 'target' string, no constraints or format guidance), no output schema documented, no error handling guidance, and the description lacks WHEN/WHY context. The tool name lacks a clear action verb (scan is weak; 'analyze_geospatial_aoi' or 'detect_geofence_violations' would be stronger). No parameter description for 'target', LLMs cannot infer whether it expects a file path, coordinate string, or identifier. The description mentions 'bounding boxes, geofence checks, and change-event diffs' but the actual implementation (visible in ports) only scans for TODO/FIXME/XXX markers, description does not match implementation. No documented output structure, pagination, or error cases.

• Add a detailed parameter description for 'target': 'File path or directory to scan for geospatial markers (absolute or relative). Supports single files or recursive directory traversal. Returns findings for TODO, FIXME, XXX markers.'
• Document the output schema explicitly: 'Returns {tool: string, findings: [{id: string, sev: string, where: string}], score: number}. Each finding includes a marker ID, severity level, and file path.'
• Correct the tool description to match actual behavior: 'Scans files and directories for code markers (TODO, FIXME, XXX) and returns findings with severity levels and locations. Useful for identifying incomplete or flagged code sections.'
• Rename tool to a stronger action verb: 'find_code_markers' or 'scan_for_code_flags' to make intent explicit.
• Add error handling examples: 'If target path is invalid, returns error with available paths. If directory is empty, returns empty findings list with score 0.'