Loading ToolBench
MCP server that logs into Schoology in a headless browser, mirrors courses/materials/assignments into SQLite, downloads files, and answers questions from the local index.
Schoology-mcp demonstrates solid naming conventions (verb_noun pattern: schoology_status, schoology_sync, schoology_search) and comprehensive descriptions (avg 180 chars, well above 10-char minimum). All 11 tools have descriptions explaining WHAT, WHEN, and WHY. Input schemas are present and typed for all tools. However, several parameters lack descriptions (e.g., schoology_sync's with_assignment_detail parameter description is incomplete in visible code), and output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal; tools return JSON but lack recovery guidance or error categorization. No tool annotations (readOnlyHint/destructiveHint) despite clear risk distinctions (READ_ONLY vs WRITE). Parameter constraints are loose (e.g., 'kind' accepts free-form strings instead of enums). Overall: good naming and descriptions, but incomplete schemas and weak error handling prevent higher scores.
List assignments in a course, with due dates, points, and submission status.
Is the local mirror still current? One request, ~1 second. Reads Schoology's notifications feed, which names every course with recent activity and the exact items posted. Compares that against the mirror and reports which courses have drifted. Far cheaper than a full sync, which walks every folder of every course.
List all courses in the mirror, with folder structure and material counts.
Download a single material file if not already downloaded.
Get details of a single material, including extracted text if available.
List materials (documents, assignments, links, etc.) in a course or folder.
Output schemas not documented. LLMs cannot predict response structure (e.g., what fields schoology_status returns, what schoology_search result objects contain). Forces LLMs to guess and parse unstructured JSON.
Parameter 'kind' accepts free-form strings instead of enums. Visible in schoology_profile (kind: preference|struggle|misconception|strength|goal|note), schoology_materials (kind: document|assignment|link|page|discussion|quiz|album), schoology_search (kind: document|assignment|link|page|discussion|quiz|album). LLMs will hallucinate invalid values without enum constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
What we know about how this student learns — read this BEFORE tutoring. Returns their stated preferences, the topics they've struggled with, the specific misconceptions they've hit, and what they've already mastered, so an explanation can build on what worked rather than starting from zero.
Record what we learn about how this student learns as we tutor them.
Search the local mirror for materials, assignments, and extracted text. Returns ranked results from both keyword and semantic search.
Report login state, configured district domain, database contents, and when each course was last synced. Call this first if anything looks stale.
Refresh the local mirror from Schoology.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). Tools clearly marked READ_ONLY vs WRITE in metadata, but MCP annotations not applied. Agents cannot infer safety/retry semantics from tool definitions alone.
Error handling lacks recovery guidance. Tools return JSON errors (e.g., 'not_logged_in' with fix hint in schoology_status) but most tools do not document error cases or suggest next steps. Agents cannot self-correct on failures.
Parameter descriptions incomplete or missing in visible code. E.g., schoology_sync's with_assignment_detail parameter description cut off mid-sentence. Some parameters lack type hints or constraints (e.g., course_id, material_id are strings but no format/length guidance).