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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful detail that the result includes certification status, but otherwise discloses no deeper behavior such as authentication requirements or data scoping. 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 a single compact sentence with no filler, front-loading the operation and target resource. Every word contributes to the meaning, and it is appropriately sized for a simple read-only query 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?

The output schema and annotations cover return shape and safety, but the description leaves key invocation context undefined: how to select a child, what a null child means, and whether limit applies per child or overall. Given the low parameter documentation, an agent would need to guess to call the tool correctly.

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

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

Schema description coverage is 0% and the description does not mention either 'child' or 'limit'. The schema only provides names, types, and defaults, not meaning: it is unclear what 'child' should contain, what null means, or how 'limit' affects results. The description completely fails to compensate for the missing parameter 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 Hungarian description translates to 'Retrieval of absences and their certification status', naming a specific operation (lekérése/retrieval) and a specific resource (absences). It is unambiguous and clearly distinguishable from all sibling tools, none of which cover absences.

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

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

The description implies when to use the tool: whenever absence records or their certification status are needed. However, it provides no explicit guidance about prerequisites, such as whether a login or a selected child is required, and it does not mention alternatives or 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?

The annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, and the description is consistent with those, so there is no contradiction. It adds modest behavioral context by limiting the result set to announced assessments over a date range, but it does not disclose limit handling, child semantics, or date format.

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 clear sentence with no fluff, and the main object ('announced tests/assessments') is front-loaded. It could contain more detail, but the conciseness itself is appropriate for the tool's simplicity.

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 output schema and strong annotations cover return shape and safety, but the 0% parameter coverage and absence of usage guidance mean an agent does not have enough context to confidently supply 'child' or 'limit' or to choose this tool among its siblings. It is minimally viable only for a straightforward read.

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 has 0% per-parameter description coverage, so the description must compensate. It clarifies that start_date and end_date form a date range, but it leaves 'child' and 'limit' entirely unexplained, making half of the parameters ambiguous.

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 action ('lekérése' – retrieval) and a specific resource ('bejelentett dolgozatok és számonkérések' – announced tests and assessments), plus a date-range scope. This helps distinguish it from sibling tools like kreta_evaluations or kreta_announcements, though it does not explicitly name 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?

No guidance is given for when to use this tool instead of its siblings. There are no exclusions, no mention of related tools, and no conditions or prerequisites, so an agent is left to infer selection from the name and short description.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description merely repeats the retrieval nature without adding behavioral detail. It does not mention pagination, default limit behavior, open-world caveats, or authentication needs, so it adds no transparency 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 concise sentence with no filler, so it is efficient and easy to scan. It loses a point because it lacks any structural elements such as scoping notes or parameter hints that would make the one-liner more informative to an agent.

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

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

With an output schema present and strong annotations, the safety profile is covered, but the tool has two optional parameters whose meaning is entirely unexplained. The description gives no context for how to use 'child' or 'limit', so an agent cannot reliably construct a well-formed request beyond calling with all defaults.

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 does not explain either parameter. 'child' and 'limit' are left completely undefined, so an agent cannot know what 'child' refers to (e.g., a student identifier filter) or how the default limit of 100 behaves. The description was the only remaining source of parameter meaning and it provides none.

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

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

The description names a specific verb-like action ('lekérése' – retrieval) and a clear resource ('KRÉTA faliújság-elemei' – KRÉTA bulletin-board elements), which maps directly to the tool name. This resource is distinct from the sibling tools (evaluations, absences, timetable, etc.), so an agent can identify what this tool is for.

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 about when to choose this tool over the many sibling kreta_* tools. The description does not mention alternatives, exclusions, or any context condition (e.g., 'use kreta_announced_tests for tests'). An agent can only infer usage from the name.

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 readOnlyHint=true, idempotentHint=true, and destuctiveHint=false, and the description's 'lekérese' is consistent with a read operation. The description adds only the group-scope detail and does not disclose authentication, pagination, or other behavioral nuance, but the annotations lower the burden.

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, uncluttered sentence with no repeated information from the name or schema. Every word contributes to the action and scope, making it highly concise.

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?

Output schema and annotations cover return values and safety, so those do not need to be repeated. However, the definition lacks parameter semantics and usage guidance, leaving it minimally viable but incomplete for correct tool selection in ambiguous cases.

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

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

Input-schema description coverage is 0% and the description says nothing about 'child' or 'limit'. With only property names and defaults available, an agent receives no added meaning about what values are valid or how the parameters affect the request.

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 action and resource: retrieving class averages available to the student's groups. It is distinguishable from siblings like kreta_evaluations or kreta_class_groups by resource type, but it doesn't explicitly name or contrast those alternatives.

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

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

There is no guidance about when to use this tool versus the many sibling read tools. No conditions, exclusions, or alternative tool names are mentioned, so an agent must infer usage from the resource name alone.

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 provide a strong safety profile: readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description's 'retrieval' wording is consistent with these annotations, but it adds no extra behavioral context such as pagination, filtering effects, or what the 'child' parameter changes about the result.

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

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

The description is a single efficient sentence that communicates the core action and resource without redundancy. However, it is so terse that it leaves out essential parameter and usage context, which prevents a top score.

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

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

With an output schema present and two optional parameters, the tool is not highly complex, but the description lacks enough context for correct invocation: the meaning of 'child' is unexplained and no usage guidance distinguishes this from many similar kreta_* siblings. The annotations cover safety, but not semantics.

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 two parameters ('child' and 'limit') have no semantic descriptions in the schema. The description does not compensate: it never explains what 'child' represents, how 'limit' applies, or what values are acceptable. An agent cannot confidently determine parameter meaning from this definition.

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 ('lekérése' – retrieval) and a specific resource ('a tanuló osztályainak és csoportjainak' – the student's classes and groups), so an agent can tell what the tool does. It does not explicitly differentiate it from siblings like kreta_student_profile or kreta_class_averages, so it stops short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives in the sibling list, nor exclusions, prerequisites, or selection criteria. The only clue is the resource name itself, making usage implied rather than explicitly guided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the constraint that the UID must come from the list, but reveals no other behavioral traits such as error behavior or side effects.

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, front-loaded Hungarian sentence states the operation and the key constraint with no filler. 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 read-only detail lookup with an output schema and annotations covering safety, this is nearly complete. The main gap is the undocumented child parameter, which an agent may need to understand to call the tool correctly in a multi-child context.

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 explain parameters. It clarifies consulting_hour_uid as the UID obtained from the list, but does not explain the optional child parameter at all, leaving a meaningful 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 a specific verb ('lekérése' = retrieval) and resource ('fogadóóra részletei' = consulting hour details), and specifies the lookup key is the UID from the list. This clearly distinguishes it from sibling kreta_consulting_hours, which is the list 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?

It states the UID comes from the list, implicitly directing the agent to call kreta_consulting_hours first and then use this tool with the obtained UID. It does not explicitly name alternatives or exclusion conditions, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description is consistent with those annotations and adds the date-range constraint, but it does not disclose additional behavioral traits such as pagination, limit behavior, or how the listing is ordered.

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 concise sentence with no filler and is front-loaded with the core purpose. However, it is so terse that it omits useful parameter and usage detail that would help an agent invoke it correctly.

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 four parameters, 0% schema description coverage, and no parameter descriptions, the description is incomplete for safe invocation. The output schema likely covers return values, but the meaning of 'child', the role of 'limit', and the expected date format are absent, and no distinction from the detail sibling is provided.

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 of explaining parameters. It only clarifies that there is a date range, which maps to start_date and end_date, but leaves 'child' and 'limit' unexplained and does not specify date formats or accepted values.

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 retrieval action ('lekérése') on a specific resource ('Fogadóórák' consulting hours) scoped to a date range. It does not explicitly contrast with the sibling 'kreta_consulting_hour_detail', so differentiation is inferred 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?

No guidance is given on when to use this tool versus alternatives such as 'kreta_consulting_hour_detail'. There are no exclusions, prerequisites, or contextual cues beyond the implicit fact that it operates on a date range.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the specific subject (allocation and registration status) but does not disclose details like authorization requirements, data scope, or response behavior. It is consistent with 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 concise sentence that states the tool's function up front with no filler or repetition.

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

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

For a simple read-only tool with an output schema and a single optional parameter, the description adequately conveys the tool's purpose. However, the 'child' parameter is left completely unexplained, which is a clear gap for an agent deciding whether and how to supply 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 has one parameter, 'child', with no description, and schema_description_coverage is 0%. The description never mentions this parameter or explains what it controls (e.g., filtering by student), so it adds no meaning beyond the raw 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 uses a specific verb ('lekérése' = retrieval) and a concrete resource ('tárgyi eszköz kiosztási és regisztrációs állapota' = physical device allocation and registration status). This clearly identifies the tool's domain among many KRÉTA sibling tools, none of which target device/asset status.

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

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

The description implies the usage context: call when you need KRÉTA physical device allocation and registration status. It does not explicitly mention exclusions or alternatives, but among the sibling tools there is no competing device-status tool, so the intended use 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 already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description doesn't need to repeat that. It adds a useful scoping detail—'legfeljebb a megadott darabszámban' (at most the specified quantity)—but doesn't clarify ordering, filtering, or what 'other evaluations' encompasses. 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 a single, tight sentence with no filler. The core action and resource are front-loaded, and the limit constraint is included without redundancy. It earns its place as a concise, structured definition.

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?

Although an output schema exists and annotations are present, the description leaves key gaps: the meaning of 'child', what 'other evaluations' includes, and how to choose this tool over siblings. For a tool with two parameters and several sibling tools, this minimal text is 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?

With 0% schema description coverage, the description must compensate for the schema's silence, but it only partially does. The phrase 'legfeljebb a megadott darabszámban' hints at the 'limit' parameter's purpose, yet the 'child' parameter is entirely unexplained. An agent cannot determine what value to pass for 'child' from this 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 clearly identifies the action ('lekérése' = retrieval) and the resource ('Jegyek és más értékelések' = grades and other evaluations), so an agent can grasp the core purpose. It doesn't explicitly distinguish this from sibling tools like kreta_class_averages or kreta_announced_tests, but the resource wording is fairly specific.

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

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

No guidance is provided on when to use this tool instead of the many sibling evaluation-related tools. There are no stated exclusions, prerequisites, or comparison to alternatives like kreta_class_averages or kreta_announced_tests, so the agent must infer usage from the name and description alone.

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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds the account-level scoping ('bejelentkezett fiók') but does not explain how the optional 'child' parameter changes behavior, authentication needs, or any other operational traits.

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 Hungarian sentence with no filler. It states the operation and scope directly and earns every word, though it sacrifices explanatory richness for brevity.

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 all parameters are optional and an output schema exists, the description is minimally sufficient for a no-argument call. However, it is incomplete for correct advanced invocation because the 'child' parameter is unexplained, and there is no guidance on when to pick this tool over the sibling student-profile 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 schema has one parameter, 'child', with 0% description coverage, and the tool description does not mention it at all. The description therefore adds no meaning beyond the raw schema, leaving an agent unable to tell what 'child' is for or how it affects the retrieved profile.

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 operation ('lekérése' = retrieval) and a specific resource ('gondviselői adatlap' = guardian profile) scoped to the logged-in account. It clearly distinguishes this tool from the sibling 'kreta_student_profile' by specifying the guardian-facing profile rather than the student profile.

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

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

The description implies the tool should be used when the guardian profile of the logged-in account is needed, but it does not explicitly state when to use it versus alternatives, nor does it give any exclusions. Sibling tools like 'kreta_student_profile' exist, but no routing guidance is provided.

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 read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds the useful default-window behavior, but it does not disclose how limit or child affect results, which would add further transparency 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?

A single focused sentence leads with the verb and resource, then immediately provides the practical default date window. There is no filler or unnecessary repetition, and the structure is easy to parse quickly.

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

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

Given the rich annotations, output schema, and non-required parameters with defaults, the core retrieval behavior is reasonably complete for agent selection and default invocation. It is slightly held back by missing parameter guidance, especially around child and limit, but those are partly inferable from schema defaults.

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

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

The input schema has 0% description coverage, so the description must compensate, but it only clarifies the date-range concept and defaults. It does not explain the child parameter, how limit works, or the expected date string format, leaving significant meaning to 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?

The description states a clear action and resource: retrieving homework assignments for a date range, and it adds a concrete default window. It does not explicitly contrast with kreta_homework_detail, so it stops short of fully distinguishing itself from that closely related 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 implies this tool is appropriate for date-range homework retrieval and clarifies the default range, but it gives no explicit guidance about when to prefer kreta_homework_detail or when not to use this tool. Usage is mostly inferred from the wording rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description only restates the basic retrieval behavior and adds no extra behavioral traits such as auth requirements, rate limits, or output characteristics. 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?

The description is a single, compact sentence with no filler words. It front-loads the action and resource, then specifies the input source. 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?

The tool is simple, an output schema exists to describe the return value, and annotations cover the safety behavior. However, the child parameter is undocumented and the UID parameter is only vaguely referenced in natural language, leaving an agent to guess parameter semantics. It is adequate but not 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 0%, so the description must compensate. It mentions 'UID' in natural language, hinting at the homework_uid parameter, but it does not explicitly map to the parameter name, and the 'child' parameter is entirely unexplained. This is a notable gap in a two-parameter tool with no schema descriptions.

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 action ('lekérése' – retrieval) and resource ('házi feladat részletei' – homework details), and adds that it works from a UID obtained from a list, which differentiates it from the list-oriented kreta_homework sibling. However, it does not explicitly name the sibling tool, so it stops short of a 5.

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

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

The phrase 'a listából kapott UID alapján' gives clear usage context: this tool should be used after obtaining a UID from a homework list, implying the list sibling is for listing and this one for details. It does not mention alternatives or exclusions explicitly, but the context is strong enough.

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

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

The only behavioral claim is 'lekérése' (retrieval), which adds nothing beyond the readOnlyHint and idempotentHint annotations. It does not disclose pagination, filtering behavior, or the meaning of the optional child parameter.

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 short Hungarian sentence with no filler. The resource and action are front-loaded, making it 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?

For a simple read-only retrieval with annotations and an output schema, the core purpose is clear. However, the ambiguous child parameter and lack of any usage guidance leave meaningful gaps 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?

Schema description coverage is 0%, and the description does not explain either parameter. The names and defaults give some hint (limit=100 is fairly clear), but child is ambiguous and is not clarified 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?

A description specific verb+resource: 'lekérése' (retrieval) and 'előadások' (events/performances) of the Lázár Ervin Program. It is clearly distinct from all listed siblings, none of which target this program.

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 use when Lázár Ervin Program events are needed, but it gives no explicit when-to-use guidance, exclusions, or comparison with alternative tools. It remains at the 'implied usage' level.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond annotations: the OAuth 2.0 Authorization Code + PKCE flow and the aggregate per-child status behavior when 'child' is omitted.

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

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

The description is short, front-loaded with the core purpose, and the child-selection nuance is placed in a separate sentence. Every sentence adds distinct value with no redundancy.

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

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

For a login verification tool with a single optional parameter and an output schema, the description covers the main purpose, the protocol, and the parameter-dependent behavior. It could be slightly richer about when login verification is necessary, but it is otherwise sufficient.

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 compensate. It does by explaining that 'child' is optional: when omitted with multiple children configured, all are checked and per-child statuses are returned. This meaningfully clarifies the only parameter, though it does not specify the expected string format of 'child'.

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 action: login verification using OAuth 2.0 Authorization Code + PKCE. It also adds the distinctive child-selection behavior, which separates this login/status tool from the data-focused sibling tools.

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 conditional usage rule: if no 'child' is specified and multiple children are configured, all are checked and per-child status is returned. However, it does not explicitly discuss when to prefer this tool over alternatives or when not to use it.

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 read-only, idempotent, and non-destructive. The description adds a small amount of behavioral/scope context by specifying the note types, but it does not discuss auth, output format, or other behavioral traits. 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 a single, focused sentence that states the tool's core purpose without unnecessary words. It is front-loaded with the relevant action and resource, though it omits parameter details that would make it more informative.

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

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

While an output schema exists and annotations cover safety, the description fails to clarify the two optional parameters and offers no guidance about scope, filtering, or behavior. For an agent to invoke non-default calls correctly, important context is missing.

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

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

Schema description coverage is 0%, and the description does not explain the 'child' or 'limit' parameters at all. An agent cannot determine what 'child' refers to or how 'limit' affects results from the provided text, so the description adds no parameter-level meaning.

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 action ('lekérése' = retrieval) and the resource ('Tanári és intézményi feljegyzések' = teacher and institutional notes). It is specific enough to distinguish the tool from most siblings, though it does not explicitly contrast it with any 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 purpose implies the tool is for retrieving teacher/institutional notes, which gives some usage context. However, it provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions or prerequisites.

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 readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior. The description adds no behavioral detail beyond naming the data domain; it does not mention child-scoping, limit behavior, staleness, or other caveats. It aligns with the annotations, so there is no contradiction.

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

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

One short sentence with no filler, front-loading the core action and resource. It is concise, though the brevity comes at the cost of missing contextual detail that other dimensions penalize.

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 tool with no required arguments, an agent can call it with defaults, but a correct targeted call is underspecified: the meaning of 'child' is absent and there is no guidance on when to use it. The output schema and annotations cover returns and side effects, but not invocation semantics.

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 mentions neither 'child' nor 'limit'. The agent is left to guess what 'child' refers to and how limit applies to calendar results. The description provides zero compensation for the unannotated parameters.

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 concrete retrieval operation ('lekérése') for a specific resource: the school year's order and institutional days. The resource is distinct enough from siblings like kreta_timetable or kreta_week_schedule, though the description does not explicitly contrast it with them.

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 about when to prefer this tool over the many sibling calendar/timetable tools, nor any exclusions or preconditions. The description implies usage only through the read-only verb. Not misleading, but effectively no 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 cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description aligns with these. It adds the useful scope that the operation targets the logged-in student, but it discloses no extra behavioral details such as authentication requirements or error behavior. This is acceptable given the strong annotation coverage.

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 concise sentence with no filler or redundant phrasing. It front-loads the action and resource clearly, and 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 simple read-only profile-fetch tool with an output schema and strong annotations, the description is nearly sufficient. The main gap is the completely unexplained 'child' parameter, which introduces ambiguity about whether the tool can retrieve another student's profile or whether it always targets the logged-in user.

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

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

The only parameter, 'child', has zero schema description coverage, and the description does not mention it at all. An agent is left without any explanation of what 'child' means, whether it is relevant for a logged-in student, or when it should be provided.

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 the specific verb 'lekérése' (retrieval) and resource 'a bejelentkezett tanuló adatlapja' (the logged-in student's profile). This clearly differentiates it from the sibling kreta_guardian_profile, though it does not explicitly name any alternative.

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 'bejelentkezett tanuló' implies the tool is for fetching the currently logged-in student's own profile, giving a clear general usage context. However, it provides no explicit guidance about when to prefer this over sibling tools such as kreta_guardian_profile, and mentions no exclusions or alternatives.

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 tool read-only, idempotent, and non-destructive, so the description only needs to add behavioral context. It adds the default ±7-day range and the date format, which is useful, but it does not explain how limit or child affect the request or how the date bounds are resolved when only one date is provided.

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

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

The description is a single compact sentence that leads with the purpose and uses a parenthetical for the default behavior. It contains no filler or redundancy, and the key scoping information is front-loaded.

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 output schema covers return values and annotations cover the safety profile, so those do not need to be repeated. However, the description omits guidance on child and limit parameters, so an agent cannot fully understand all inputs from the description 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?

With 0% schema description coverage, the description must compensate by explaining parameters, but it only addresses the date-range semantics. The child and limit parameters are not described, leaving meaningful gaps even though their names and defaults provide some self-evident meaning.

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 action (retrieval) and resource (timetable) with a date-range scope, and specifies the expected YYYY-MM-DD format and default ±7 days. It is distinct enough from unrelated siblings, though it does not explicitly differentiate itself from close siblings like kreta_timetable_item or kreta_week_schedule.

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

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

The description provides clear context: use this tool to fetch the timetable for a date range, with a default range of ±7 days. It does not name alternatives or give explicit when-not-to-use guidance, but the stated purpose gives sufficient context for basic 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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds only that the UID originates from a list call and the output schema covers return values. It adds modest context but no deeper behavioral disclosure (auth requirements, error behavior), which is acceptable given the strong 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?

A single Hungarian sentence that states the purpose without redundancy, with the key constraint (UID from the list) included. It is appropriately sized and front-loaded, though it is also the only substantive content in the definition.

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 lookup tool with an output schema and comprehensive annotations, the definition is close to adequate. The main gaps are the unexplained 'child' parameter and routing to sibling kreta_timetable being implicit rather than explicit, which prevents full completeness.

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 for parameter meaning. It does clarify that lesson_uid is a UID obtained from a prior list call, adding value beyond the bare 'string' type in the schema. However, the optional 'child' parameter (string or null, default null) is entirely unexplained in both the schema and the description, leaving real ambiguity.

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 ('lekérése' – retrieval), a specific resource (órarendi elem részletei – timetable item details), and the lookup mechanism (UID from the list). This implicitly differentiates it from sibling kreta_timetable, which is the source of the list. It is clear but does not explicitly name the sibling, so it stops short of a 5.

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

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

The phrase 'a listából kapott UID alapján' (based on the UID received from the list) implies a two-step flow: first call kreta_timetable to get the list of UIDs, then call this tool for item details. However, no explicit when-to-use versus alternatives guidance or exclusions are given, so the usage is implied rather than stated.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description does not need to cover basic safety. It confirms a read-only retrieval and adds the 'institutional weekly' scope, but gives no further behavioral detail such as date-range handling or pagination. There is no contradiction with 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, compact sentence with no filler and front-loads the object and action. It is concise and well-structured, though the sparse content is a completeness issue rather than a conciseness issue.

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 sibling ambiguity and four undocumented parameters, the description is too thin to fully support correct invocation. It does not explain how this differs from kreta_timetable, what child means, or how the date range behaves. The output schema and annotations help, but the tool-set context is still under-specified.

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 is completely silent about child, limit, start_date, and end_date. The description does not compensate for the missing schema descriptions, so an agent must guess the meaning and expected formats of the parameters.

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

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

The description identifies a specific operation — retrieving the institutional weekly timetable — with a clear verb (lekérése) and a specific resource (intézményi heti órarendi beosztás). It is clear, but it does not explicitly distinguish it from siblings like kreta_timetable, so it lacks sibling differentiation.

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

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

No guidance is given on when to use this tool versus kreta_timetable or kreta_timetable_item. The phrase 'institutional weekly timetable' weakly implies a use case, but there are no explicit alternatives, exclusions, or conditions.

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