This server has fundamental gaps in tool definition quality. Both tools have acceptable names that start with action verbs (query_*), but descriptions are generic and lack operational context. The first tool has a descriptive schema annotation embedded in its description (table schema details), but this is poor practice, schema details belong in documentation, not the tool description. Neither tool has output schema documentation. Parameters lack descriptions in some cases (query_schools_and_neighborhoods has no description for the 'query' parameter beyond its type), and the optional school_name parameter in query_school_websites has minimal guidance. Error handling is present but returns unstructured text rather than actionable error messages. Security is a concern: query_schools_and_neighborhoods accepts raw SQL queries, which creates SQL injection risk despite the attempt to block DML statements, an attacker could still use UNION SELECT to exfiltrate data or construct subqueries. The server lacks pagination support for result sets and does not document output field structures, forcing LLMs to parse free-text results.

• Add output schema documentation to both tools. For query_schools_and_neighborhoods: 'Returns a list of objects with fields: id (integer), created_at (datetime), school_id (integer), school_name (string, uppercase), neighborhood (string).' For query_school_websites: 'Returns a list of objects with fields: school_name (string), page_url (string), content (string, up to ~500 characters of matched text).'
• Expand tool descriptions to 100-200 characters that explain WHEN to use each tool. Example for query_schools_and_neighborhoods: 'Look up structured school-neighborhood mappings for Chicago public schools. Use this to find which neighborhoods a school serves or which schools are in a neighborhood. Results are exact matches only.'
• Add parameter descriptions with format/constraint details. For 'query': 'SELECT SQL query on the schooltoneighborhood table. Use column names: id, school_id, school_name (uppercase), neighborhood. Queries returning >1000 rows may timeout.' For 'school_name': 'School name to filter by. Format: proper case (e.g., "Lincoln High School"). Matching is case-insensitive but requires exact name match.'
• Replace raw SQL parameter with a parameterized interface. Instead of accepting arbitrary SQL, offer structured filters: school_name (string), neighborhood (string), school_id (integer). Build safe SQL internally. This eliminates injection risk and makes the tool safer for agents.
• Add pagination support. query_schools_and_neighborhoods should accept optional parameters: limit (1-100, default 20), offset (0+). query_school_websites already limits to 10 but should document this and allow override: limit (1-50, default 10).

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

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