Two tools with complete JSON schemas and descriptions, but quality is uneven. get_weather has a clear, concise description (47 chars) and well-formed schema with enum constraint on units. query_database has a longer description (56 chars) and proper schema with enum on database. Both tools have all required parameters documented with types and descriptions. However, neither tool description explains WHEN to use it vs alternatives, what the output structure is, or error handling. Output schemas are not documented, LLMs cannot predict response fields. No guidance on error recovery. Tool names follow verb_noun pattern correctly. Parameters lack format/range constraints beyond enums (e.g., query length limits, city name format). Risk annotations (READ_ONLY) are present but not leveraged in descriptions.

• Add output schema documentation to both tools. Example for get_weather: 'Returns {city: string, temperature: number, units: string, conditions: string, humidity: number}'. This lets LLMs plan downstream use.
• Expand descriptions to 100-150 chars with WHEN/WHY context. Example: 'Get current weather for a city. Use this to answer questions about temperature, conditions, or humidity. Returns temperature in requested units (celsius or fahrenheit).'
• Add parameter constraints: city (1-100 chars, alphanumeric + spaces), query (1-5000 chars, SELECT only, no DDL/DML), database (enum already present, good).
• Document error cases and recovery paths. Example: 'If query fails, check syntax and database name. Only SELECT queries allowed, UPDATE/DELETE will be rejected.'
• Consider adding a 'units' parameter default to query_database (e.g., 'limit' param defaulting to 20) to reduce required parameters and simplify common invocations.