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

The annotations already cover the read-only and open-world aspects, so the description need not repeat safety. It adds value by disclosing the breadth of data (groups, lecturers, rooms, curriculum placement, assessment, exam dates), but it does not flag that some fields depend on the include_description parameter triggering an extra request; that nuance lives only in the 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?

The description is a single, compact sentence with a front-loaded purpose phrase and a scannable comma-separated list of content areas. Every word earns its place; no redundant or tangential information appears.

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 a 100% parameter schema, readOnly/openWorld annotations, and a declared output schema, the description does not need to explain return formats or parameter behavior. It provides a complete inventory of the returned data and is sufficient for an agent to decide to call this tool, though it would benefit from naming a sibling alternative for fuller guidance.

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 meaningfully expand on lv, semester, or include_description beyond what the schema states. It implicitly connects to the lv parameter by referring to 'one course' but adds no semantic detail.

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 returning comprehensive details for a single course, enumerating specific fields such as ECTS, groups, lecturers, dates, and curriculum placement. This distinguishes it from siblings like search_courses (search) and get_course_schedule (schedule-only), though it lacks an explicit verb like 'retrieve'.

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 that this tool is for obtaining full course details when you have a specific course identifier, but it never states explicit when-to-use conditions or names alternative tools. The wide scope ('everything') and the listing of fields subtly differentiate it from schedule-only or search tools, but the 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=true and openWorldHint=true, so the description need not repeat that. It adds value by specifying the two output formats (summary and iCal feed), which is behavioral context beyond the schema. However, it does not disclose other behaviors like error handling or pagination, but given the read-only nature, this is acceptable.

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, front-loaded sentence with no unnecessary words. It efficiently communicates the core purpose and output options, earning a perfect score for conciseness.

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 simple nature of the tool, full schema coverage, and annotations covering safety and open-world behavior, the description is nearly complete. It does not mention the optional group and semester parameters, but those are clearly documented in the schema. The description adequately conveys the essential purpose and output options.

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 all parameters are documented in the schema. The description does not add any additional parameter semantics beyond what the schema already provides, so the 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 clearly states the tool retrieves dates, times, and rooms for a course group, and distinguishes between two output formats (summary vs iCal). It is specific about the resource and the two modes, which differentiates it from siblings like get_course (course details) and search_courses (search).

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 usage context by stating what it returns, but it does not explicitly mention when to use this tool versus alternatives or when not to use it. There are no exclusions, but the context is clear enough for an agent to infer its use for schedule lookups.

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 description claims the tool returns the 'complete course list', but the annotations include openWorldHint=true, which signals the result set may not be exhaustive. This is a direct contradiction. Additionally, the default limit of 400 and maximum of 2000 mean the response can be truncated, making 'complete' potentially misleading.

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 short sentences with no filler. The core functionality is front-loaded, and the usage example is placed at the end to reinforce when to use the tool. Every phrase 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 the main use case and scope, and the output schema plus parameter schema provide much of the remaining context. However, the 'complete course list' claim is unreliable given the openWorldHint and limit parameter, so an agent could be misled about exhaustiveness.

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 adds some semantic mapping by tying 'department or degree programme' to program and 'semester Y' to semester, but it does not add meaningful parameter-level detail 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 clearly identifies the resource: a complete course list for a department or degree programme in a semester, grouped by module. It also includes a concrete query template ('what does department/programme X offer in semester Y') that distinguishes it from broad search tools like search_courses and single-course tools like get_course.

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 with the 'Use this for...' phrasing, which clearly tells an agent when to invoke it. It does not name alternatives or state when not to use it, but the use case is specific enough to route most calls 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 provide readOnlyHint and openWorldHint, so the description only needs to add non-annotation-redundant context. It does add that the result excludes courses and is cheap, which sets expectations about content and performance, but does not discuss error handling, semester interpretation, or result size.

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 sentence is front-loaded with the main resource 'Module tree of a programme or department', and the exclusion 'without any courses' is integrated right away. The phrase 'a cheap overview...' adds a little extra but does not feel padded, so the description is short and stays focused.

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 output schema and the annotations already present, the description covers the basic shape of what is returned. It is simple enough that this explanation suffices, though it could mention that program codes also correspond to department names and that the semester parameter is optional but can affect 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?

Input schema description coverage is 100%, and the description only restates that the program can be a programme/department name or VVZ path, which is already present in the schema. It adds no further details about the semester format or the relationship between modules and curriculum.

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 identifies the resource as a module tree and scopes it to a programme or department, and explicitly notes 'without any courses', which differentiates it from the sibling get_program_courses. It lacks an explicit verb like 'retrieves' or 'lists', so the action is not stated as directly as it could be.

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 implies when to use the tool, 'a cheap overview of how a curriculum is structured', and tells you the result contains no courses, suggesting this is the lightweight structure-level option. However, it never names the alternatives or gives an explicit when-not-to-use condition, so the guidance remains mostly inferred.

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 annotations readOnlyHint=true and openWorldHint=true, the agent knows it is safe and that the results may be incomplete. The description adds no behavioral details beyond what is already in the annotations. It does not contradict the annotations, but adds no extra context such as that the person might not be found or that data may vary.

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, compact sentence that efficiently conveys the tool's purpose. It is appropriately sized and front-loaded, 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?

Given the tool's simplicity (one required parameter, schema coverage complete, output schema present, and annotations covering safety), the description is adequate. However, it does not mention what the return value will look like, even though an output schema exists. It also does not mention that the person might not be found or how to handle that, but the openWorldHint may imply data is world-open. Overall, it is minimal but not dangerously incomplete.

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 description covers 100% of parameters, and the schema already provides a helpful example ('36131'). The description adds no additional meaning beyond the schema, but since schema coverage is complete, the baseline is 3. The description does not explain the semantics of the fields returned, but parameter semantics for the id is well-covered by 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 clearly states the verb 'get' and the resource 'one person', specifying that it returns 'Contact details, room and affiliations'. It is concise and unambiguous; however, it does not explicitly differentiate from sibling tools like search_staff, though the distinction is inferable from the name and the singular resource.

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 does not explicitly state when to use this tool versus alternatives. It implies usage by describing the output, but there are no alternative names or conditions. The sibling tool search_staff likely returns a list of people, and this tool gets details for one, but this is not stated.

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 description adds return-field details beyond what annotations convey lacks explicit notes on null behavior, not-found handling, or side effects online. However, the read-only annotation covers the main behavioral risk, and the description adds no detail about 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 a single, compact sentence that avoids redundancy and front-loads the core meaning. No filler or unnecessary 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 lookup tool with a single ID parameter and a well-defined output schema, the description is mostly adequate. However, it does not mention likely usage context or error/edge-case behavior, leaving some contextual gaps.

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 the single 'id' parameter well, and schema coverage is high. The description does not need to restate the parameter, though it also adds no extra semantic guidance such as where the ID comes from.

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 makes clear this is a single-unit retrieval by describing it as 'one institute/department' and listing the returned fields. It does not explicitly use a verb like 'get' or contrast itself with list/search siblings, but the intent is still evident.

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?

No guidance is provided about when to use this tool instead of alternatives like search_units, list_units, or list_departments. The 'from search_units' relationship is only mentioned in the parameter schema, not in the 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 readOnlyHint=true and openWorldHint=true, so the description need not restate safety. It adds useful behavioral context: the result includes the VVZ path needed for course listing, and the set is described as 'all top-level units' plus 'special categories', which clarifies the open-world nature.

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 and adds necessary detail about what is included. 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?

Given the tool's simplicity (one optional parameter, no nested objects, output schema present), the description is nearly complete. It could explicitly mention that the output is a list of department names with paths, but the output schema likely covers that.

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 semester parameter fully, including examples and defaults. The description adds no additional parameter semantics, which is acceptable given the schema's completeness.

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 ('top-level units of the Vorlesungsverzeichnis'), and clarifies what those units are (SPL departments plus special categories) and what each entry includes (the VVZ path needed to list its courses). This distinguishes it from sibling tools like search_units or get_unit.

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 when to use this tool: to get top-level departments and their VVZ paths before listing courses. It does not explicitly name alternatives or exclusions, but the context of siblings and the clear scope provide adequate 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 annotations already declaring readOnlyHint=true and openWorldHint=true, the description does not need to state the operation is safe. It adds context that the tool returns programmes/semesters and allows filtering, which is useful operational context beyond the annotations, but it does not mention pagination, result ordering, or performance characteristics.

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, front-loaded sentence that goes straight from the resource to the filtering options. The parenthetical list of degree types adds a little length but is arguably useful for disambiguating the scope and does not repeat the schema 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?

Given the output schema and full parameter documentation, the description covers the essential semantics without needing to explain return values. It optionally mentions a semester scope but does not mention edge cases like default semester; these are already captured by the parameter descriptions. It leaves some sibling relationships but not structurally 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 description coverage is 100%, so each parameter is already documented. The description adds that the list is filterable by department and by name, which mirrors the schema's query and department fields, but it does not add details beyond the schema for limit, semester, or default 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 identifies the resource (degree programmes and extension curricula) and the scope (offered in a semester) with optional filters, giving an agent a clear sense of the tool's output. It distinguishes the tool from sibling resource types (courses, staff, exams), though it does not explicitly name those alternatives.

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 when to use the tool: when a list of degree programmes or curricula is needed, optionally filtered by department or name. It does not explicitly contrast with siblings like search_courses or get_program_courses, leaving the comparison to the agent, but the semantic focus on programmes gives reasonable context.

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 description adds useful behavioral caveats beyond the annotations: past semesters are archived and future semesters beyond one term are usually empty. This is valuable expectation-setting for a read-only tool and does not contradict the readOnlyHint.

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 short, front-loaded with the essential purpose, and has no filler. Every sentence adds useful information: the first gives the core purpose, the second explains relevant behavioral edge cases.

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 0-parameter list tool with an output schema, the description is nearly complete: it explains the purpose, current-semester semantics, and the caveats around archived/empty semesters. The only minor gap is that it does not specify how the current semester is determined, but that is not needed to call the 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?

The tool has zero parameters and schema coverage is 100%, so there is no parameter documentation burden. The description provides helpful context about semester codes and current/empty states, which more than satisfies the baseline for a no-parameter tool.

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 the tool tells the agent which semester codes to use and which one is current, naming the resource 'semesters' and the two key questions. It is distinct from sibling tools like search_courses or list_departments, though it lacks an explicit verb like 'lists'.

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 usage context: use this to understand semester codes and identify the current term. It also warns about archived past semesters and usually-empty future ones, which helps the agent decide when to query those semesters. It does not explicitly name alternatives, so it misses full when-not 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?

The description mentions that it searches over multiple fields and defaults to the current semester, which is useful. It also notes that passing an empty semester searches all semesters knowledge not in annotations. However, it doesn't detail result ordering or that it's a free-text fuzzy search, but the annotation openWorldHint=true indicates infeasible queries may return empty results.

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 concise, with three well-structured lines. It front-loads the primary purpose and then provides field scope and usage examples. Every sentence delivers value without 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?

The tool is relatively simple with 1 required parameter, and the schema covers all parameters. The description gives enough context for an agent to construct queries and handle the semester filter. However, it doesn't mention what the output contains (though an output schema exists), nor discuss potential latency or rate limits, but that's acceptable given the output schema exists and the operational context is not critical.

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 three parameters are described in the schema with examples (e.g., 'logik', '180013', semester codes). The description adds minimal extra meaning beyond the schema because the schema already covers coverage 100%. The description's mention of semester defaults and the empty string for all semesters is also found in the schema, so the extra value is limited.

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 purpose: free-text search over u:find courses, matching titles, LV numbers, lecturer names, and semester codes. It distinguishes itself from sibling tools by specifying the search scope and fields, and contrasts with structured lookups like get_course.

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 provides specific use cases ('is there a course about X' or 'what does lecturer Y teach'), which helps an agent know when to invoke it. However, it doesn't explicitly state when not to use it or mention alternatives like get_course for exact lookups, but the examples are sufficient for many scenarios.

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 and openWorldHint=true, so the safety profile is covered. The description adds that the tool returns courses rather than exam dates, which is a useful behavioral clarification. However, it doesn't disclose details like pagination, result ordering, or how the open-world hint affects results, so it adds only moderate value beyond 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 wasted words. The core purpose is front-loaded, and the follow-up instruction is placed immediately after, making it easy for an agent to parse and act on.

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 has a rich output schema and full parameter documentation, so the description doesn't need to explain return values. The only minor gap is not explicitly contrasting with search_courses, but the exam-specific focus and the get_course pointer make the tool's role clear enough.

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 all three parameters. The description doesn't add parameter-level detail beyond what the schema provides, but it does clarify the overall return semantics (courses, not dates). Baseline 3 is appropriate since the schema carries the parameter documentation burden.

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 for courses with matching exam records (Prüfungstermine), using a specific verb and resource. It also distinguishes itself from get_course by noting that concrete exam dates require a follow-up call, which helps differentiate it from sibling tools like 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 explicitly tells the agent to call get_course for concrete exam dates, providing a clear next step and implicit alternative. It doesn't explicitly state when to use search_exams versus search_courses, but the exam-specific focus and the pointer to get_course give adequate context.

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 and openWorldHint, lowering the burden on the description. The description adds useful behavioral and data-scope context by noting that results include email and room only where published, which is valuable 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?

The description is a single, efficient sentence that front-loads the operation and follows with the return shape. Every word contributes meaning, with 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?

For a simple search tool with one required parameter, a defaulted limit, rich annotations, and an output schema, the description is complete enough for an agent to select and invoke it correctly. It states what to search by, what results look like, and the relevant scope caveat.

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 query as 'Name or part of a name' and limit as 'Maximum people.' The description does not add additional parameter-level detail, but the schema carries the burden adequately, so the baseline score 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 uses a specific verb (find) and resource (university staff), and clarifies the search is by name. It also lists the returned fields (ids, unit, email, room), making the tool's scope and output clear and distinguishable from search tools for other 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?

The description clearly states the use case: finding staff by name. It does not explicitly name alternatives such as get_staff or explain when to prefer one over the other, so it stops short of full exclusion guidance, but the intended context 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?

The readOnlyHint and openWorldHint annotations already cover the safety profile, so the description only needs to add context beyond them. It adds scope (which unit types and fields are involved), but it does not disclose match semantics, pagination, result limits, or exact-match 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 a single, front-loaded sentence with no filler. Every word earns its place, and the parenthetical is compact yet informative.

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 an output schema, read-only annotations, and fully documented parameters, the description is mostly complete for selection and invocation. The only notable gap is the lack of explicit usage guidance relative to sibling unit tools like list_departments or get_unit.

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 query and limit already documented. The description does not add parameter-level detail, but because the schema carries the full burden, a baseline score 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 clearly states the verb ('Find') and resource ('institutes, departments and faculties'), with a useful parenthetical about returned fields. It is distinct from course, staff, and exam search siblings, but it does not explicitly differentiate itself from list_departments or get_unit.

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?

No guidance is provided on when to use search_units versus alternatives like list_departments or get_unit. The description relies on the tool name and required query parameter to imply a keyword-search use case.

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