Two tools with comprehensive schemas and detailed descriptions. reso_query has well-structured parameters with enums, ranges, and examples; reso_help is simpler but functional. Both descriptions exceed 100 chars and explain purpose clearly. However, output schemas are not documented, LLMs cannot predict response structure. No error handling guidance. Parameter descriptions are strong but lack actionable recovery hints. No tool annotations (readOnlyHint). Naming is clear (verb_noun pattern) but generic 'reso_' prefix doesn't distinguish tools by action.

• Document output schemas for both tools. For reso_query, specify: 'Returns {value: [{ListingKey, StandardStatus, ListPrice, ...}], @odata.nextLink?, @odata.count?}'. For reso_help, specify: 'Returns {topic, content, examples?, fields?}'.
• Add error handling guidance to descriptions. E.g., reso_query: 'If rate-limited (429), retry after 60s. If entity not found, verify entity name against reso_help entities topic. If filter syntax invalid, consult reso_help filters topic.'
• Add readOnlyHint: true to both tool definitions in setupToolHandlers() to signal safety to LLMs.
• Enhance reso_query description with entity selection guidance: 'Use Property for listings, Member for agents, Office for brokerages, Media for photos. Use expand to include related data (e.g., expand: "Media" to fetch photos with listings).'
• Add pagination best-practice note: 'For large result sets, use top (10-50) + skip for initial pages, then use @odata.nextLink from response for subsequent pages. nextLink is more efficient than skip for large offsets.'