Loading ToolBench
An AI-powered academic advisor for Stanford University that helps students discover suitable courses by searching Stanford's course catalog. Built as a full-stack application with a Next.js frontend, FastAPI backend, and MCP integration.
Stanford Atlas exposes 5 course discovery tools with reasonable naming (verb_noun pattern) and adequate descriptions. However, schema documentation is incomplete, while parameter types are declared, output schemas are not formally documented in the visible source. Descriptions are present but generic; they lack dependency hints and recovery guidance. Error handling is not visible in the tool definitions. The server acts as a Next.js/FastAPI wrapper around explorecourses but tool definitions are inferred from src/app/api/stream-content/prompt.ts and lack explicit MCP tool registration visible in the provided code.
Full single-course details including description, sections, schedules, instructors, attributes, GERS, etc. primary_class_id is surfaced at the top of the response so you can render a card without parsing the sections block. Only use this when you genuinely need the deeper detail; otherwise prefer search-courses or get-courses.
Batch fetch render-ready JSON records for an array of course_ids in ONE call. Returns each course's course_id, class_id, subject, code, title, units_min/units_max, term, description, gers.
List departments within a school (or across all schools if school is omitted).
Return all available schools in ExploreCourses, optionally with department counts.
Free-text course search. Each result row includes course_id AND class_id (primary section) which are needed to render a course-card or course-list. The terms filter is optional; omit it to search across all four quarters.
Output schemas not documented. Tool descriptions mention what is returned (e.g., 'Returns each course's course_id, class_id, subject...' for get-courses) but no formal JSON schema is visible for responses. LLMs cannot plan downstream calls without knowing response structure.
Parameter descriptions lack format constraints and validation rules. E.g., 'terms' parameter lists allowed values in description ('AUTUMN, WINTER, SPRING, SUMMER') as prose; should be an enum. 'query' string lacks length limits or pattern info. LLMs cannot validate input and may pass invalid values.
No error handling guidance visible. Tool definitions do not describe what errors may occur (e.g., invalid term, empty query, server timeout) or how LLM should recover. Missing pattern:recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 53 | - | v1 |
Pagination not documented for get-courses and search-courses. No mention of limit, offset, page_size, or total count. Large result sets could blow context window; tools should accept pagination parameters and return cursor/count.
Descriptions do not clarify tool selection logic. E.g., get-course says 'Only use this when you genuinely need the deeper detail; otherwise prefer search-courses or get-courses', this guidance should be explicit in get-courses and search-courses descriptions (e.g., 'Use get-courses when you have specific course IDs; use search-courses to discover courses by keyword').
Tool definitions appear inferred from prompt text, not explicitly registered as MCP tools in visible code. No evidence of ServerCapabilities.tools, tool_name metadata, or structured registration. Source file is src/app/api/stream-content/prompt.ts (a Next.js API handler), not an MCP tool registry.