This server has 8 tools with schemas visible and descriptions present, but most tools have weak descriptions (averaging ~50 chars), lack parameter descriptions for optional fields, and provide no documentation of output schemas or error handling. Naming is correct (verb-driven: get_*), but descriptions are minimal and do not explain when/why to use each tool or what fields are returned. No tool annotations (readOnlyHint/idempotentHint) are present despite all tools being read-only. Parameter schemas are present but sparse, most optional parameters like schoolId lack descriptions. The server appears to prioritize minimal descriptions over LLM-optimized clarity. This is typical of early-stage integrations (C-grade) that prioritize function over usability.

• Expand each tool description to 80 - 150 characters minimum, covering: (1) What the tool fetches, (2) When to call it (e.g., 'Use this to list all schools before filtering learners'), (3) What fields are returned (e.g., 'Returns array of {id, name, address, phone}').
• Document every parameter, even optional ones. For 'schoolId' in get_learners, write: 'Optional school ID to filter learners to a single school. Omit to fetch all learners across the district.'
• Add explicit output schema documentation in tool descriptions or as a JSON example. E.g., 'Returns: [{id: string, name: string, grade: string, school_id: string}]'.
• Add readOnlyHint annotations to all 8 tools since they are safe to call multiple times without side effects. This signals to LLMs that retries are safe.
• Document error scenarios: 'Errors: API unavailable (retry after 30s), invalid schoolId (use get_schools first), rate limited (backoff exponentially).'
• For get_lookup_data, clarify the enum values and return structure. E.g., 'Returns: {genders: [{code: string, label: string}], grades: [{code: string, label: string}], languages: [{code: string, label: string}]}'.
• Consider adding pagination parameters (limit, offset, cursor) to get_learners, get_staff, and get_parents since these could return large result sets. Without pagination, large districts will exhaust context.
• Add a note in get_parents: 'Optional: pass learnerId to get parents of one learner, or omit to get all parent records in the system.'
• Consider splitting get_integration_info into more granular tools if it returns disparate data (e.g., connection status, auth type, sync state), currently unclear what it actually returns.

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

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