Two tools present, both with minimal schema documentation and generic descriptions. Tool definitions are visible in src/server.py with @mcp.tool() decorator, but input parameters are completely absent from both tools (empty {} in both cases). Descriptions exist but are extremely brief (under 50 chars) and lack actionable context for LLM selection. No output schemas documented. No error handling guidance provided to agents. No parameter validation or type information. This server falls well below production baselines for tool definition quality.
Retrieve all courses student is enrolled in from Schoology.
Retrieve upcoming assignments from Schoology.
Both tools have empty input schemas ({}). No parameters are declared, typed, or described.
Tool descriptions are under 50 characters and lack context. 'Retrieve all courses student is enrolled in from Schoology' (56 chars) and 'Retrieve upcoming assignments from Schoology' (44 chars) do not explain WHEN to use the tool, what downstream tools expect, or any dependencies. LLMs cannot disambiguate based on these descriptions.
No output schemas documented. The agent does not know what fields to expect from either tool. get_enrolled_courses returns [{'courseTitle': ..., 'sectionTitle': ...}] but this is not documented in the tool definition. get_upcoming_assignments returns [{'title': ..., 'due': ..., 'class': ...}] but again, undocumented. LLMs must guess the structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 28 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 28 | - | v1 |
No error handling or recovery guidance. get_upcoming_assignments has a bare except clause that returns a generic error dict with key 0 (invalid), but does not tell the LLM how to recover. Requests exceptions are logged but not turned into actionable error messages.
Credentials are injected at initialization (browser cookies loaded in SchoologyConfig.__init__), but error messages may expose URLs and internal state. The server relies on browser_cookie3, which is fragile, if cookies expire, the entire server fails at startup and there is no graceful recovery for the agent.
No pagination support. Both tools return full lists with no limit, offset, or cursor. If a student has 50 courses or 100 upcoming assignments, the entire response bloats the context window. Baselines recommend capping results at 20 - 50 and offering pagination.
Unnecessary response fields not stripped. get_enrolled_courses returns only two fields per course, which is good, but get_upcoming_assignments returns datetime objects (not ISO 8601 strings), which are not JSON-serializable and will cause errors when the response is marshaled. Dates should be ISO 8601 strings or human-readable formats.