Geeflow provides complete, typed parameter schemas for all 10 tools with clear descriptions. Tool names follow verb_noun conventions (gee_init, catalog_search, build_composite). However, descriptions are inconsistent in depth, some tools lack context on when to use them vs. alternatives. Output schemas are not formally documented in the code. Error handling is minimal; most tools lack recovery guidance. The composite registry pattern (in-memory _COMPOSITES dict) is clever but undocumented in tool descriptions, forcing users to infer the composite_id workflow. Parameter descriptions are generally good (72-char baseline met), but some lack constraint details (e.g., reducer enum values not listed in build_composite description).

• Document output schemas for all tools. Add a 'Returns' section to each docstring listing field names, types, and meanings. E.g., catalog_search returns [{'id': str, 'title': str, 'provider': str, ...}].
• Explain the composite_id registry in gee_init or build_composite description: 'Composites are stored in a session-scoped registry. Use the returned composite_id in compute_indices, thumbnail, region_stats, and export_composite. Composites persist for the session duration.'
• Convert enum examples to formal constraints. In build_composite, change 'reducer defaults to median' to 'reducer: one of [median, mean] (default: median)'. In compute_indices, list all valid indices as an enum.
• Add error recovery guidance. Wrap _get() calls with try/except that returns: 'Unknown composite_id. Call build_composite first to create a composite, then reference its ID here. Known composites: [list]'.
• Document mutually exclusive parameters. In scene_availability and build_composite, add: 'Provide either aoi_geojson OR (lat + lon + optional radius_m), not both. If both are given, aoi_geojson takes precedence.'