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

Annotations already provide readOnly, idempotent, and non-destructive hints. The description adds useful behavioral context beyond those annotations: the check spans the whole catalog rather than one term, accepts a code format like 'CSCI-103', and returns true/false. 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 concise sentences, with the core purpose and scope front-loaded, followed by input format and return type. Every sentence contributes meaningful information 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 simple single-parameter, read-only existence check, the description fully covers scope, input format, and return type. Given the annotations and schema, no essential information is missing.

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 single parameter 'course' is fully described in the input schema with the same example, 'CSCI-103'. The description repeats this information rather than adding new semantic detail, so it provides little value 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 opens with a specific verb and resource: 'Check whether a course code exists anywhere in the USC catalog.' It also clarifies scope by noting it is not limited to a single term, which clearly separates it from term-scoped lookup and search siblings.

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 communicates the intended use case: verifying whether a course code exists across the entire catalog. It does not explicitly name alternatives such as search_courses or get_course, but the boolean existence framing makes the appropriate context clear.

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 non-destructive behavior, so the description does not need to repeat that. It adds valuable context beyond the schema by disclosing that the section filters are applied client-side and by enumerating the returned record fields.

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 focused sentences lead with the core action, then the return contents, then the filter behavior. Every sentence carries distinct information with 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?

With no output schema, the description compensates by enumerating exactly what will be returned, including course metadata and section-level details. Combined with the detailed input schema and safety annotations, an agent has enough information to invoke the tool correctly and interpret the result.

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 83% of parameters with detailed descriptions, so the baseline is 3. The description adds extra meaning by grouping days, startAfter, startBefore, and openOnly as optional section filters and clarifying that they are applied client-side, which helps the agent understand how those parameters behave.

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 ('Get'), a precise resource ('full record for a single USC course in a term'), and the lookup key ('course code'). The 'single' scoping clearly separates it from the sibling search/list tools even though no sibling names are given.

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 intended use is clear: when the agent needs the complete record for one known course in a known term, with optional client-side section filtering. It does not name alternatives or provide explicit when-not-to-use guidance, so it misses the top level.

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 supply readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, so safety behavior needs little repetition. The description adds the single-category scoping but does not disclose return shape, empty results, or error behavior, which are the remaining behavioral gaps given no output schema.

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

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

Two sentences front-load the action and resource, then provide an illustrative example. No filler or repetition of schema metadata.

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 all three required parameters documented and sourced, the description is complete enough for an agent to invoke the tool correctly. Without an output schema, a touch more detail about what 'details' contains would have been useful, but it is not essential for this low-complexity tool.

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 each parameter already explained and sourced (e.g., 'Use list_ge_requirements'). The description's 'HINQ' example mirrors schema content and adds no new semantic meaning 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 names a specific verb ('Get') and a precise resource: the name and details of a single GE category within a requirement for a term. This granularity separates it from the sibling list_ge_requirements, which handles the broader listing, and the example 'HINQ' makes the target concrete.

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 frames the use case: confirm what a GE category prefix means. It does not spell out when not to use it or name alternatives, but the 'single category' wording and sibling set make the boundary reasonably clear.

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, so the safety profile is covered. The description adds useful behavioral context about the nature of the returned content and the prerequisite lookup via list_programs. No contradictions 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 two sentences with no filler. The main purpose and return content are front-loaded, followed by a useful prerequisite hint. Every sentence contributes meaningful information.

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 getter with three well-documented required parameters, the description adequately explains what the tool returns and what is needed to call it. There is no output schema, but the described return content ('details for a single USC program... including program-specific notes') is enough for an agent to decide and invoke the tool 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 input schema has 100% description coverage for all three parameters, so the schema already carries most of the semantic weight. The description only restates that school and program prefixes are required and points to list_programs for discovery, adding little 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 says the tool gets details for a single USC program in a term and calls out program-specific notes such as enrollment or D-clearance instructions. The 'single program' scope distinguishes it from list_programs and other listing tools. The resource and verb 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 clear context: use this for a single program's details rather than for listing programs. It also gives practical guidance by pointing to list_programs for finding the required school prefix. It does not explicitly state when not to use it, but the scope is clear 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 establish this is read-only, idempotent, and non-destructive. The description adds value by saying what the call returns—any tuition/fee items attached to the section—which is useful because there is no output schema. It does not mention empty-result behavior, but that is minor for a simple read.

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 the core purpose in the first sentence and the return value in the second. The example is embedded naturally and there is no filler.

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 one-parameter, read-only tool with no output schema, the description covers what it returns and the exact identifier needed. There are no nested objects, enums, or required alternatives to explain.

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 already documents sectionId as the SIS section id with 100% coverage. The description repeats this and adds a concrete example ('29934'), which is a small helpful addition but not substantial 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 opens with a specific verb and resource: 'Get the fees for a single course section.' It also names the exact lookup key, SIS section id, which separates it from the other get/list tools for terms, schools, programs, and 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 intended use is clear: retrieve fees for one section by sisSectionId. It does not explicitly state when not to use it or point to an alternative, but no sibling tool covers section fees, so this is enough context to route an agent correctly.

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 the read-only, idempotent, open-world, and non-destructive safety profile. The description adds value by clarifying the returned resource is a URL and how it relates to syllabi, but it does not disclose edge cases such as what happens when no index exists for a term or whether the URL is fetched or constructed.

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 just two sentences, front-loads the main operation, and includes only meaningful context. Every sentence earns its place without unnecessary elaboration.

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 one-parameter read-only lookup with annotations covering safety, the description is nearly complete: it states what is returned, what it is used for, and how it relates to a direct alternative. The only minor gap is not explicitly describing behavior when no syllabus index is available.

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 single parameter 'termCode' is already fully documented in the schema with a numeric pattern, an example, and a pointer to list_terms for discovery. The description itself adds no parameter-level detail, so the baseline of 3 applies due to high schema coverage.

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 specific operation: getting the SimpleSyllabus index URL for a term. It also explains the purpose of that URL and distinguishes it from the direct 'syllabus' URL carried by individual sections, so the tool's role is 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 states that the returned index URL is for looking up published syllabi for a term's sections, and notes that individual sections also have a direct 'syllabus' URL. This gives useful context about when this tool is relevant, though it does not explicitly say 'use this when' vs 'use the section URL when'.

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 carry the safety profile (readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false), lowering the bar. The description adds the return-value contract (season, year, status, activation date), which is meaningful behavior context given there is no output schema. 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 waste. The purpose, method, and example are front-loaded in sentence one; the return fields, critical since no output schema exists, are in sentence two. Every clause 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 single-parameter lookup with comprehensive annotations and 100% schema coverage, the description is complete: it states the input format, gives a concrete example, and discloses the return fields in the absence of an output schema. Error-case behavior is not described, but openWorldHint already signals partial/missing data is possible.

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 termCode format, the pattern, and the list_terms discovery path. The description reinforces the example (20263 = Fall 2026) but adds no meaning beyond the schema, 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?

States a specific verb ('Get'), a specific resource ('details for a single academic term'), and the identification mechanism (numeric termCode) with a concrete example (20263 = Fall 2026). The singular 'single' clearly differentiates it from the list_* siblings like 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 implies the usage context: use when you have a termCode and need details for one term. The schema's parameter description explicitly routes code discovery to list_terms ('Use list_terms to discover codes'), providing an articulated alternative for the related scenario. It lacks explicit when-not-to-use exclusions, but for a simple lookup this is adequate.

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 read-only, idempotent, non-destructive, and open-world behavior. The description adds useful behavioral context by stating the result spans all terms and includes each prefix's name. No contradiction with annotations is present.

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 concise sentences with no wasted words. The action and scope are front-loaded, followed by a purpose clause, making the description easy to parse quickly.

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 zero-parameter, read-only enumeration tool with strong annotations, the description is complete. It identifies what is returned (subject prefixes with their names), the scope (all terms), and the intended use case. The absence of an output schema is compensated by the description's clear indication of the return content.

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 tool has zero parameters, and schema description coverage is 100% vacuously. The baseline of 4 applies because there are no parameter details that the description would need to clarify.

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 ('List') and resource ('every USC subject prefix in the catalog'), includes examples ('CSCI, MATH, AHIS'), and specifies scope ('across all terms'). This clearly differentiates it from sibling list tools such as list_terms and list_schools.

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 phrase 'Useful for discovering what subjects exist' provides a clear context for when an agent should invoke this tool. It does not explicitly mention alternatives or exclusions, but for a simple enumeration tool this guidance is sufficient.

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 non-destructive behavior, so the safety profile is covered. The description adds valuable behavioral context by noting that section filters are applied client-side and that results include sections, which helps the agent set expectations about response scope and filtering semantics beyond annotation metadata.

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: two sentences front-load the primary purpose, then give the prerequisite discovery step, an illustrative example, and a summary of optional filters. Every clause earns its place, and there is no redundancy 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 listing tool with a fully documented 7-parameter schema, the description covers the essential context: what it lists, what prerequisites are needed, how to discover them, and what filters exist. A small gap is that it does not describe the shape or size of the returned course/section data, which would have been useful given there is no output schema, but this is a minor omission for a list 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?

Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining how geRequirementPrefix and geCategoryPrefix relate to each other and to list_ge_requirements, with a concrete example ('ACORELIT', 'HINQ'). This cross-tool parameter knowledge is genuinely useful and not present in the schema itself.

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 a specific verb-resource combination: 'List all courses in a term that satisfy a General Education (GE) category, with their sections.' It clearly distinguishes this tool from list_ge_requirements by noting that the GE prefixes are discovered through that sibling, and the course-listing intent is 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 gives concrete when-to-use context: it is for listing GE-satisfying courses, and it tells the agent that the required prefixes must be obtained via list_ge_requirements. It provides a concrete mapping example, but it does not explicitly state when an alternative like list_courses_by_program or search_courses would be preferred, so it stops just short of full routing 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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds genuine value beyond that by disclosing return shape ('Returns courses with their sections') and, importantly, that the optional filters are 'applied client-side' — a real behavioral trait with implications for data volume and server load. It does not contradict the annotations, but it stops short of explaining pagination or volume implications.

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: core function, prerequisite+example, and return value+filters. The main purpose is front-loaded in the first sentence, and there is zero filler or repetition of schema boilerplate.

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 list tool with a fully documented 7-parameter schema and safety-bearing annotations, the definition covers purpose, prerequisites, and return shape adequately. The only gap is the absence of an output schema combined with a terse return-value description — an agent composing multi-step workflows (e.g., piping sections into get_section_fees) would benefit from more detail on the returned course/section shape.

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%, and the schema entries are rich: days has enum values with matching semantics, termCode has a pattern plus the 20263 example, and startAfter/startBefore have HH:MM format constraints. The description adds only the 'applied client-side' note for filters and re-states the ENGV/CSCI example already present in the schema, so it contributes marginally beyond the baseline.

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 a specific verb and resource: 'List all courses offered by a USC program (department) in a term.' It states the scope precisely and gives a concrete example (ENGV/CSCI), which makes the tool's role unmistakable. This distinguishes it from siblings like search_courses (keyword search vs. full listing) and list_courses_by_ge (GE category vs. program dimension).

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 clear context by naming the prerequisite discovery path: 'Requires the school prefix and program prefix, which can be discovered via list_programs.' This tells an agent how to prepare before calling. However, it does not explicitly exclude alternatives such as search_courses or list_courses_by_ge, so the when-not-to-use guidance is left to inference.

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 useful behavioral detail about how results are grouped and structured, including an example of requirement/category prefixes. 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 compact and front-loaded with the core action, then efficiently explains the return structure and the downstream use of prefixes. Every sentence contributes non-redundant, decision-relevant information.

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 only one parameter and full schema coverage, the description explains the return shape well: requirement eras, prefixes, category prefixes, and an example. Since there is no output schema, this is sufficient for an agent to know what to expect and how to use the result with list_courses_by_ge.

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 only parameter, termCode, is fully documented in the schema with format, example, and a pointer to list_terms. The description adds little beyond restating that the tool works for a term, so the schema carries the weight and 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?

Clearly states it lists USC General Education (GE) requirements for a term, naming the specific verb, resource, and scope. It distinguishes itself from course-listing siblings by describing the returned GE structure, eras, and category prefixes, making its purpose 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?

Provides clear context by indicating the tool takes a term code and returns GE structure grouped by era, plus an explicit pointer to use the returned prefixes with list_courses_by_ge. It does not explicitly rule out alternatives like get_ge_category_details, so the guidance is strong but not fully exhaustive.

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, and destructiveHint=false, so the safety profile is covered. The description adds the term-scoping constraint and the shape of the returned data, which is useful but does not go into pagination or size-related behavior. This is adequate given 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, no filler. The action and scope are front-loaded, the returned fields are listed compactly, and the cross-reference to list_courses_by_program is integrated naturally. 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, one-parameter listing tool, the description fully covers what it returns, how it is scoped, and why an agent would call it. The schema covers the parameter, and the description covers the output fields despite the lack of an output schema. Nothing essential is missing.

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%: termCode is fully described with an example ('20263') and a pointer to list_terms. The description adds only the high-level notion that programs are listed 'in a term,' which does not materially extend the schema. 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 opens with a specific verb and resource: 'List all USC programs (departments/majors) in a term.' It also states the returned fields (prefix, name, school prefix(es)), and distinguishes the tool's role by naming the sibling list_courses_by_program. An agent can tell exactly what this tool does without opening the schema.

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 explicit guidance: 'Use this to find the school+program pair needed for list_courses_by_program,' including a concrete example. It does not explicitly state when not to use alternatives like get_program or list_schools, but the intended workflow is clear.

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 disclose readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false; the description does not contradict these. It adds context about the term filter and the returned fields (prefix + programs), but does not disclose additional operational behaviors such as auth, pagination, or performance. This is useful context but not rich behavioral disclosure.

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 focused sentences. The first sentence carries the essential definition; the second adds mild navigation context. Nothing is redundant, though the second sentence is less information-dense than it could be.

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 one required parameter documented in the schema, robust annotations, and a description that names the core output fields, the tool is callable without further research. It lacks an output schema and does not mention empty-result behavior, but for a simple single-parameter list operation this is adequate.

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 covers the single termCode parameter 100% with format, an example, and a pointer to list_terms for discovering valid values. The tool description adds nothing about termCode beyond the phrase 'in a term.' Since schema description coverage is high, 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 opens with a specific verb+resource: 'List all USC schools/colleges offering classes in a term' and explains the output components: prefix mapping and contained programs. This clearly distinguishes it from sibling tools like list_programs and list_course_prefixes because the unit of the result is the school/college, not the program or prefix alone.

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?

Only generic guidance appears: 'Useful for navigating the catalog structure.' It implies a catalog-navigation use case but does not state when to choose this over list_programs or list_course_prefixes, nor give exclusion criteria. The parameter schema's pointer to list_terms is embedded in the schema, not the tool description.

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/openWorld/idempotent and non-destructive. The description adds the returned field set (term, session code, description, last drop date, RNR session id), which is useful since there is no output schema. 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 action and object are front-loaded, and the second sentence earns its place by connecting the tool to section codes.

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 parameters, a clear output field list, and annotations covering the safety profile, the description is sufficient for an agent to call it correctly. The field list compensates for the lack of an output schema.

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?

There are zero parameters and schema description coverage is 100%, so the description does not need to document parameters. It appropriately focuses on output content rather than inputs.

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 ('List') and resource ('USC enrollment sessions'), enumerates the fields returned, and gives examples of session types. The distinction from sibling list_terms is apparent: this is about sessions, not 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?

Provides a concrete use case ('understanding session codes shown on sections') but does not explicitly state when to prefer it over alternatives like list_terms. Clear context, no exclusions.

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 signal readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by disclosing the output contents (season, year, term code, status) and providing a concrete termCode example. It does not contradict 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 tightly written sentences: the first states purpose and output fields, the second gives a concrete usage example. Every sentence earns its place and there is no redundant filler.

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, parameterless listing tool with annotations covering safety and idempotency, the description is complete. It explains the returned fields, gives an example of termCode semantics, and leaves no obvious gap an agent would need to call the tool 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 tool has zero parameters, so the schema contributes little. The description compensates by explaining what terms contain and how termCode is used, which gives an agent the semantic context needed to interpret results.

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'), names the exact resource ('USC academic terms available in the course catalog'), and specifies the returned fields (season, year, term code, status). It clearly distinguishes itself from siblings like get_term by describing a collection-level listing operation.

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 explicit context: 'Use this to find the termCode for a given semester (e.g. 20263 = Fall 2026).' This tells an agent when invoking this tool is appropriate. It does not explicitly contrast it with get_term or other alternatives, but the use case is clear enough for a parameterless enumeration tool.

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 behavior, but the description adds meaningful behavioral detail: 'optional section filters ... applied client-side' and what the response contains (courses with sections, schedule, instructor, seat availability). This goes beyond the structured annotations and helps the agent anticipate client-side filtering 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?

Three sentences, all high-signal: purpose, matching criteria, return content, and filter behavior. No filler or repetition of schema details. The structure is front-loaded with the primary action and scopes the tool effectively.

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 no output schema, the description adequately explains what is returned and highlights the client-side filtering behavior. It does not mention result ordering, pagination, or limits, which could matter for a search tool, but the description covers all core functionality and parameter semantics sufficiently for an agent to select and call it.

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 high (83%), so baseline is 3. The description adds value by explaining searchTerm semantics ('Matches course codes, titles, and descriptions') with concrete examples, which is absent from the schema. Other parameters are already documented in the schema, so the description does not need to repeat them.

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'), a concrete resource ('USC course catalog'), and the matching scope ('course codes, titles, and descriptions'). It clearly differentiates from siblings like get_course (single course) and list_courses_by_program (program-based listing) by emphasizing keyword search and returning sections with schedule/instructor/availability.

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 clear context for when to use the tool: when searching the catalog by arbitrary keyword. It includes examples and mentions the optional filters. However, it does not explicitly name alternatives or state when NOT to use it, such as when listing all courses by program or fetching a specific course.

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