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

With annotations already indicating a non-read-only, non-idempotent operation, the description adds real-world side-effect context ('real student account') and discloses the postcondition ('verify it with a fresh enrolled-course read'). It also surfaces the important non-behavior that conflict checks are not implicit. More depth about failure states or permission requirements would improve it, but this is still 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?

Two short, information-dense sentences. The first states the action and verification, and the second adds the conflict-check caveat. No filler or repetition of schema details.

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 booking tool, the description covers the core operation, the verification step, and the conflict-checking caveat. It does not explain the return shape or error conditions, but there is no output schema to mirror, and the overall complexity is low.

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 gives only courseId with minLength; the description adds that it is a 'learning-unit course ID', which is helpful, but it does not specify where the ID comes from or that it should be a bookable course. With 0% schema description coverage, more explicit parametric guidance would be beneficial, yet the single param's role is largely inferable from the tool name and description.

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

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

The description states a specific verb-resource pair: book a learning-unit course on the real student account. It also names the follow-up verification action and implicitly separates this tool from siblings like unbook_course, check_course_conflicts, and join_waitlist.

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 warns that it does not check conflicts and directly instructs the agent to call check_course_conflicts first when schedule compatibility matters. This provides clear when-to-use versus when-to-defer-to-another-tool 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 annotations already communicate read-only, open-world, idempotent, and non-destructive behavior. The description adds useful interpretation of an empty upstream array as meaning "no conflict" and removes ambiguity by explicitly stating the tool does not book or modify anything. 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?

Three short sentences with no filler. The core purpose and scope are first, followed by a useful return-value interpretation, then a caution against an assuming a side effect. 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?

Given that the tool has only two parameters, strong annotations, and no output schema, the description is nearly complete: it covers the action, the input intent, the no-conflict return meaning, and the non-modifying guarantee. It stops short of describing the structure or detail of a non-empty conflict report, but the empty-array result is still covered and the tool is fully append-callable.

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 description gives context for courseIds: they are a proposed set of learning-unit course IDs checked against each other and known appointments. It does not add much beyond that, and it leaves includeAppointmentsForCourseIds entirely to the schema. With only about 50% schema description coverage, the description only partially compensates.

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 exactly what the tool does: evaluate learning-unit course IDs against one another and known appointments. The verb is specific, and the line 'does not book or modify anything' separates it from the booking-related sibling tools. It is clearly not a tautology.

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 a proposed course selection needs to be checked for conflicts or uncovered that are non-mutating. It does not explicitly name an alternative or say when-not-to use this tool, but its behavioral distinction from booking/modifying tools is clear enough that an agent can choose it appropriately.

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

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

Annotations already establish a read-only, non-destructive, idempotent profile, so the description's job is to add behavior beyond that. It does: the 'tolerates an unavailable study-plan or catalog section and reports partial results in warnings' disclosure is genuinely valuable, since an agent would otherwise misinterpret missing data as a failure. It stops short of describing the warnings format or empty-result 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?

Five dense sentences, front-loaded with the trigger condition and then progressing logically through return payload, failure behavior, parametrization, and follow-up workflow. Every sentence earns its place and there's no filler; it's simply a lot of orchestration context for what is fundamentally a two-optional-param tool.

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-required-param tool with no output schema and no enums, the description covers every key decision point: when to call, what you get, how it degrades, how to parameterize, and what comes next. The only gap is the unspoken boundary with the semantically overlapping siblings, which would complete the orchestration story.

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 exactly 50% — only electiveGroupIds gets a description, and query has just a default. The description compensates by assigning functional meaning to both: 'browse those categories' for electiveGroupIds and 'thematic text search' for query. Both params are optional strings, so the semantic burden is light, but the description still adds real meaning 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?

States a specific verb and resource ('Explore the catalog') with a clear entry condition ('when the student does not yet know module or LU names') and details the unfiltered return payload (raw study plan, elective-group facets, bookable LU summaries). It stops short of explicitly naming its nearest siblings (search_fuxam, get_study_plan) to draw a boundary, so the differentiation is implied rather than stated.

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?

Opens with the selection condition (student doesn't know names) and closes with a follow-up workflow ('use get_module_details and get_learning_unit_details for the shortlist'), which routes the agent to the right next tool. However, it never explicitly contrasts against search_fuxam or get_study_plan, so the 'when not to use it / use X instead' guidance is absent.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description aligns with these rather than contradicting them. The description adds useful context by listing the returned data and noting that academic gates are unchanged, but it does not explain errors, authorization, or what 'alternative-assessment state' means.

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 front-loaded with purpose and the full list of return categories, followed by one targeted parameter note. Every sentence contributes meaning, though the return-category list is dense.

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 return surface of the tool and calls out an important cohortId fallback, which is valuable given there is no output schema. However, it leaves the required IDs' roles and the overall response shape to be inferred from the schema property names and tool title.

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 bears the burden of explaining parameters, but it only addresses cohortId explicitly. examId, moduleVersionId, organizationTermId, and attemptNumber receive no explanatory value beyond their property names and schema constraints.

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 and resource ('Drill into one assessment attempt') and enumerates the detailed fields returned, which makes the tool's purpose clear even without opening the schema. It does not explicitly differentiate itself from sibling tools such as get_module_attempts or search_fuxam, so some differentiation is left to inference.

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 when-to-use guidance is provided; the description never states when this tool should be chosen over sibling tools or what conditions make it the appropriate choice. The only usage note ('Omit cohortId...') concerns parameter behavior, not tool selection.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds meaning by explaining the result is a 'structural hierarchy' or 'path', giving insight into the return shape. No contradictions exist, and the description enriches the behavioral understanding beyond the structured 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?

The description is two sentences with zero redundancy. The primary action and object are front-loaded, and every phrase is informative. It follows the 'less is more' principle perfectly.

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 resolver with one parameter and no output schema, the description provides enough context for an agent to invoke it correctly. It explains the purpose, expected input type, and the nature of the output. Minor missing details like common use cases or response format examples are not critical given the tool's simplicity and the rich annotations.

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 for the undocumented lone parameter. It does add domain context by calling it a 'Fuxam layer ID', which explains what kind of ID is expected, but it doesn't elaborate on format, source, or examples. This is minimal but helpful, placing it above a tautology yet below thorough clarification.

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 'Resolve' and clearly defines the resource: a Fuxam layer ID to its structural hierarchy. It further differentiates itself from siblings by specifying the use case: understanding where a course, module, or content layer sits in the curriculum or organization tree. This clearly sets it apart from the many list/get tools among its 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 provides clear context on when to use this tool: 'This is useful for understanding where a course, module, or content layer sits in the curriculum or organization tree.' It does not explicitly name alternatives or state when not to use it, but the intent is clear and unambiguous. This meets the 'clear context, no exclusions' 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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds valuable behavioral details: missing IDs are reported separately, and schedule/deadline sections may be unavailable for certain courses. This extra transparency about edge cases exceeds what annotations alone provide.

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 relatively concise and well-structured: it opens with the core purpose, then details the return content, then provides usage context and exclusions. It avoids redundancy, though it could be slightly more streamlined.

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 adequately explains what is returned (complete course record plus appointments/deadlines) and covers important nuances (missing IDs, unavailable sections). It also provides usage guidance. It lacks some detail but is sufficiently complete for an agent to use effectively.

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 only 25% (only courseIds has a description). The tool description does not elaborate on the parameters' meanings or the effects of includeDeadlines/includeAppointments or the language enum. The description fails to compensate for the low schema coverage, leaving users to infer parameter semantics from names alone.

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: batch-inspecting learning-unit course IDs and returning their records, appointments, and deadlines. It distinguishes itself from sibling tools by focusing on detailed retrieval for specific course IDs and explicitly notes it does not rank or check conflicts, making its role 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 a clear usage condition ('Use this after narrowing a semester shortlist') and states what it does not do (rank, check conflicts, mutate). While it does not explicitly contrast with each sibling tool, the context is sufficient to guide when to use this tool over others.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering safety. The description adds the independence behavior: each module is returned independently so one unavailable record does not discard the others. This is useful beyond annotations, but no further behavior (e.g., errors, pagination) is disclosed, so the description complements but does not greatly expand on annotation.

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 first sentence enumerates the exact data returned; the second clarifies independence and provides the ID source. Information is front-loaded and each word adds value.

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 batch retrieval tool with no output schema, the description lists the data categories and warns against partial failure. However, it does not specify the response structure (e.g., array of objects keyed by moduleVersionId) or any edge cases, which could be important given the independence claim. The lack of an output schema increases the description's burden, and it only partially satisfies 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?

The schema provides only type and constraints for moduleVersionIds (array of strings, 1-20 items), with zero description coverage. The description compensates by stating these IDs come from study plans or connectedModule records, giving semantic context. It does not detail the format of each string or the relationship between IDs and the batch response, but the source hint is a meaningful addition 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 states a clear verb and resource: it retrieves a batch of attempt history, assessment requirements, attendance fulfillment, grades, and academic rules for several module versions. This distinguishes it from sibling tools like get_module_details or get_exam_details, which focus on other specific aspects. The tool's scope 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?

It provides explicit guidance on where to obtain the required IDs (from study plans or connectedModule records), which helps an agent know when this tool is appropriate. It does not explicitly name alternatives, but the detailed content makes it clear this is for batch academic data rather than individual lookup, so the usage context is 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is already clear. The description adds value by specifying the batch capability (max 20 items, though that's also in schema) and the nuanced parameter mapping (moduleId as courseModuleId). It also discloses that it returns attempt and academic-rule state, which is richer behavioral context. 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 two sentences, dense but not bloated. The core purpose is front-loaded in the first sentence, and the special-case parameter guidance is in the second. It earns its length by covering return contents and a critical nuance, though it could tighten wording.

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

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

Given the tool's moderate complexity (batch operation with three fields per item, no output schema), the description covers the purpose, return contents, and a key parameter nuance. It doesn't specify the output shape (no output schema exists), but for a read-only batch inspector with annotations covering safety, this is adequate. Slight gap: it doesn't clarify what 'academic-rule state' means or how term affects results, but overall complete 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 0%, so the description must compensate. It does not explicitly explain what courseModuleId or moduleVersionId are beyond what the schema property descriptions say (only courseModuleId has a schema description; moduleVersionId and organizationTermId have none). However, the description clarifies the critical relationship between moduleId and courseModuleId in a connectedModule record, which is semantic value beyond the schema. organizationTermId's purpose (optional term for learning units) is implied but not fully explained.

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 clear verb ('Batch-inspect') and resource ('module versions'), and enumerates the returned data (catalog settings, requirements, module info, associated learning units, attempt and academic-rule state). It distinguishes itself from sibling get_module_attempts by covering more than just attempts, though it doesn't name a specific sibling. The 'Batch' qualifier signals it handles multiple modules at once, which differentiates it from single-module 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 usage context (inspecting several module versions, optionally including a term) but does not explicitly state when to prefer this over siblings like get_module_attempts or get_learning_unit_details. It gives a concrete structural note about passing moduleId as courseModuleId in a connectedModule record, which helps in that particular case, but there is no general 'when to use' vs alternatives 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, and destructiveHint=false, so the safety profile is fully covered. The description adds 'unchanged' and enumerates the returned data, but offers no further behavioral details such as pagination, auth requirements, or rate limits. This is adequate but not rich.

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

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

Two sentences with no filler. The core return statement is front-loaded, and the follow-up instruction about using returned IDs earns its place by giving actionable guidance. Nothing is redundant or excessively verbose.

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 partially compensates by listing return contents and providing a forward pointer to drill-down tools. However, focusId is entirely unexplained, and with a broad set of sibling retrieval tools, the description does not fully delineate when this comprehensive snapshot is needed versus when to use a more specific 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 0%, so the description must compensate for the parameters. It references organizationTermId and how to reuse it, but provides no explanation of focusId, no indication that both parameters are optional, and no semantics about how the parameters affect the returned study plan.

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 ('Return') with a detailed resource list: module elections, elective pools, available terms, attempt summaries, and study-plan state. It also distinguishes this tool from 'drill-down tools' by positioning it as the top-level entry point, so an agent can clearly understand what this tool provides.

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?

Explicitly instructs the agent to use the returned organizationTermId and moduleVersion.id values with the drill-down tools, establishing when this tool should be used—as a prerequisite for deeper lookups. It doesn't name specific sibling tools or provide negative conditions, but the entry-point role 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 indicate a mutation (readOnlyHint=false). The description adds useful behavioral context by specifying it operates on the 'real student account' and that it will re-read the catalog to report the resulting position. No contradictions with annotations, but it does not disclose edge cases like duplicate join attempts or failure handling.

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?

A single concise sentence that leads with the primary action and includes the follow-up read. No wasted words or redundant 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?

The description touches on the main action and the reporting step, but with no output schema it should specify the return format or result structure. It also omits common edge cases (e.g., already on waitlist, course not available). For a simple mutation tool, this is adequate but not thorough.

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?

With 0% schema description coverage, the description must explain the parameter. It only implies courseId is the course to join via the phrase 'Join a course waitlist' but never explicitly maps it or describes how to obtain the ID. This leaves the parameter under-explained for a tool with a single required param.

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 a specific verb (Join) and resource (course waitlist) and adds a secondary action (re-read booking catalog) that differentiates it from siblings like book_course and leave_waitlist. It is unambiguous what the tool does.

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 no explicit guidance on when to use this tool versus alternatives such as book_course or leave_waitlist. It does not state conditions like 'use when a course is full' or 'when not already enrolled,' leaving usage context 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?

The description explicitly mentions leaving a waitlist on the real student account, indicating a real side effect, and advises verifying the resulting state. The destructiveHint annotation is true, and the description aligns, with no contradiction. It clearly conveys that this action modifies live data and is destructive in 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?

Description is a single concise sentence that clearly states the action and the verification step, without unnecessary 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?

The description gives enough context about the entity ('course') and the follow-up action ('re-read the booking catalog'), making it self-contained for most use cases, though it could mention prerequisites like being on a waitlist.

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?

Only one parameter, courseId, is presentaren't described; description says 'Leave a course waitlist' which implies courseId is the identifier, but doesn't provide details on allowed formats, how to obtain it, or whether it's the course or waitlist ID. Schema description coverage is 0%, so the tool's own description doesn't explain the 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's function: leaving a course waitlist, and includes the verification step of re-reading the catalog, making the 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?

It explains the primary action and the verification step, but doesn't explicitly state prerequisites like how to obtain the courseId or conditions such as being on the waitlist. However, with sibling tools listing waitlists, it's inferable.

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 context about the filtering scope ('applicable to the student') and the meaning of excluded dates, which goes beyond the raw annotations. No contradictions found.

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. The primary action and resource are front-loaded, and the constraints (ISO-8601, student-specific) follow naturally. There is no fluff or redundant content, making it highly efficient for an agent to parse.

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 and strong annotations covering safety, the description provides sufficient context for an agent to call the tool correctly. It states the resource, the interval format, and the intended application. It does not describe the return structure or sorting, but for a read-only list operation this is minor. An agent can confidently invoke it with the given parameters.

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 mentions 'ISO-8601 date or datetime interval', which hints that both 'from' and 'to' are ISO-8601 strings and bound the interval, but it does not explicitly explain which parameter is the start/end or whether they are inclusive. This is a partial compensation, leaving room for interpretation.

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 'Return' and the specific resource: 'institution-wide excluded dates applicable to the student'. It also specifies the interval format (ISO-8601 date or datetime) and gives examples ('holidays or closure periods'). This distinguishes it from sibling tools like list_course_deadlines or list_student_appointments, which target different data types.

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 frames the use case: retrieving unavailable scheduling dates. It implies when to use this tool (e.g., checking holidays affecting the student's schedule) but does not name alternatives or exclusion conditions. While not exhaustive, the context is clear enough for an agent to select it over siblings without further 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 carry readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description need not repeat safety. It adds pagination behavior ('one upstream page' and 'Follow pageCount') and lists the specific data returned. This is meaningful context beyond the annotations, though it doesn't address auth or rate limits, which are minor given the safety hints.

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 with zero waste. The main purpose is front-loaded, followed by actionable usage guidance and a pagination hint. Every sentence contributes value, and the structure is easily scannable.

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

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

For a read-only listing tool with no output schema and optional parameters, the description covers the main return fields and gives usage hints. However, it omits explanations for `page` and `perPage` and does not explicitly state when to choose this over sibling tools. Given the annotations cover safety, this is acceptable but not fully complete.

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

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

Schema description coverage is only 33% (only `search` has a description). The description does not explain `page` or `perPage` semantics, nor does it mention them at all. It references `pageCount` but that is an output field, not a parameter. With low schema coverage, the description should compensate, but it fails to clarify pagination controls, leaving the agent to infer their meaning from defaults and types only.

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 returns 'one upstream page of bookable learning units unchanged' with specific included fields (capacity, enrollment, waitlist state, descriptions, connected modules). It distinguishes itself from siblings by indicating which identifiers to use for booking, schedules, and curriculum tools, 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 guidance on how to use the returned data: 'Use id for booking/waitlists, layerId for course schedules, and connectedModule.moduleVersionId for curriculum tools.' Also advises to 'Follow pageCount to inspect further pages.' It does not explicitly mention when to use this tool over alternatives like list_enrolled_courses or get_learning_unit_details, but the field usage guidance partially covers 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, openWorldHint, idempotentHint, and non-destructive behavior, so the description only needs to add context. It adds the pass-through behavior ('unchanged') and the layerId provenance caveat, but does not disclose pagination shape or how direction affects 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?

Two sentences with no filler; the core operation is stated first and the critical parameter caveat is second. 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?

The description is adequate for the required parameter but not fully complete: no output schema exists, and pagination behavior plus direction semantics are not explained. The layerId warning is valuable, yet an agent still lacks guidance on how limit, cursor, and direction should be used.

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?

With 0% schema description coverage, the description must carry parameter meaning. It does clarify layerId's required source, but limit, cursor, and direction are left entirely to their schema names/defaults, which is only partial compensation.

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 action and resource: 'Return one course's appointment page unchanged.' It scopes to a single course and warns about layerId provenance, which helps distinguish it from learning-unit tools, though it does not explicitly contrast it with list_student_appointments.

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 gives a clear precondition: supply layerId from enrolled or bookable course data, not the learning-unit course id. However, it does not state when to choose this tool over list_student_appointments or list_bookable_courses, leaving the selection inference to the agent.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds that the tool returns items and pagination metadata 'unchanged' and operates on 'one course', which is useful context about the return behavior and scope. This is a modest addition beyond annotations but not contradictory.

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

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

The description is a single sentence that is concise and front-loads the core purpose before giving the parameter hint. There is no fluff or redundancy, and it is appropriately sized for a straightforward list operation. It could be slightly more structured, but the brevity is effective.

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 bears the burden of explaining what the tool returns; it only offers a high-level 'deadline items and pagination metadata unchanged', without detailing the structure of items or pagination metadata. It also lacks explanations for limit, cursor, and language, and provides no info on when to use it relative to siblings. The description is too thin for a tool with this parameter count and pagination 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?

Schema description coverage is 0%, so the description must compensate for all parameters. It only mentions layerId (with a source hint) but completely ignores limit, cursor, and language. For a tool with four parameters, especially pagination-related ones, this is a significant gap that leaves the agent guessing about the remaining parameters' purposes and formats.

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 ('Return') and a clear resource ('one course's deadline items'), and further clarifies that it returns pagination metadata unchanged. It distinguishes the tool's single-course scope, though it does not explicitly name sibling alternatives to differentiate from. The purpose is clear and not a mere tautology.

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

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

The description provides a usage hint by instructing to 'Supply layerId from enrolled or bookable course data', which tells the agent where to source the required parameter. However, it does not state when to use this tool versus alternatives, nor does it give any exclusion criteria. The guidance is partial but not misleading.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint: false, so the description carries a lighter burden. The phrase 'unchanged' reinforces the read-only nature, and the clarification that course id and layer_id are different identifiers adds some context, but it does not disclose substantial new behavior 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, front-loaded sentence that states the core action and scope, followed by a brief clarification about identifiers. Every clause adds information, and there is no redundancy or 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?

Given the simple tool shape—one optional parameter and no output schema—the description lists the return contents and clarifies identifier semantics, which covers most of what an agent needs. It omits minor details like search filtering behavior and pagination, but these are not essential for correct invocation.

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 fully describes the only parameter, 'search', as 'Optional course search text' with 100% coverage. The description does not add any further meaning or usage details for this parameter, so it provides no value beyond 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 uses a specific verb ('Return') and names the exact resource ('the student's enrolled course records'). It further distinguishes itself from siblings like list_bookable_courses by emphasizing 'enrolled' and specifying the included fields, making the tool's purpose immediately clear.

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 establishes the context: this returns enrolled course records, and the optional search parameter is documented. However, it does not explicitly state when not to use this tool or name alternatives such as list_bookable_courses, so it provides strong context but no explicit exclusionary 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, and destructiveHint=false, so the safety profile is covered. The description adds value by stating the records are returned 'unchanged' and clarifying that they are not a recommendation signal, which is useful behavioral context beyond the annotations.

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

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

Two sentences with no wasted words. The core action is front-loaded, and the clarifying caveat about recommendation signals is placed second, keeping the structure efficient and readable.

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 tool with strong annotations, the description is complete. It explains what is returned, that the data is unchanged, and how the data should be interpreted, which is sufficient for an agent to invoke it correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the empty input schema is fully consistent with the described 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 states a specific verb ('Return') and resource ('student's pinned-course records unchanged'), clearly identifying what the tool does. It also distinguishes the tool's meaning from recommendation signals, which helps separate it from sibling tools like list_enrolled_courses.

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

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

The description gives clear context for when to use the tool: pinned courses indicate the student's current working set. It also implicitly warns against using it as a recommendation signal, though it does not explicitly name alternative tools or state when-not-to-use conditions.

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

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

Annotations already declare the operation as read-only, open-world, and idempotent. The description adds value by explaining the pagination contract ('Use the returned cursor for another page') and listing returned fields. However, it does not elaborate on what 'attendance settings' means or what 'unchanged' implies behaviorally, so the added context is moderate.

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—two sentences that front-load the primary action and include a helpful pagination hint. It wastes no words and is easy to parse.

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 moderate complexity with four parameters, yet the description does not cover the semantics of direction (past/future) or showPastAppointments. An agent cannot fully determine how to retrieve past vs. future appointments, which is likely a common use case for this tool. The lack of an output schema makes this omission more 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?

With 0% schema description coverage, the description carries the full burden of explaining parameters. It only hints at 'cursor' usage and provides no information about 'limit', 'direction', or 'showPastAppointments'. The absence of any explanation for the direction parameter (initial/past/future) is a major gap that the description fails to fill.

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 main action: returning one page of the student's agenda, and lists the fields included (times, locations, organizers, etc.). It is somewhat specific, but it does not explicitly differentiate from the sibling tool list_course_appointments, which could be confused for a similar 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 provides no explicit guidance on when to use this tool versus alternatives. It neither mentions prerequisites nor suggests calling this tool for student-specific appointments versus course appointments. The only usage hint is implicit from the tool name, which is not enough for an agent to decide between similar tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns the workload 'unchanged' and explicitly lists the status categories, which gives useful behavioral context about the output scope without contradicting annotations.

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

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

Two sentences, no filler. The first sentence states the primary action and the second adds the planning context. It is efficiently front-loaded and every word contributes value.

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 six parameters, no output schema, and 0% schema description coverage, the description is far too thin. It omits any explanation of the timePeriod default or the effect of the boolean toggles, and provides no details on the return structure or possible pagination. An agent cannot fully infer correct usage from this definition alone.

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 carry parameter meaning. However, it does not explain what timePeriod means or how the boolean flags (showLocked, showCompleted, etc.) control the output. The status categories are mentioned, but there's no mapping to the parameters, leaving agents to guess parameter semantics.

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 ('Return') and a clear resource ('the student's Fuxam content-block workload and current statuses'), and names the concrete status categories (outstanding, in-progress, completed, reviewed, locked). This is unambiguous and distinct from siblings like list_courses or get_study_plan.

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 the tool is for planning workload, but does not explicitly state when to use it over alternatives (e.g., get_study_plan or list_course_deadlines) or when not to use it. There is no mention of exclusions or preferred 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?

The description adds the behavioral detail that the upstream result is returned unchanged, which is useful. With readOnlyHint, idempotentHint, and destructiveHint already true, the safety profile is covered, but the description does not elaborate on pagination, rate limits, or error behavior, so a score of 3 is appropriate.

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

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

Two sentences with no fluff. The first sentence states the core action and behavior, and the second gives concrete usage context. Efficient and well-structured.

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 4 parameters and no output schema. The description covers purpose, usage timing, and the key behavior of returning the upstream result unchanged. It is sufficiently complete for an agent to know when to call it and what to expect, though it does not specify pagination details available in the 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?

Schema description coverage is 50%; only query and types have descriptions. The description mentions entity types but does not clarify limit or offset semantics. Since coverage is not low and defaults are provided, the description adds minimal value beyond the schema, so a baseline 3 is warranted.

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 what the tool does: 'Search Fuxam entities and return the upstream result unchanged.' It lists the entity types it covers and explicitly frames it as a discovery tool before specialized tools, which differentiates it from the sibling list functions.

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 explicit guidance on when to use the tool: 'Use this to discover course, module, term, appointment, and exam IDs before calling specialized tools.' This clarifies its role relative to the specialized siblings, though it does not name specific alternatives or give exclusion conditions.

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

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

While annotations already indicate destructiveness, the description adds value by disclosing that the tool verifies the outcome with a fresh read, which implies an internal read-after-write behavior. It also specifies the target as 'real student account,' hinting at environment‑sensitive behavior. This goes beyond the annotation flags, though it could be more explicit about side effects or error handling.

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

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

The description is a single, tightly worded sentence that packs all essential information without fluff. It front-loads the action and includes a meaningful detail (verification) without drifting into unnecessary explanation. Every word earns its place.

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

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

For a destructive action with one parameter, the description provides enough context to understand its purpose and a key behavioral nuance (verification). It could mention idempotency (since the idempotentHint is false) or clarify what 'real student account' means, but these are minor gaps given the simplicity of 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 input schema provides only the parameter name and type, with no description, so the description must compensate. It clarifies that the parameter is a 'learning-unit course ID,' which narrows its meaning, but does not specify format, source, or acceptable values. This is partial compensation for the 0% schema coverage, warranting a mid‑range score.

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 'unbook' with a clear resource ('learning-unit course ID from the real student account') and includes a distinct verification step ('verify its absence with a fresh enrolled-course read'). It clearly differentiates from siblings like 'book_course' and 'leave_waitlist' by naming the exact action and object. No ambiguity remains about what the tool does.

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 verb 'unbook' implies its use case, and the 'real student account' hints at a production context, but there is no explicit guidance on when to prefer this over alternatives (e.g., 'leave_waitlist') or conditions like 'do not use if already unbooked'. The usage context is largely implied by the name rather than spelled out.

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