Three well-named tools with strong descriptions (194 - 250 chars, above baseline 194). All parameters have types and descriptions. Input schemas are complete with proper constraints (lat/long bounds, limit 1 - 30). Tool names follow verb_noun pattern (find_*, get_*). Descriptions include actionable guidance (e.g., 'always tell the user which address this resolved to'). However, output schemas are not formally documented, responses are inferred from code. Error handling returns structured objects but lacks recovery guidance (e.g., 'try a more complete address' is present but not consistently actionable). No tool annotations (readOnlyHint, etc.) despite all being read-only. Composition is clean: three distinct tools with clear responsibilities.

• Add formal output schema documentation. Define the structure of 'churches' array (fields: id, name, distance_miles, worship_times, etc.) and 'resolved' object (matched_address, latitude, longitude). Use JSON Schema or TypedDict in docstrings.
• Add tool annotations: set readOnlyHint=true on all three tools to signal they are safe to call without confirmation.
• Enhance error responses with structured recovery guidance. Instead of {error: '...'}, return {error: '...', recovery_action: 'try_search_users', recovery_params: {...}}.
• Set sensible defaults: limit=20 for find_churches_near and find_churches_near_address to reduce agent reasoning overhead.
• Document the normalize_church() function's output schema in the tool descriptions so agents know what fields are available (e.g., 'Each church includes: id, name, address, phone, worship_times (array of {type, day, time, incomplete}).').

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry