penn-course-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct purpose: searching, retrieving details, listing sections, getting ratings/reviews, finding by attribute/requirement, checking conflicts, building schedules, comparing, recommending, and managing saved schedules. No overlapping functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case (e.g., search_courses, get_course_details, build_schedule). The verbs vary (search, get, list, find, check, build, compare, recommend, save, delete) but are descriptive and predictable.
Tool Count5/5
15 tools cover the full lifecycle of course exploration and schedule planning without being excessive. Each tool serves a clear purpose in the domain, and the count is appropriate for a comprehensive course management MCP.
Completeness5/5
The tool surface covers all major operations: course search, details, ratings, reviews, attribute/requirement filtering, schedule building, conflict checking, comparison, recommendations, and persistent schedule management. No obvious gaps for the stated purpose.
Average 3.8/5 across 15 of 15 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It lists return content but omits details like read-only nature, required permissions, potential latency, or side effects. The description adds minimal behavioral context beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise and front-loads the action and resource. However, it lists many items in a dense clause, which could be slightly more readable if split into two sentences. Overall, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description adequately covers the return content. However, it lacks usage guidelines and parameter details, and does not explain when to prefer this over siblings. For a tool with moderate complexity, it meets the minimum but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% schema description coverage. The description does not explain the purpose, format, or constraints of course_code or semester (e.g., semester format, default behavior), leaving the agent without guidance for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get full details for a course' and enumerates specific components (description, prerequisites, attributes, etc.), distinguishing it from sibling tools that focus on subsets like ratings or sections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_course_sections or get_course_ratings. The description does not mention trade-offs or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses substring-matching behavior, which is the core algorithmic detail. However, no annotations exist, and the description does not explicitly state that the tool is read-only or safe, nor mention any side effects or rate limits. The matching behavior is useful but safety is assumed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. First sentence states the main purpose; second adds key detail about substring matching. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters and no annotations, the description adequately covers the main query but omits details on output (though output schema exists) and parameter semantics for limit/semester. Usage context is missing. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains the 'requirement' parameter (pre-NGSS code/name) and substring matching. But 'limit' and 'semester' parameters are not described, leaving their purpose unclear. Partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool finds courses fulfilling a requirement using pre-NGSS code or name, and specifies substring matching. While it doesn't explicitly distinguish from siblings like 'find_courses_by_attribute' or 'search_courses', the specific mention of requirements differentiates it adequately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention scenarios or limitations (e.g., for general course search, use 'search_courses'). The description is purely operational.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral details like validation of course codes, effects of the semester parameter, or how missing courses are handled. With no annotations, it carries full burden but falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy, but omitting the semester parameter reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks documentation for the optional semester parameter and potential edge cases, making it incomplete for a 2-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the course_codes parameter with an example but ignores the semester parameter entirely. With 0% schema coverage, it should document both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares courses on specific attributes (ratings, difficulty, workload, credits, prerequisites) and accepts multiple course codes, distinguishing it from siblings like get_course_details or get_course_ratings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing multiple courses, providing clear context but no explicit exclusions or reference to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the data is public and always available, and lists the four included fields. However, it does not describe error behavior, response structure, or any limitations. With no annotations provided, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that efficiently communicate the purpose and included data. No extraneous information is present, and the most important fact ('always available') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and two parameters, the description covers the basic purpose and output fields but lacks parameter explanations and usage guidance relative to many sibling tools. It is adequate but incomplete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the input parameters (course_code and semester). With schema description coverage at 0%, the description fails to add any meaning beyond the schema, leaving the agent uninformed about required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns public aggregate ratings for a course and lists the specific fields included. It emphasizes that it's always available, distinguishing it from tools that might require authentication or have limited availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for obtaining course ratings but does not explicitly state when to use this tool over siblings like get_course_details or get_course_reviews. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It discloses that the tool produces credits, grid, conflicts, and warnings, but does not discuss error handling, validation, or whether it is read-only. Fails to fully characterize behavior beyond outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key purpose and outputs. However, it could be slightly more structured (e.g., separating inputs from outputs) without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and a relatively simple input schema (2 params, 1 required), the description provides enough context for basic usage but lacks guidance on the 'semester' parameter and potential edge cases, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only partially explains parameters: it mentions 'section ids' for the 'sections' parameter but completely omits the 'semester' parameter, leaving its purpose unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assembles a weekly schedule from section IDs, listing key outputs (credits, grid, conflicts, warnings). It distinguishes from siblings like check_schedule_conflicts (focused on conflicts alone) and list_schedules (listing saved schedules).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have section IDs and want a full schedule, but it does not explicitly state when to use it versus alternatives like check_schedule_conflicts, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the sorting behavior and whether higher/lower values are better, but does not mention whether the tool is read-only, destructive, or requires authentication. This is adequate for a search/rank tool but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, efficiently stating the purpose and then detailing the sort_by options. It is front-loaded with the main action, and every sentence adds value. A small improvement could be to structure the parameter explanation more clearly, but it remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values are documented elsewhere) and 4 parameters, the description covers the core purpose and the most important parameter (sort_by). However, it lacks guidance on when to use this tool vs siblings and does not address default behavior for limit or semester. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the sort_by parameter (one of four), describing its possible values and their ordering. The parameters query, limit, and semester are not explained, leaving a significant gap for the agent to understand their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches and ranks courses by a quality metric, which distinguishes it from sibling tools like search_courses that likely only search without ranking. The verb 'recommend' implies ranking, and the sort_by list makes the ranking criteria explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the sort_by values and their ordering, which provides some usage guidance. However, it does not explicitly state when to use this tool versus alternatives like search_courses or find_courses_by_attribute, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions formatted output and two filters, but lacks details on read-only nature, error handling (e.g., invalid course_code), pagination, or rate limits. It is minimally adequate beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a bullet-style parameter explanation. It is front-loaded with the main purpose and has no redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. The description covers the main purpose and two parameters clearly, but misses documenting the semester parameter. Overall, it is nearly complete for the tool's complexity, with only one clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains open_only and activity parameters clearly, but omits the semester parameter entirely. The course_code parameter is implied but not explicitly described. This covers only half the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'a course's sections with formatted meeting times and instructors', which is specific and distinct from sibling tools like search_courses (which searches across courses) or get_course_details (which provides details of a single course).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It simply describes what the tool does without contextualizing its place among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It describes two matching modes and prefilter behavior, but omits details on authentication, rate limits, or the return format beyond the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—three lines of text with no fluff. It front-loads the purpose and provides essential details for key parameters in a structured format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and 0% schema coverage, the description only fully explains 2 (match, prefilter_query). 'attribute' is exemplified but not completely described; 'limit' and 'semester' are omitted. The output schema exists, so return values are covered, but the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning for 'match' and 'prefilter_query', explaining their exact behaviors. 'attribute' is exemplified but not formally defined; 'limit' and 'semester' are not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds courses by a given attribute with examples like 'EUMS' or 'MFR'. It distinguishes from siblings like search_courses (likely by keyword) and find_courses_by_requirement, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use match='code' vs match='description' and suggests using prefilter_query for faster results. However, it does not provide guidance on when not to use this tool or how it compares to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses conditional behavior with authenticated session cookie and graceful fallback. No annotation provided, so description carries the full burden; it addresses key behavioral traits well, though does not mention rate limits or detailed return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, clear sentences; no wasted words. Purpose is front-loaded, followed by important conditional behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, conditional behavior, and error guarantee. Output schema exists, so return details are not needed. Slightly incomplete on what 'breakdowns' entail (e.g., distributions), but overall sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'course_code' has no schema description (0% coverage) and the description merely says 'for a course' without specifying format or examples, adding little value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States it gets detailed Penn Course Review breakdowns for a course, clarifying the specific resource. However, does not explicitly differentiate from similar sibling like get_course_ratings, so slightly less than perfect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly describes when to use based on authentication status, including fallback behavior and guarantee of no errors. Could improve by noting alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the return format ('clashing meetings in human-readable form') and implies a read-only check. Could disclose whether any state changes occur, but for a check tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the action, the second describes the output. Front-loaded with the key verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (not shown but known), the description adequately covers what it checks and returns. It could mention it does not modify data, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description provides an example for the 'sections' parameter but does not describe the 'semester' parameter, its format, or purpose. Partial compensation for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('section ids for time conflicts'), and clearly differentiates from sibling tools like 'build_schedule' or 'list_course_sections'. It also states the return format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for conflict checking but does not explicitly state when to use this tool versus alternatives like 'build_schedule'. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description takes on the full burden and does well by stating the authentication requirement and the permanent nature of the deletion. It does not mention rate limits or other behaviors, but for a simple delete operation, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. The first sentence clearly states the action and requirements; the second provides critical usage guidance. Perfectly sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the essential context: authentication, permanence, and the prerequisite step. It is complete for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one integer parameter (schedule_id) with 0% description coverage. The description adds value by explaining that the id is obtained via list_schedules, but it does not provide additional details about the range or format of the id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (a saved Penn Course Plan schedule), along with the condition (by id, requires auth). It effectively distinguishes from siblings by explicitly mentioning using ``list_schedules`` to find the id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use ``list_schedules`` to find the id before deleting, and warns that the deletion is permanent. This gives clear context for when to use the tool and what to expect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that the tool returns 'lightweight course summaries including aggregate ratings' and that semester defaults to current term. This is sufficient for a search tool, though it could mention that searches are read-only and any rate limits or caching behavior are omitted. Overall, it provides adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no filler. The first sentence captures the core purpose with examples, the second adds return type and default behavior. Every sentence adds value, and it is well-structured for quick reading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which likely details the return structure), the description is largely complete for a search tool. It specifies the search scope, return content, and default semester. However, it could mention that results are a list or that it supports partial matches to fully set expectations. The sibling tools provide context, but the description stands alone well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'query' (code or keyword) and 'semester' (defaults to current term), but does not explain the 'limit' parameter. This leaves one parameter undocumented, limiting full understanding. The description partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the course catalog by code or keyword, with concrete examples (CIS-1200, ethics). It also specifies that it returns lightweight summaries with ratings. This differentiates it from sibling tools that retrieve full details (get_course_details) or specific data (get_course_ratings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for initial broad searches of the catalog by code or keyword. It implies alternatives (e.g., get_course_details for full info) but does not explicitly state when not to use it or name alternative tools. It does mention the default semester behavior, which is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses that the tool writes to the live Penn account and requires authentication. It explains overwrite behavior and the effect of saving, providing necessary safety information for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loading the purpose and key details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a save tool with 4 parameters and no annotations, the coverage is solid: main behavior, authentication, and overwrite logic are explained. The omission of the 'semester' parameter is a minor gap, but an output schema exists to cover return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage. The description adds meaning for 'name' (schedule name), 'sections' (full section IDs), and 'schedule_id' (for overwriting), but fails to explain the 'semester' parameter. This partial compensation yields a mid-range score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves a schedule to a Penn Course Plan account so it appears on the website. It specifies the verb 'save' and the resource 'schedule to account', distinguishing it from sibling tools like search_courses or delete_schedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool is for creating a new schedule by name and sections, or overwriting an existing schedule via schedule_id. It also notes the requirement for a session cookie. However, it does not explicitly mention when not to use this tool or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses auth requirement and return fields. Adequately indicates it is a read-only operation without destructive effects, though not explicitly stating it is safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded purpose, followed by return value and usefulness. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of output schema, the description fully covers what an agent needs: action, auth requirement, return fields, and practical follow-ups. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters (coverage 100%), so the description need not explain parameters. Baseline 4 is appropriate; no additional param semantics needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List the saved schedules' and specifies the returned fields (id, name, semester, section ids). Distinguishes from sibling tools like save_schedule and delete_schedule by mentioning its use for finding a schedule_id to update or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly requires authentication. Contextually guides usage by noting it returns schedule IDs for subsequent update/delete operations. Does not explicitly state when not to use, but sibling names imply clear boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully handles behavioral transparency by stating what is returned (active semester, review-auth status). It is a read-only tool with no side effects, and the description adequately covers its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no extraneous words, and front-loads the key result. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, the description sufficiently explains the return values and provides usage context. It is complete for a simple informational tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description does not need to add meaning to the input schema. Schema description coverage is 100% (no parameters), making this dimension trivially satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it returns the active semester and whether detailed reviews are enabled, with a concrete example of the term code format. This clearly identifies the tool's purpose and distinguishes it from sibling tools that focus on courses and schedules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using it as a first call to learn the current term code and review-auth status, providing clear context. However, it does not explicitly mention when not to use it or list alternatives, though no alternatives exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![penn-course-mcp MCP server](https://glama.ai/mcp/servers/grantdehoog/penn-course-mcp/badges/card.svg)](https://glama.ai/mcp/servers/grantdehoog/penn-course-mcp)

Score Badge

Copy to your README.md:

[![penn-course-mcp MCP server](https://glama.ai/mcp/servers/grantdehoog/penn-course-mcp/badges/score.svg)](https://glama.ai/mcp/servers/grantdehoog/penn-course-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/grantdehoog/penn-course-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server