Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds value by detailing what the output contains (units, elective units, GE categories, courses) and the catalogueName integration point, which is beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The primary purpose is front-loaded, followed by usage context and a precise integration hint. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only lookup with one optional parameter and no output schema, the description fully specifies the return content and how to use it with check_prerequisites. An agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single 'exam' parameter, and the schema description already explains the exam name/part and omit behavior. The tool description adds no extra parameter detail beyond what the schema provides, so a baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('look up') and resource ('what AP exam scores earn at UCI') with concrete output components (units, GE categories, courses). It differentiates from sibling check_prerequisites by noting the output feeds that tool, so an agent can distinguish them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives two explicit use cases: incoming students planning a first quarter and checking if an exam satisfies a prerequisite. It also explains how the output integrates with check_prerequisites. It doesn't explicitly state when not to use it, but the use cases are specific enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as read-only, non-destructive, and idempotent, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it reports both satisfied and missing requirements, and it discloses the limitation that enrollment restrictions cannot be automatically verified by the API.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. The primary evaluation behavior is front-loaded, and the additional enrollment-restriction note is concise and informative without being redundant with the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only eligibility-check tool with fully documented parameters and safety annotations, the description covers the core behavior, scope, and a key limitation. There is no output schema, but the description gives enough about what is reported (met/missing requirements and restrictions) to guide an agent, though exact return structure is left unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are fully documented in the schema. The description reinforces the role of 'completed' courses and mentions enrollment restrictions, but it does not add meaningful detail about apScores or the precise input formats beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Evaluate') and resource ('a course's prerequisite tree') and clearly states the output: which requirements are met and which are missing. It also adds a distinct second purpose, enrollment restrictions, making it easy to distinguish from sibling tools like get_course or course_grades.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context that this tool is for checking prerequisite and enrollment eligibility against a student's completed courses. It does not explicitly name alternative tools or state when not to use it, but the intended scenario is obvious and no misleading exclusions are present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, and non-destructive hints. The description adds specific behavioral context by stating it builds a weekly timetable, totals units, and detects meeting-time and final-exam conflicts. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and a clear use-case. No wasted words; every phrase contributes to understanding the tool's purpose and invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although there is no output schema, the description adequately explains expected outputs (timetable, unit total, conflict reports) and context (validation before registration). This covers the essential behavior for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully documents both parameters (term and sectionCodes) with examples and accepted formats, achieving 100% coverage. The description does not add extra parameter-level detail beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 a term and section codes, it builds a timetable, totals units, and reports conflicts. This distinguishes it from sibling tools like search_courses or find_sections by focusing on schedule validation rather than lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: 'Use this to validate a proposed schedule before registration.' It gives clear context but does not explicitly mention alternatives or when not to use it, though the purpose is distinct enough to infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context: data comes from UCI public records, recent quarters may be missing, and results can be grouped by instructor or term. This goes beyond the structured metadata without contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences with no filler: the first states the resource, the second gives concrete use cases, and the third provides a relevant data caveat. Each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, grouping options, source, and recency limitations, which is strong for a read-only lookup tool with fully documented parameters. It does not describe the exact output shape, but since there is no required input and the schema documents all filters, this is a minor gap rather than a critical one.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds only marginal parameter context, such as highlighting the default grouping and connecting professor difficulty to the instructor/course filters. It does not substantially clarify parameters beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as providing historical grade distributions and average GPA for a course, with a default breakdown by instructor. It also distinguishes itself from sibling tools like enrollment_history or instructor_info by focusing on grade outcomes and professor difficulty.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent when to use the tool: to answer 'which professor should I take?' or 'how hard is this class?'. It does not name alternatives or exclusions, but the use-case framing gives clear selection guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not repeat these. It adds useful behavioral context: the data covers final enrollment, capacity, waitlist, and a fill curve for recent terms, plus the note that the fill curve is day-by-day. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero redundancy. The first sentence front-loads the data contents; the second sentence gives usage context with three crisp example questions. Every word earns its place, and the structure is immediately scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by naming the key return elements (final enrollment, capacity, waitlist, fill curve). It also explains the temporal scope ('for recent terms') and the intended use case. For an 8-parameter read-only tool, this is complete enough for an agent to decide whether to call it and interpret basic results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with each parameter (year, quarter, courseId, etc.) already explained. The description adds no parameter-specific detail beyond the general 'for a course', which is sufficient given the schema's thoroughness. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb-resource pair ('Historical enrollment for a course') and lists the exact data returned (final enrollment vs capacity, waitlist size, day-by-day fill curve). It distinguishes itself from siblings like course_grades and find_sections by focusing on enrollment trends and registration risk, making the tool's scope unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly explains when to use it: 'Use this to judge registration risk' and provides concrete example questions ('will I get in?', 'do I need to enroll at 7am?', 'does the waitlist clear?'). It does not name specific alternative tools or state when not to use it, but the context is clear enough that an agent can infer the appropriate scenario.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description goes beyond these by noting it queries the 'live schedule,' requiring at least one narrowing filter, and summarizing the returned section data. There is no contradiction between the description and the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact: three sentences convey what the tool does, what it returns, how it can be filtered, and the required-filter rule. Key information is front-loaded, and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 21 parameters and no output schema, the description handles selection context well by naming primary return fields and the mandatory narrowing constraint. Per-parameter semantics are fully covered by the schema, so this is a solid overall package. Minor gaps remain around pagination and output volume, but the schema's `limit` description partially addresses this.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 21 parameters have schema descriptions, so the baseline is 3. The description names broad filter categories such as department, course number, GE, instructor, days, and time window, but it does not add detail beyond the schema, such as dependencies between avoidDays/avoidStart/avoidEnd or the default limit behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'The main course-finding tool' and states that it queries UCI's live schedule for a term and returns matching sections with meeting times, instructor, location, seats, waitlist, and final exam. This is a clear verb-resource pairing with a specific resource and scope. It does not explicitly contrast itself with sibling search_courses, so it is just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 it—finding course sections in a term—and explicitly states a hard precondition: 'At least one narrowing filter besides the term is required.' It also enumerates the dimensions an agent can filter by. However, it does not name alternative tools or state explicit when-not-to-use conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by specifying the breadth of the returned data (e.g., prerequisite structure, enrollment restrictions, GE credit, repeatability, term offerings), which goes beyond the annotations and helps the agent understand what to expect from the response. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the core purpose ('Full catalogue detail for one course') and then efficiently lists the included data categories. Every clause adds information without redundancy. It is concise yet comprehensive, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-course detail tool, the description enumerates all relevant content areas (description, units, prerequisites, unlockable courses, restrictions, GE credit, repeatability, terms offered). With no output schema, this description gives the agent a clear picture of what the tool returns. Combined with the annotations covering safety, the description is complete for correct invocation and expectation setting.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (the only parameter courseId has a detailed description with examples like 'COMPSCI 161' or 'I&C SCI 46'). The description adds no further parameter guidance, but the schema already fully documents the parameter format. Baseline of 3 is appropriate because the description doesn't need to compensate for any schema gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it provides 'Full catalogue detail for one course' and enumerates the specific data points (description, units, prerequisites, etc.). This clearly distinguishes it from sibling tools like search_courses (which searches across courses) and check_prerequisites (which only checks prerequisites). The verb 'get' and resource 'course' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear usage context: 'Use this before advising someone to take a course.' This tells the agent when to invoke this tool. It doesn't explicitly mention alternatives or when not to use it, but the context is sufficient given the sibling list and the tool's purpose as the comprehensive course detail source.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds content scope (full requirement tree, GE categories, unit minimums) but does not elaborate on behavioral details like response size or the impact of catalogYear. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The core resource ('full requirement tree') is front-loaded, and the practical use case is stated concisely at the end.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only query tool with five well-described parameters and safety covered by annotations, the description adequately conveys purpose and usage. It does not explain output shape, but 'full requirement tree' hints at the structure, and no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for all five parameters, including enum values and defaults. The description adds no parameter-specific meaning beyond what the schema already provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the full requirement tree for majors, minors, specializations, and general undergraduate requirements. It distinguishes itself from siblings like list_programs by emphasizing the complete tree and degree-planning context, though it does not explicitly name an alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use for degree planning — what do I still need?' providing a clear when-to-use. It does not mention alternatives or exclusions, but the use case is specific enough to guide an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower for the description. The description adds useful context beyond annotations: links point to UCI Canvas and may require a UCInetID login, which is important for setting expectations about access.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences each add value: the first defines behavior, the second gives the use case, and the third discloses the login requirement. Information is front-loaded with the core function, and there is no redundant wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only retrieval tool with a fully described schema and safety annotations, the description covers the essential behavioral context, access implication, and motivating use case. It does not discuss alternatives, but that is a minor gap given the simplicity of the operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers all parameters with 100% description coverage, including examples for courseId, year, quarter, and instructor. The description's mention of 'by term and instructor' reinforces the main filter dimensions but does not add new semantic detail beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that this tool links to syllabi from previous offerings, scoped by course, term, and instructor. It also explains the practical purpose—showing workload, grading breakdown, and topics before enrollment—which effectively distinguishes it from other course-related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use the tool: to show a student what a course is actually like before they enroll. It does not mention exclusions or alternatives, but the use case is specific enough to guide an agent without ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context by stating that it returns courses taught and an average GPA aggregated across all courses, which goes beyond the schema and helps the agent understand aggregation behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no filler. The core action and output are front-loaded, and the use case is added in a single closing sentence. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich annotations, complete schema descriptions, and optional parameters, the description provides enough context for an agent to select and call the tool. It does not fully specify behavior when no parameters are supplied, but the schema's optionality and openWorldHint mitigate that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema for parameters like name, ucinetid, and includeGrades, but it does imply the output context in which those parameters are used.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Find') and resource ('UCI instructor'), and enumerates the exact returned data points: title, department, courses taught, and average GPA. This clearly distinguishes it from sibling tools like course_grades, which focus on grades for a course rather than an instructor profile.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit use case: 'Use to evaluate a professor before enrolling.' It does not name alternative tools or state when not to use it, but the context is clear enough for an agent to select it over the listed siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds context about the data source (schedule of classes) and filtering behavior, which is useful. It doesn't describe return format or edge cases, but given the annotations cover the main safety aspects, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states purpose with examples, the second gives usage guidance and filtering. Every word earns its place, and the key information is front-loaded. No fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one optional parameter and no output schema, the description covers purpose, usage context, and filtering. It doesn't mention what happens without a filter (returns all codes) but that is implied. The annotations cover safety, so the description is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the filter parameter is fully documented in the schema. The description only says 'Optionally filter by a substring', which largely repeats the schema's meaning. The description adds minimal extra value beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists UCI department codes used by the schedule of classes, with concrete examples (COMPSCI, I&C SCI, BIO SCI). This is a specific verb+resource and immediately distinguishes it from sibling tools like list_terms or list_programs, which handle different entities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Use when you are unsure of the exact code for a subject', which is a clear usage condition. It also notes optional substring filtering, providing practical guidance. However, it doesn't explicitly mention alternatives or when not to use it, so it's slightly below perfect.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds no additional behavioral details such as pagination or rate limits, but does not contradict the annotations. Given the rich annotations, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with a clear purpose, no redundancy, and the key information (what it lists and why to use it) is front-loaded. Perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with optional parameters and no output schema, the description is nearly sufficient. It states the purpose and ties to a downstream tool, though it could explicitly mention the return format (e.g., array of objects with id and name). This is a minor gap, but the tool is straightforward.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters (kind and filter) described in the schema. The description does not add any extra meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the verb 'List' and the resource 'UCI degree programs', and explicitly mentions its purpose of finding the program id for get_program_requirements. This clearly distinguishes it from sibling tools like list_departments or list_terms.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear use case ('Use to find the program id needed by get_program_requirements') and ties it to a specific sibling. It does not explicitly mention when not to use it, but the purpose is clear enough for the agent to select it appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already convey the read-only, idempotent, non-destructive profile. The description adds meaningful behavioral context beyond those annotations: it returns the current week of instruction, and with a term also returns academic calendar details such as instruction dates, finals week, and holidays.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: the first defines the core output, the second clarifies the optional behavior, and the third gives an explicit usage trigger. There is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple optional-parameter read-only tool, the description is complete: it states the data scope, the optional calendar behavior, the calendar contents, and when to call it. The safety profile is covered by annotations, and the return shape is self-evident from the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully documents the optional 'term' parameter, including a format example and the conditional calendar behavior. The description adds value by specifying what the calendar includes—instruction begins/ends, finals week, holidays—providing useful semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and resource ('UCI terms (quarters) that have schedule-of-classes data'), and adds the distinct secondary behavior of returning the current week and optional academic calendar. It is clearly differentiated from sibling tools like list_departments 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit invocation trigger: 'Call this first when the user says "next quarter" or doesn't name a term.' It provides clear context for when to use the tool, though it does not name alternatives or state 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context by explaining that it combines live schedule data with historical grades and ranks by historical GPA or open seats, which goes beyond the structured hints. It does not describe edge cases or output format, but the key behavioral traits are disclosed without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences and every sentence contributes: the 'find me a class' hook, the data-combination mechanism, the filter and ranking behavior, and a realistic example. The opening tag is slightly redundant with the tool name, but it is short and immediately frames the tool's role. Overall it is tight and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 11 parameters and no output schema, the description supplies enough high-level context about what the tool does and how results are ordered. It does not detail the exact result shape, pagination, or data freshness caveats, but the phrase 'rank candidate courses' plus the example covers the agent's core decision needs. The rich annotations also carry part of the contextual burden.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter already carries its own meaning and examples. The description adds a high-level grouping of filters (GE category, department, level, days, time window, seat availability) and clarifies ranking options (GPA or open seats), but it does not add syntax or format details beyond the schema. This matches the baseline-3 expectation for fully documented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-resource pair: it 'rank[s] candidate courses' by combining live schedule data with historical grade data. It clearly differentiates itself from siblings like search_courses and course_grades by emphasizing the ranking and recommendation behavior, and the 'find me a class' tagline makes its purpose instantly recognizable. The example query reinforces the exact job this tool performs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a concrete ideal use case: "find me an easy GE-2 with open seats that doesn't meet before 10am". This tells an agent when the tool is appropriate for natural-language-style course recommendation. It does not explicitly name sibling tools or state when NOT to use it, so it stops short of full exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds behavioral context by noting that calling with no argument lists majors with a published plan, which is a useful behavior beyond the schema. It doesn't contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: what it is, when to use it, and how to invoke the no-argument behavior. The most important usage guidance is front-loaded. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, idempotent tool with a single optional parameter and no output schema, the description covers the essential usage context. It could mention what the returned plan looks like (e.g., quarters, course names), but the annotations and schema cover the safety and parameter aspects, so the gap is minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the 'program' parameter with examples. The description adds the behavior of omitting the parameter to list all, which is a meaningful addition, but it doesn't add much beyond the schema's examples. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as a catalogue-recommended quarter-by-quarter course sequence for a major, with a specific verb ('sample', 'recommended') and resource ('four-year plan'). It distinguishes itself from siblings like get_program_requirements and recommend_courses by focusing on the published plan. The title reinforces the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use it: to answer 'what should I take first year?' or to sanity-check whether a student is on track. It also gives a clear usage instruction: call with no argument to list majors with a published plan. This is strong guidance for an agent deciding between this and sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral context beyond that: it clarifies the search covers the full catalogue rather than term-specific offerings, and gives example queries. It does not contradict annotations and adds useful scope information, though it omits details about return format or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero filler. It front-loads the primary purpose, then immediately gives usage guidance and the alternative tool. Every sentence earns its place, and the structure is logical and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 10 parameters, the description is complete in explaining the core behavior, usage modes, and the main alternative. It does not describe the return structure, but given the absence of an output schema and the read-only, idempotent nature, this is a minor gap. The description covers the essential context an agent needs to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter is documented. The description adds value by providing concrete usage examples ('machine learning', 'CS 161') and illustrating combined filters ('all GE-2 lower-division courses worth 4 units'), which clarify how to combine parameters beyond their individual definitions. This goes beyond the schema's isolated descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb 'search' and a clear resource 'UCI course catalogue', and explicitly clarifies the scope ('all courses that exist, not term-specific offerings'). It also distinguishes itself from find_sections, making its purpose unambiguous and differentiated from a key sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: it explains two usage modes (free-text query vs. structured filters) and gives a concrete alternative with a condition ('To see which sections actually run... use find_sections instead'). This leaves no ambiguity about when to select this tool over others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.