10 tools with complete schemas and descriptions. Naming is domain-specific but lacks action verbs (e.g., 'building_violations' instead of 'get_building_violations'). Descriptions are solid (100-200 chars, domain-grounded) but generic for similar tools. Parameters are well-typed with enums for borough. Output schemas are not documented in the source. Error handling is minimal, no recovery guidance or actionable error messages visible. No tool annotations (readOnlyHint, etc.). Composition is good: each tool has one responsibility, and parameters chain well (house_number/street/borough used consistently). Security: no secrets in params, read-only operations only.

• Rename all tools to start with action verbs: 'get_building_violations', 'search_landlord_portfolio', 'lookup_evictions', etc. This matches the 90% baseline of A+ tools and helps LLMs parse intent from the name alone.
• Document output schemas for all tools. Include field names, types, and descriptions. Example: 'Returns array of {violation_id: string, class: string, status: string, date: ISO8601}'. This enables LLM planning and field extraction.
• Add tool annotations to all tools. Set readOnlyHint: true for all 10 tools since they only read data. This signals to agents that these operations are safe to retry without side effects.
• Implement structured error responses with recovery guidance. Example: 'Address not found. Try search_buildings() with a partial street name, or verify the borough spelling (Bronx, Brooklyn, Manhattan, Queens, Staten Island).'
• Disambiguate overlapping tools by renaming: 'hpd_violations' vs 'dob_violations', 'hpd_complaints' vs 'building_311_complaints'. This prevents LLM confusion when multiple tools serve similar purposes.