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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so 'Read-only. Does not create or delete events.' mostly restates them. The description nonetheless adds genuinely new behavioral facts: the Europe/Berlin timezone, the YYYY-MM-DD format, the default 14-day window, and the required calendar permission.

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 short sentences, front-loaded with the core action, then format/timezone, then defaults, then permissions, then safety. Nothing is padded, and each sentence delivers a distinct fact.

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 two-parameter read tool with no output schema, the definition covers format, defaults, permission, and safety. It does not describe the shape of returned events or pagination, which is the remaining gap, though the core calling information is 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 coverage is 0%, so the description must carry the parameter burden, and it largely does: date format, timezone, and the default range when dates are omitted. It stops short of stating boundary inclusivity (whether from/to are inclusive) or ordering expectations, which would have earned a 5.

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

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

The description opens with a specific verb and resource: 'Read wbservicesbasic.kalender and filter events to a date range.' That is unambiguous about what is fetched and that a filter is applied. It does not explicitly contrast with siblings like get_course_dates, so it lands just short of a 5.

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

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

It gives useful calling context — default window of today through 14 days and the required 'calendar right' — which implies when the tool applies. However, it never states when to prefer this over other date/event-oriented siblings, so the guidance is implied rather than explicit.

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

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

Annotations already cover read-only, idempotent, open-world, non-destructive semantics, so the description only needs to add context. 'No token' is a genuine addition (unauthenticated access), but nothing is said about what happens for a non-public or nonexistent courseId, nor about error or rate-limit 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?

Two short, front-loaded sentences with no filler; the resource and auth condition come first. The raw endpoint path is arguably low-value detail for an agent but costs little.

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?

No output schema exists, so the agent has no idea what the returned course object contains, and the meaning of the language parameter is unexplained. For a simple two-parameter read tool this is adequate but leaves meaningful gaps around response shape and the public/non-public failure case.

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, yet it only surfaces courseId via the path template and never mentions the optional 'language' parameter (e.g. whether it localizes the response or course content). The numeric pattern and enum are visible in the schema, but the intent of 'language' is undocumented anywhere.

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 ('Read one public course') and even gives the concrete endpoint path, which pins down scope. It does not explicitly say how it differs from siblings such as get_course_details or list_my_courses, so the agent must infer the 'public single course by id' distinction from the word 'public'.

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 token' is a useful precondition for deciding whether this tool can be called at all. However, there is no explicit when-to-use vs which-alternative guidance (e.g. when to prefer get_course_details or list_my_courses), leaving selection 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 read-only, idempotent, open-world, and non-destructive behavior. Beyond that, the description adds important auth context: courseId requires no token, while lvNumber requires a token and lectures right. It does not discuss pagination, rate limits, or return shape, but the added auth detail is substantive.

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 three compact sentences, front-loaded with the core action, then the two invocation modes and the exclusivity constraint. There is no redundant wording.

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

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

It covers the main routing decision and auth requirements, which are the highest-risk parts of the call. However, for a tool with six parameters and no output schema, it is incomplete: the four undocumented filters and any result/pagination behavior are left unaddressed.

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. It explains courseId and lvNumber semantics and exclusivity, but leaves limit, groupId, language, and includePast completely undocumented in both the schema and the description. This is only partial compensation for a six-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 states a specific verb and resource: 'List course dates.' It distinguishes two operating modes by source endpoint, but does not explicitly differentiate this tool from siblings such as get_course_details or 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 gives clear conditional guidance: use courseId for the public catalogue and lvNumber for wbservicesbasic, and pass only one. It does not explain when to choose this tool over sibling course-detail tools, but the mode-selection guidance is strong.

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

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

Annotations already cover readOnly, idempotent, non-destructive, and open-world, so the safety profile is handled. The description adds real context beyond that: which underlying tables are touched, that veranstaltungenTermine is only read when includeDates is true (and that true is the default), and the required permission — all things the agent could not learn from annotations or 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?

A single compact sentence with the resource, the conditional behavior, and the prerequisite front-loaded; nothing is wasted. The internal table names are dense jargon but they do encode real behavioral information.

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

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

With only two parameters and no output schema, the description should say something about what comes back for a detail call (e.g., which fields appear when dates are included). It explains input-side behavior well but leaves the return shape entirely unspecified, so an agent knows how to call it but not what to expect.

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. It does explain includeDates behavior and its default, which is genuinely additive, but lvNumber is only described as 'one LV number' with no format, source, or example despite the schema's numeric pattern.

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: read veranstaltungenDetails for a single LV number, with dates read conditionally. An agent can tell this is a single-course detail lookup, but the description never distinguishes it from nearby siblings such as get_course, get_course_dates, or search_lectures, so 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?

Usage is implied (fetch details for one known LV number) and the access prerequisite 'requires the lectures right' is stated, which is useful. There is no explicit when-to-use versus get_course/get_course_dates guidance and no advice on when to set includeDates=false to avoid the extra table read.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description's one piece of added behavioral context is 'No token', which usefully discloses that no authentication is required, but it says nothing about pagination, result volume, or failure modes.

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, front-loaded with the verb and resource, with no padding. The raw endpoint path is slightly technical but does convey the source resource.

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 two-parameter read with no output schema, the definition covers the core intent and auth status. It stops short of defining what a 'course group' contains or how the parameters shape the response, which an agent would want before calling.

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 carries the full burden for the two parameters, yet it never explains what courseId identifies or how language affects results. Only the vague implication that results are scoped to a course can be inferred.

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

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

States a specific verb ('List') and resource ('public course groups') plus the backing endpoint, so the agent knows exactly what it retrieves. It lacks explicit differentiation from siblings like list_public_exams or get_course_details, which keeps it from a 5.

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

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

'List public course groups' plus 'No token' implies this is the unauthenticated listing route, which hints at when it is applicable. There is no explicit when-to-use guidance or mention of an alternative for authenticated/filtered listing.

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, destructiveHint=false, and openWorldHint, so "Read-only" mostly repeats structured data. The one genuine addition is the required "tuition fees right", which tells the agent an authorization prerequisite exists that the annotations do not express; no pagination, error, or rate-limit behavior is disclosed.

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, front-loaded with the resource and the returned fields, with the access requirement last. The internal endpoint name (wbservicesbasic.studienbeitragsstatus) is jargon an agent gains little from, but nothing is padded or redundant.

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

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

With no parameters, no output schema, and rich annotations, the description supplies the remaining essentials: what data comes back and that a specific right is needed. It stops short of explaining failure modes when the right is missing, which keeps it from a 5.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The listed fields (semester, open amount, deadline) describe the result shape rather than inputs, which is a mild bonus rather than a parameter 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?

States a specific verb and resource ("Read wbservicesbasic.studienbeitragsstatus") and names the data returned: semester, open amount, and deadline. That makes the tool's purpose unmistakable, though it never contrasts itself with sibling tools such as get_grades or list_semesters.

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 prerequisite ("Requires the tuition fees right"), which implicitly tells the agent this only applies to fee-related queries. It offers no explicit when-to-use framing or named alternatives, so the routing guidance is only implied.

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, destructiveHint=false, and the description's 'Read-only' merely restates that. What it does add beyond annotations is the permission requirement and the fact that the default behavior silently reads an additional dataset (absNoten), which changes the payload shape. It does not say what happens when the permission is missing or what the returned grade records look like.

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?

It is short with no filler, and the default-value fact is stated up front where it matters. But leading with an internal service identifier rather than the resource hurts front-loading, and 'Read-only' duplicates the annotations, so a sentence is spent on zero-information 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 single-parameter read tool with full annotations and no output schema, the definition covers the data source, the default parameter behavior, the permission gate, and safety. It falls short on explaining what the returned grade data contains and what 'absNoten' vs 'noten' actually means, which is the key ambiguity for an agent deciding whether to call it.

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

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

Schema coverage is 0%, so the description must carry the parameter, and it does supply the one thing the schema omits: includeAverages defaults to true and gates whether absNoten is also read. That is meaningful behavioral semantics, not just a restatement of the boolean. The only gap is that 'absNoten' is never explained, leaving the parameter's practical effect partly opaque.

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 verb/resource is stated but only via the internal endpoint name 'wbservicesbasic.noten', which is domain jargon rather than a plain-language statement of purpose. Naming 'absNoten' as a second dataset read adds some specificity, yet an agent without the internal glossary cannot tell exactly what it gets back. No sibling differentiation is offered, though none of the listed siblings appear to be grade-related.

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?

'Requires the grades right' is a genuine precondition that tells the agent when the call will fail, which is more than nothing. However, there is no guidance on when to prefer this tool, no mention of how it relates to identity/course tools that likely scope the grades, and no 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and idempotentHint=true, so safety is covered. The description still adds real value beyond them by disclosing the required permission ('identity right') and describing what data comes back (TUM ID, name, obfuscated ids) in the absence of an output schema. It does not describe failure behavior when the right is missing, which keeps it short of a 5.

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 compact sentence front-loads the action and scope, then the payload, then the prerequisite. No filler, no restatement of the tool name as a standalone sentence.

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, non-destructive read with full annotation coverage and no output schema, the description supplies everything an agent needs: what it returns, that it is self-scoped, that it is read-only, and what permission is required.

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 takes zero parameters, so the schema carries no semantics to supplement and the baseline is 4. The description correctly implies no input is needed by framing everything as 'for this user'.

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 (read) plus the exact resource (the caller's identity record) and enumerates the returned fields (TUM ID, name, obfuscated ids). The phrase 'for this user' implicitly scopes it to the caller, which distinguishes it from person-lookup siblings such as get_person or search_persons, though it never names an alternative explicitly.

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

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

Usage context is implied rather than stated: 'for this user' tells an agent this returns the authenticated caller's identity, not an arbitrary person. The only explicit constraint is the prerequisite 'Requires the identity right'. There is no statement of when to prefer this over get_person, search_persons, or get_token_status.

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, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description usefully adds that the person's right is required and that profile images are omitted, but 'the persons right' is ambiguous and error or not-found behavior is not described.

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 definition is short and front-loaded, with the core read operation stated first. It wastes little space, though 'wbservicesbasic.personenDetails' is internal jargon and 'Read-only' duplicates the annotation.

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

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

For a simple one-parameter read tool, the description provides the permission requirement and an output limitation, while annotations cover safety behavior. It still leaves out returned fields beyond image omission and any personId format or acquisition guidance, which matters because there is no output schema.

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

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

Schema description coverage is 0%, and the description never mentions personId, its expected format, or where to obtain a valid value. The single parameter name is somewhat self-explanatory, but the description does not compensate for the missing schema documentation.

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 ('Read') against a specific resource and adds that profile images are omitted, which narrows what the tool returns. However, the resource is an internal endpoint name and the description does not distinguish this result from sibling tools such as search_persons, so it falls short of fully self-contained purpose clarity.

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?

There is no guidance on when to use get_person instead of alternatives like search_persons or get_identity, nor any note on when not to use it. At best, usage is implied by the read-only nature of the operation.

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, non-destructive and openWorld, so the safety profile is covered. The description still adds real value beyond them: it discloses that the response resolves parent locations (so a Heilbronn room is identifiable as such) and that no TUMonline token is required — an auth fact the annotations do not express.

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 tight sentences with the core action front-loaded and no filler. The parent-location clause is slightly opaque phrasing ('visible as such'), but it still earns its place by explaining return 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?

With no output schema, the description should explain what comes back; it partially does via the parent-inclusion note and the auth remark. It leaves gaps on the `language` parameter's effect on returned names and on `id` format, which matters for a 2-parameter tool with zero schema documentation.

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 the parameter burden. It identifies the `id` as a NavigaTUM location id used in the API path, but adds no format or example for it, and the `language` parameter (de/en) is never mentioned in the description at all.

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: 'Read one NavigaTUM location from /api/locations/{id}'. The single-record scope is explicit, which implicitly separates it from the sibling search_rooms, but the sibling is never named, so the agent must infer the distinction.

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

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

Usage is implied rather than stated: the endpoint path and 'Read one' signal a by-id lookup, and 'No TUMonline token' tells the agent no auth is needed. There is no explicit when-to-use or when-not-to-use guidance, and no named alternative such as search_rooms for discovery.

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

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

Annotations already cover readOnly/idempotent/non-destructive, so the description usefully adds the one thing structured data cannot: it never returns the token, and probe actively calls each personal function once. That fan-out behavior is real operational cost an agent should know. It omits expected latency or failure behavior under partial auth, which keeps it off a 5.

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?

Front-loaded with the core purpose, then two short clarifying clauses with no filler. Minor leak of an internal field name ('isTokenConfirmed') reads as implementation detail rather than agent-facing vocabulary, but it costs little.

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 does the necessary work: it says what is reported (token present, confirmed active, per-right result) and explicitly what is not returned. The precise per-right result shape lives in the probe parameter description, which is an acceptable place for it. Adequate for a two-boolean read 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 coverage is 100%, so the schema already documents both booleans, including that refresh is ignored. The description reinforces probe's meaning ('which rights answer') but adds no format or default detail 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?

States a specific verb and resource: report token storage, confirmation state, and which rights respond. The 'rights' enumeration (calendar, lectures, grades, identity, persons) ties it to the sibling personal-data tools without ambiguity. It stops short of naming a sibling alternative explicitly, so it reads as clear-but-not-differentiating at the 5 level.

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

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

Usage is only implied: 'when probe is true, which rights answer' tells the agent this is a diagnostic/preflight check against the personal endpoints, but the description never says when to call it versus just calling get_grades or get_identity directly. No exclusions or cost warnings are given, even though probing fans out to many TUMonline calls.

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?

It informs the agent of a critical prerequisite ('Requires the lectures right') that is behavioral context regarding authorization, which is not captured by the existing boolean annotations. This is vital for ensuring the tool call will succeed.

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 highly efficient, utilizing a single sentence to cover the data source, the specific fields retrieved, the security requirements, and the operation's read-only status. There is zero wasted language.

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 simplicity of a zero-parameter list operation, the definition is highly complete. It specifies the source, the output data structure, and the necessary permissions, leaving the agent with all the context needed to invoke it correctly.

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

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

Since the input schema has zero parameters, the baseline score of 3 is applied. The description does, however, add useful semantic value by defining the structure of the output (the specific fields listed), aiding downstream agent processing.

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 action ('List'), a specific resource ('courses'), and provides a comprehensive list of the data points returned (LV number, title, type, semester, and lecturers). This makes its function 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 tool name and the source specified ('Eigene') imply its usage is restricted to the user's personal course list. However, it provides no explicit exclusion criteria or advice on when to choose this over a broad search tool like search_courses.

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 safety profile is covered. The description still earns credit by adding the authorization prerequisite ("Requires the exam results right") and the negative scope guarantee that it does not register for an exam — context an agent cannot get from 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?

Four short sentences with the resource and scope front-loaded; nothing is buried. "Read-only" lightly duplicates readOnlyHint=true, a minor redundancy rather than a flaw.

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 tool with no output schema, the description covers origin, authorization, and mutation scope adequately. It never indicates what an exam record contains (fields, ordering, result/grades availability), so the agent cannot anticipate the response shape.

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

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

The tool takes zero parameters, which is the baseline-4 case; there is no parameter meaning to add. The description correctly spends no words on nonexistent inputs.

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

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

States a specific verb and resource ("List exams") and qualifies the scope via the source endpoint pruefungenEigene ("own exams"), so it is clearly the personal exam list rather than a catalog. It does not name list_public_exams or another sibling to draw the contrast explicitly, which keeps it from a 5.

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

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

Usefulness is implied rather than stated: the agent must have the exam results right, and the final sentence rules out one adjacent capability (registration). There is no explicit when-to-use condition and no named alternative such as list_public_exams for exam catalog browsing.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds two things they do not: no authentication token is required, and it reads at most three pages, which signals that results may be truncated rather than exhaustive. That pagination cap is exactly the kind of behavioral caveat an agent needs; only the absence of any note on what a truncated result looks like keeps it from a 5.

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?

Four short sentences, front-loaded with the core purpose and followed by constraints, with no filler. The raw endpoint path is arguably noise for an agent, but it is brief and does not obscure the main statement.

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?

There is no output schema and no parameter documentation, so the description is the only source of detail about the request shape and response — and it says nothing about the four inputs or what exam records contain. For a four-parameter, untyped-output listing tool this leaves substantial gaps despite the good notes on auth and page limits.

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% across four parameters, so the description carries the full explanatory burden — yet it mentions none of from, to, limit, or courseNumbers. An agent gets no hint about date format expectations, whether the range is inclusive, how limit interacts with the three-page cap, or how courseNumbers filters results.

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

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

States a specific verb and resource ('List public exam dates') and even names the backing endpoint, so the operation is unambiguous. The word 'public' implicitly distinguishes it from list_my_exams, but no sibling is named explicitly, which keeps it short of a 5.

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

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

The exclusion 'Does not register for an exam' and 'No token' give useful context about when this tool is appropriate. However, it never explicitly contrasts with list_my_exams or states the condition that should route an agent here versus the personal-exam variant, so the guidance remains implied.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds real behavioral context beyond them: no authentication token is required and the selected semester serves as the default, which helps the agent understand access and result semantics. The endpoint path adds little, and return structure is not described.

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, front-loaded sentences that lead with the core action. The raw endpoint path ('ee/rest/slc.lib.tm/semesters/student') is largely wasted text for an agent, but the rest is tight and free of padding.

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

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

For a simple one-parameter list tool whose annotations cover safety and that has no output schema, the description conveys the essentials. However, it leaves the language parameter unexplained and says nothing about the shape of returned semester data, leaving gaps an agent may need to fill.

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

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

There is a single parameter (language, enum de/en) at 0% schema description coverage, yet the description never mentions it. The enum values are somewhat self-explanatory, but the description contributes no meaning about what the language parameter controls, so it fails to compensate for the coverage gap.

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 the specific verb 'List' with the concrete resource 'public TUMonline semesters,' making the purpose unambiguous. It doesn't explicitly contrast with sibling tools, but the resource is distinct enough that an agent won't confuse it with course or person lookups.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tools are named. 'No token' hints at ease of access but is not usage direction, and 'the selected semester is the current default' describes return semantics rather than invocation criteria.

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 declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-redundant behavior: no authentication token is required and the catalogue is public, which changes how an agent should plan the call.

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, front-loaded with the verb and resource, then the auth fact, then the one non-obvious parameter format. Nothing is padded or repeated from the schema.

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?

Without an output schema, the description should convey roughly what a result looks like and how limit/offset page through the catalogue, but neither is mentioned. It is adequate for calling the tool but leaves the agent guessing about return shape and pagination behavior.

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 carries the burden, and it only explains one parameter: the semester key format ("26W or a semester id"). That is valuable, but query, limit, offset and the de/en language parameter are left to self-evident naming, and what fields "query" actually matches is never stated.

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 gives a specific verb plus resource ("Search the public course catalogue") and even names the underlying endpoint, which unambiguously identifies the operation. It stops short of contrasting with siblings such as list_my_courses or get_course, so the agent must infer the public-catalogue vs. personal-enrolment distinction.

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 token" states an important prerequisite and implies unauthenticated public use, which usefully separates it from token-gated siblings. However, there is no explicit when-to-use/when-not guidance and no named alternative for course lookups, so the agent must infer routing from the word "public".

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

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

The annotations already establish read-only, idempotent, non-destructive behavior, so the final “Read-only” is redundant. The description nevertheless adds useful context beyond those annotations: the concrete backend service and an authorization requirement, though it gives no further detail about search or failure 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 purpose is front-loaded, followed immediately by the alternative tool and access prerequisite in four very short statements. There is almost no waste; only the final read-only statement repeats structured information, without creating meaningful bloat.

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

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

For a one-parameter read-only search, the description adequately covers tool selection and the main access prerequisite. However, the undocumented query and absence of an output schema leave searchable fields, result scope, and result shape unclear, so the definition is usable but not fully self-contained.

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 needed to explain query, but it never says whether the text matches lecture titles, identifiers, instructors, or other fields. Its general role as lecture-search text is inferable, yet no syntax, matching behavior, or example is supplied.

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?

“Search lectures” gives a specific verb and resource, while the token-service name clarifies the intended backend. The explicit contrast with search_courses for the public catalogue distinguishes it from the most relevant sibling.

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

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

The description explicitly routes public-catalogue searches to search_courses rather than leaving that choice to inference. It also states the “lectures right” prerequisite, helping the agent avoid an unauthorized invocation.

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/non-destructive, so the bar is lower, and the description adds two things they don't cover: the authorization requirement ('Requires the persons right') and the fact that only ids come back, not full person records. The closing 'Read-only' merely restates readOnlyHint=true, which is minor redundancy rather than contradiction.

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

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

Four short clauses, front-loaded with the core action and followed by the return value and the prerequisite — no padding. Minor waste in the internal API name 'wbservicesbasic.personenSuche' and in 'Read-only', which duplicates the annotations.

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

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

For a single-parameter search tool with no output schema, the description covers purpose, return shape (ids), and authorization, which is most of what is needed. The critical gap is query semantics — what the string is matched against and how matching works — which leaves the agent guessing at 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?

There is one parameter with 0% schema description coverage, so the description must carry the burden of explaining it — but 'query' is never mentioned. The agent gets no idea whether it matches names, emails, partial strings, or what the 2-80 character constraint implies about matching 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?

States a specific verb+resource ('Search people') and immediately distinguishes itself from the sibling get_person by noting it 'Returns ids for get_person', i.e. this is the lookup step, not the detail step. An agent can tell the two apart without opening either schema.

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

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

The phrase 'Returns ids for get_person' effectively prescribes the two-step flow (search first, then fetch details), and 'Requires the persons right' gives a prerequisite an agent must check. It stops short of naming when NOT to use it or what happens with zero/many matches, so no explicit exclusions.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive) and openness, so the bar is lower, yet the description adds genuinely non-obvious behavior: no TUMonline token is required, and the default result set spans all campuses including Heilbronn, which would otherwise surprise an agent filtering for Garching. It omits the 20-result cap behavior and whether results are ranked or mixed across entity types.

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

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

Three compact sentences, each carrying distinct information: what is searched, the auth fact, and the default scope plus how to narrow it. The filtering instruction is placed last where an agent will act on it, and nothing is redundant.

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 three-parameter, no-output-schema search tool this is close, but gaps remain: the description does not say whether results are a mixed list of rooms/buildings/sites or differentiated by type, nor how truncation at 'limit' behaves. Those are the details an agent needs to interpret what comes back and whether to re-query.

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

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

Schema coverage is 0%, so the description must carry the parameter burden. It does well on 'campus', explaining it takes a NavigaTUM parent id and giving 'heilbronn' and 'garching' as examples; but 'query' and especially 'limit' (bounded 1-20) get no semantic treatment, leaving two of three parameters documented only by their JSON types.

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

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

The description opens with a specific verb+resource ('Search rooms, buildings, and sites on NavigaTUM') and even names the backing API endpoint, which clearly separates it from the course/lecture/person search siblings. It stops short of explicitly contrasting itself with the single-entity 'get_room' tool, so differentiation is inferred from the resource 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?

It gives useful scope guidance — the default search covers every campus including Heilbronn, and a campus parent id narrows results — which is the main decision an agent faces here. However, it never states when to reach for this versus a sibling such as get_room for detail lookup, and there is no exclusion or prerequisite guidance beyond the token note.

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