ScarletPlan

by heetshah15

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct aspect of course planning—eligibility, details, fill stats, professors, requirements, schedules—with clear descriptions that prevent confusion. The only potential overlap between solve_degree_plan and solve_semester_schedule is well-differentiated by their long-term vs. short-term focus.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_course, solve_degree_plan). The verbs are appropriately chosen and uniform across the set, making it easy to predict functionality from the name.
Tool Count5/5
With 13 tools, the number is well-scoped for a university course planning assistant. Each tool serves a clear purpose without redundancy, covering search, details, prerequisites, scheduling, and user profile management.
Completeness5/5
The tool set covers the full student planning workflow: searching courses, checking prerequisites and eligibility, managing schedules, validating plans, and storing preferences. No obvious gaps exist for typical planning tasks, though external actions like enrollment are excluded.
Average 3.9/5 across 13 of 13 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It only mentions storage for repetition avoidance but does not discuss side effects like overwriting, permissions, or data persistence beyond turns. This is insufficient for a tool with no annotations.
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 a single, short sentence with no unnecessary words. It is appropriately sized and front-loaded with the core action and purpose.
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?
While the tool is simple, the description is incomplete given the absence of annotations and output schema. It lacks information about parameter semantics, behavior on overwriting keys, and any return value. A user needs more context to use it correctly.
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?
Schema coverage is 0% and the description does not explain the 'key' or 'value' parameters. It only mentions that 'Value is any JSON' but leaves the key undefined and provides no additional semantic meaning for either parameter.
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 'store' and the resource 'user-profile value', and explains the purpose of avoiding repetition across turns. It distinguishes from the sibling tool 'get_user_profile' which retrieves values.
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 when to use the tool (to store a value so the student does not repeat themselves), but does not explicitly state when not to use it or mention alternatives among siblings. The context is clear but lacks exclusions.
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 full burden. It mentions the output type (AST with course titles) and the use case, but it does not disclose authentication needs, error behavior (e.g., if course not found), or whether it is a read operation. The description 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key information about the tool's output and purpose. It is appropriately sized but could be slightly expanded to include parameter details without losing conciseness.
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?
Given the tool has one parameter (undocumented), no output schema, and no annotations, the description is insufficient. It explains the output's purpose but leaves out critical details about the input format and behavioral context, making it incomplete for an agent to use correctly.
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 only parameter, course_string, has 0% schema description coverage and the tool description does not mention it at all. It provides no format, example, or guidance on how to specify the course. With a single parameter, the description should compensate but does not.
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 an annotated prerequisite tree (AST with course titles) and its purpose: to explain why a course is or isn't available. The verb 'get' and resource 'prerequisite tree' are specific, and it distinguishes from siblings like check_eligibility which likely does a direct eligibility check.
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 explicitly says 'Use to explain WHY a course is or isn't available,' providing clear context for when to use it. It does not state when not to use or explicitly name alternatives, but the purpose is well-aligned with the tool's function.
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 states the tool lists sections and provides format details (times in minutes-from-midnight, Thursday 'H'), which is helpful. However, it does not disclose whether it is read-only, any rate limits, or if data is paginated.
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 with two sentences. The first sentence states purpose and contents, the second adds format clarification. No unnecessary words, though it could be slightly smoother.
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 no output schema, the description should cover return structure. It mentions fields (meeting times, instructors, open status) but not the structure (e.g., list of objects). It is adequate for a basic understanding but incomplete for expecting exact output.
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 mentions 'course' and 'term' but does not explain the format of course_string (e.g., 'CS101') or that term is optional and accepts integer or null. The description adds minimal meaning beyond the schema.
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 lists sections for a course in a term, specifying meeting times, instructors, and open status. The verb 'list' and resource 'sections' are specific, and it distinguishes from siblings like get_course (which likely gets course info) or search_courses (which searches).
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 section details are needed for a course, but it lacks explicit guidance on when to use this tool versus alternatives like get_fill_stats or get_prereq_tree. There is no statement of when not to use or what prerequisites are needed.
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 description carries full burden. It discloses return values including 'unknowns' for unverifiable notes. However, it doesn't state side effects (none implied), required permissions, or behavior when inputs are invalid. Adequate but not comprehensive.
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?
Single sentence of ~20 words, front-loaded with key info. No fluff. Every word serves a purpose.
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?
Covers main purpose and outputs, but no output schema exists to define return structure. Missing details like whether output is a list or dict, or what the 'unsatisfied prereq subtree' looks like. Adequate for the tool's complexity but could be more helpful.
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%, meaning the description provides no additional meaning beyond parameter names. It mentions 'course_strings' and 'completed courses' but doesn't explain format (e.g., comma-separated? list of IDs?). Value is marginal beyond the schema.
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?
Clear verb+resource: 'check eligibility'. Specifies inputs (course_strings, completed) and outputs (eligible, unsatisfied prereq subtree, unknowns). Distinguishes from sibling tools like get_prereq_tree which only returns prereq structure without checking eligibility.
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?
Description implies usage: when you need to check eligibility given completed courses. But no explicit mention of when not to use or alternatives like solve_degree_plan. Could benefit from stating it's for individual course checks rather than plan optimization.
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; description carries full burden. Explains data source (openSections poller), special return status ('no_data'), and meaning of reopen_count. Lacks details on idempotency or side effects.
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?
Description is moderately sized and informative, explaining key fields and caveats. Could be slightly more concise but is well-structured.
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?
No output schema, so description covers return fields adequately. Mentions caveats and no-data case. Could provide more detail on term/year format but sufficient for a tool with few parameters.
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%. Description does not explain the parameters beyond implying index_number is required. No additional meaning or format guidance for term or year.
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 it returns historical fill statistics for a section index, listing specific fields (hours_to_first_fill, pct_time_closed, reopen_count). Distinct from sibling tools like get_sections which provide different data.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies use for fill stats but does not compare to other tools or mention 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?
With no annotations, the description partially discloses behavior: it returns buckets with satisfied/remaining and credit counts. However, it does not explain what a 'bucket' is or any side effects.
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 efficiently convey the tool's purpose, parameter, and usage recommendation with no 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?
For a low-complexity tool with one parameter and no output schema, the description covers the essential points: what it does, what input it takes, what it returns, and how it fits into the workflow. Lacks examples but sufficient.
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 description explains the 'completed' parameter as 'list of course strings the student has finished,' adding meaning beyond the schema. However, it does not specify the exact format of course strings.
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 that the tool provides per-requirement-bucket progress for the CS BS major, and distinguishes its role as a precursor to solve_degree_plan.
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 says 'Call this before solve_degree_plan to show what's left to complete,' providing clear usage context. Does not mention alternatives or when not to use.
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 full weight. It discloses the return behavior (null if unset) but omits other behavioral traits such as idempotency or error handling.
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 front-load the purpose and add examples and return behavior without any wasted 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?
For a simple one-parameter read tool with no output schema, the description adequately covers purpose, parameter semantics, and return value, though it could mention error cases.
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?
With 0% schema coverage, the description compensates by providing examples of valid key values, but does not specify exact allowed keys or format constraints.
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 ('Read a stored user-profile value') and provides concrete examples of valid keys, distinguishing it from the sibling tool set_user_profile.
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 when to use (reading profile values vs. writing), but does not explicitly state when not to use or list alternatives beyond the sibling set_user_profile.
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 must carry the full burden. It reveals that the tool accepts multiple course string formats and instructs to pass caveats. However, it does not mention if the tool is read-only, requires authorization, or how it behaves on errors. The description adds some context but is not comprehensive.
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 three sentences with no wasted words. It front-loads the purpose immediately and provides key input format details succinctly.
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 2 parameters, no output schema, and no annotations, the description covers the main purpose and input format but leaves out the term parameter's role and what the return value looks like. It is 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 the description must compensate. It explains the course_string parameter with three examples ('CS 344', '198:344', '01:198:344'). However, it does not explain the term parameter, which is optional and has a default of null. The description adds value for one but not 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 it retrieves full details for one course, including prereqs, sections, codes, and credits. It distinguishes from sibling tools like search_courses (which would search) and get_sections (which would get sections only).
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 when a user needs comprehensive details for a single course. It says 'Full detail' and provides input format examples. However, it does not explicitly say when not to use it or mention alternatives 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 description carries the burden. It states returns 'compact course rows', implying read-only operation, but lacks details on pagination, rate limits, or side effects. Adequate but not rich.
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 efficiently states core functionality with key parameter examples. Second sentence adds clear usage advice. Every word earns its place.
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?
Despite 5 params, no output schema, no annotations, the description covers the main purpose, key parameters, and usage context. Missing details on 'limit' and return structure, but for a search tool it is reasonably 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 coverage is 0%, but description adds meaning for 'query' (free text), 'subject' (with example '198' for CS), 'level' (explains 300=300-level), and 'term' (mentioned). However, 'limit' parameter is not described, and no format for 'term' is given. Partial compensation.
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 'search' and the resource 'Rutgers course catalog', listing search criteria (free text, subject, level, term). It also distinguishes from sibling 'get_course' by specifying when to use this tool.
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 says 'Use before get_course when the user names a topic not a code', providing clear context for when to use this tool vs an alternative. No explicit when-not scenarios, but the guidance is direct and helpful.
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 carries full burden. It discloses the use of CP-SAT optimization, return of penalty_score, and that caveats are always surfaced. However, it does not detail failure modes, side effects, auth needs, or performance impacts, leaving gaps in 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 a single paragraph of four sentences, front-loaded with the main purpose, then detailing preferences and output, and ending with a usage note. Every sentence adds value with no redundancy or fluff.
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 complexity of an optimization tool with 4 parameters (2 required) and no output schema, the description covers the primary use case and mentions get_sections as a prerequisite. However, it lacks details on error handling, preference interaction, and output format specifics, making it moderately complete for an agent.
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?
Schema description coverage is 0%, so the description adds significant value by explaining k's default, that preferences may include earliest_start, latest_end, days_off, campus_preference, and that course_strings is a list. This compensates for the bare schema, though preferences structure remains loosely defined.
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 function: given course strings and a term, return conflict-free schedules using CP-SAT optimization. It specifies output includes schedules, summary, penalty_score, and caveats, distinguishing it from sibling tools like solve_degree_plan by focusing on semester scheduling.
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 explicitly instructs to use get_sections first to confirm sections exist, providing a clear prerequisite. It implies the tool is for generating conflict-free schedules with preferences, but does not explicitly state when not to use or list alternatives beyond get_sections.
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 description carries full burden. It explains return behavior (plan or infeasibility explanation) and parameter effects, but lacks disclosure on side effects, idempotency, authentication needs, or behavior for past target terms.
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?
Four focused sentences: purpose, parameter explanations, output type, usage guideline. No fluff, front-loaded with intent, every sentence earns its place.
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 parameters, return type, and prerequisite call. Missing details about the structure of the returned plan or infeasibility explanation (no output schema). Also lacks behavioral notes like rate limits or mutability, but overall sufficient given tool complexity.
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?
Schema description coverage is 0%, yet description fully explains all four parameters: completed (list of strings), target_term (dict with year/term mapping), preferences (optional with defaults), pins (optional mapping). This adds significant meaning beyond the bare schema.
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?
Description states 'Plan remaining semesters from now to target_term', clearly indicating the verb (plan) and resource (degree plan). It distinguishes from sibling tools like solve_semester_schedule (single semester) and check_eligibility.
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 instructs to call get_requirements_progress first, providing a clear usage guideline. However, it does not explicitly state when not to use this tool or compare directly 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?
With no annotations, fully describes caching behavior ('cached RateMyProfessors rating'), the `ratings_available` flag meaning, and confidence caveats. Does not mention auth or rate limits, but these are less critical for a read-only lookup.
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?
Three sentences, each adding value: first states core purpose, second clarifies name flexibility and output interpretation, third explains a key flag. No wasted words.
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 output schema, description covers all return fields (ratings, courses, match_confidence, caveats, ratings_available). Completely explains what the agent needs to know for invocation and result interpretation.
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?
Schema coverage is 0%, so descriptions must compensate. Explains name accepts any format and provides examples. The `term` parameter is mentioned indirectly ('this term') but lacks format or allowed values.
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 specifies the verb 'Look up', the resource 'professor by name', and the exact data returned (cached ratings and courses). It clearly differentiates from sibling tools like get_course or search_courses.
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?
Provides explicit instructions on name formats ('Professor Smith', 'J. Smith', SOC format) and how to handle low-confidence matches. Lacks explicit when-not-to-use but sibling tools are clearly distinct in function.
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. Lists output structure (valid, conflicts, caveats) and implies read-only behavior. Does not mention side effects, but acceptable for a validation tool.
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?
Three concise sentences: purpose, usage context, input/output description. Every sentence earns its place with no redundancy.
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 output schema and no annotations, description adequately covers input format and all three return fields. Sufficient for an agent to invoke correctly.
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?
Schema coverage is 0%, but description fully compensates by specifying the exact structure of the 'plan' object: {sections: [index_number, ...], term: int}. Adds critical meaning beyond vague schema.
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 verb 'check whether' and resource 'proposed schedule for time conflicts'. Distinguishes from sibling solve_semester_schedule by specifying it validates after manual editing.
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 says 'Use after the student manually edits a solve_semester_schedule result'. Provides clear context but lacks explicit when-not-to-use or alternatives.
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:

[![scarletplan MCP server](https://glama.ai/mcp/servers/heetshah15/scarletplan/badges/card.svg)](https://glama.ai/mcp/servers/heetshah15/scarletplan)

Score Badge

Copy to your README.md:

[![scarletplan MCP server](https://glama.ai/mcp/servers/heetshah15/scarletplan/badges/score.svg)](https://glama.ai/mcp/servers/heetshah15/scarletplan)

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/heetshah15/scarletplan'

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