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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well: it discloses exact-match lookup semantics, that results include instructor data, and it enumerates the complete return payload (课程名、星期、节次时间、地点、学分、教师姓名、职称、院系、邮箱). The only unstated behavior is the not-found case, which is a minor gap.

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 packed paragraphs: the first states the purpose, the second covers parameter format and return fields. There is no filler, no restating of schema facts, and the core purpose is front-loaded in the first clause.

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 low-complexity tool (one required parameter, no output schema, no annotations), the description is complete: it documents the input format, the exact-match semantics, and the full return payload — necessary because no output schema exists to carry that information. An agent has everything required 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?

Schema description coverage is 0%, so the description must compensate — and it does, defining course_id semantically as a course number and giving concrete format examples (CS101、AI201). This meaningfully exceeds the schema, which only declares 'type: string' and the parameter name.

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 (课程), and exact-match scope (精确, 某一门). The '精确' qualifier and the by-course-number key distinguish this from sibling tools like search_courses and list_courses_by_weekday without needing to inspect their schemas.

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 conveys a clear usage context: invoke this when you hold an exact course_id, reinforced by the format examples ('course_id 形如 CS101、AI201'). However, it does not explicitly name alternatives or state when not to use this tool (e.g., fuzzy name search belongs to search_courses), 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?

With no annotations, the description carries the behavioral burden and does disclose that this is a lookup operation and exactly what is returned, including the current-semester course list. It omits edge cases like not-found or duplicate-name behavior, but these are minor for a simple read tool.

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 front-load the lookup method and then state the returned data. No filler or repetition of schema data.

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 query tool with no output schema, the description covers both input semantics and return values. It could add handling for ambiguous names or missing teachers, but nothing essential is absent.

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 0% and the parameter is merely named 'name'. The description compensates fully by specifying that it accepts either a teacher name ('李老师') or employee ID ('T002') and gives concrete examples.

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 the exact action (查询) and resource (教师信息), explicitly lists accepted lookup keys (name or employee ID), and enumerates the returned fields. This makes it clearly distinct from course- and assignment-focused 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 intended use is inferred: query teacher info by name or ID. However, there is no explicit comparison with sibling tools such as get_course or search_courses, and no when-not-to-use 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?

With no annotations provided, the description carries the burden and does well: it discloses the output shape, sorting order by deadline, handling of missing data with a prompt message, and the all-courses fallback behavior. It does not discuss edge cases like pagination or authentication, but for a simple read tool the disclosure is strong.

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 cover the core behavior, the optional parameter semantics, output fields, sorting, and empty-result behavior. There is no redundant or filler content.

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 tool is simple with one optional parameter, and the description covers input semantics, output contents, ordering, and the no-result case. Since an output schema exists, return value details do not need further elaboration.

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 0%, so the description must compensate. It fully explains the only parameter: course_id is optional, has a format example (CS101), and omitting it returns all courses' assignments. This is more than 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 states a specific verb and resource: querying course assignment lists with deadlines. It distinguishes itself from sibling course-related tools by clearly targeting assignments, and it explains the optional course_id behavior upfront.

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 clearly explains when to pass course_id and what happens when it is omitted, which is clear usage context. It does not explicitly name alternative tools or exclusions, but the naming and purpose make the intended use unambiguous.

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?

With no annotations, the description carries the full burden and does it well: it discloses accepted weekday input forms (周一/星期一/Mon/1), returns sorted by class time, specifies the exact returned fields (course number, name, teacher, period time, location, credits), and states the empty-day behavior with a prompt message. This is substantial behavioral context beyond the raw 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 compact sentences with zero filler: the purpose is front-loaded in a parenthetical, and the second sentence packs parameter flexibility, ordering, return fields, and the empty case. 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 simple one-parameter tool with an output schema, the description is nearly complete: it covers purpose, accepted input formats, output contents, ordering, and the empty result case. The only gaps are lack of sibling differentiation and unspecified behavior for invalid/unsupported weekday strings, both minor for a query tool of this simplicity.

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 0%, so the description must compensate, and it does: it explains that weekday accepts common representations such as 周一, 星期一, Mon, and 1, giving an agent concrete calling guidance the schema alone cannot. It loses a point for the open-ended '等常见写法' and no statement of what happens with unsupported input.

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 and resource: 查询星期几有哪些课 (query which courses fall on a given weekday), clarifying it is the schedule-by-day tool. This is clearly distinct from siblings like get_course or get_teacher, though it doesn't explicitly name or contrast them, so it stops 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?

Usage is implied: when an agent needs a given day's timetable, this tool fits. However, there is no explicit guidance about when to prefer it over search_courses or list_assignments, and no exclusions or routing among the four 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the searchable fields, fuzzy matching, returned fields (number, name, teacher, time, location, credits), and the no-match fallback. It does not explicitly state that the operation is read-only, but the word 'search' and the list-return behavior strongly imply 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?

The description is compact and front-loaded with the core purpose, followed by illustrative examples and a summary of the return value. Every sentence contributes useful information, 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 one-parameter search tool, the description is largely complete: it covers the input semantics, expected output fields, and the no-match case. An output schema exists, so return-value details need not be repeated. It only omits minor constraints like exact matching rules or edge-case behavior, which is acceptable given the low complexity.

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 provides only a required 'keyword' string with no description (0% coverage). The description fully compensates by explaining that the keyword can be a course name, course number, or teacher name and supports fuzzy matching. This gives the agent precise semantic understanding of the single parameter.

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 searches courses by course name, course number, or teacher name with fuzzy matching. The examples ('张' finding all courses by a teacher, 'python' finding Python programming) make the behavior concrete and distinguish it from sibling tools like get_course or list_courses_by_weekday.

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 strong context for when to use this tool: when the caller has a partial keyword for a course name, code, or teacher. It does not explicitly name alternatives or say when not to use it, but the sibling tool names and examples make the intended usage clear enough.

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