GeoAgent defines 13 tools with complete input schemas and descriptions. Naming follows verb_noun convention (inspect_*, plan_*, assess_*, run_*, validate_*) and is generally clear. However, descriptions are terse (10-60 chars, well below the 194-char baseline), lacking context on WHEN to use each tool and what downstream actions they enable. Output schemas are not documented, LLMs cannot predict what fields to extract for chaining. Error handling and recovery guidance are absent. Two write tools (run_approved_vector_postgis_workflow, run_approved_recipe) lack confirmation/dry-run patterns despite irreversible consequences. Parameter descriptions are minimal; execution_envelope and plan_filename lack detail on expected structure.

• Expand tool descriptions to 100-200 chars. Include WHEN to use (e.g., 'Call this after plan_postgis_promotion to verify the new table matches the reference'), prerequisites, and what the tool returns at a high level.
• Document output schemas for all tools. For plan_* tools, specify: {plan_id, status, estimated_impact, next_step}. For assess_* tools, specify: {assessment_result, confidence, details}. This enables LLM chaining.
• Add dry-run or confirmation step to run_approved_vector_postgis_workflow and run_approved_recipe. Return a preview of changes before execution, or require explicit approval_confirmed=true parameter.
• Define execution_envelope schema explicitly. Document required fields (workflow_id, parameters, timeout_seconds) and provide an example structure in the parameter description.
• Add error handling guidance to all tools. Document: (1) what errors are retryable (e.g., 'PostGIS connection timeout, retry after 5s'), (2) user-fixable errors (e.g., 'Invalid SRID, must be a valid EPSG code'), (3) fatal errors (e.g., 'Approval file not found, contact administrator').