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

No annotations are given, so the description carries the full burden. It clearly implies a read-only operation ('Show'), but it does not explicitly disclose that it does not modify state, nor does it mention any requirements or edge cases (e.g., what happens if no subdomain is logged in). For a simple status tool this is adequate, but not rich.

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

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

The description is a single, concise sentence that conveys the full purpose without any filler. It is front-loaded and economical, earning 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?

For a simple, parameterless read tool with no output schema, the description is mostly complete. It states exactly what the tool reports. The only minor gap is not describing the format of the returned status, but this is not critical for invoking 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?

The tool has zero parameters, and the schema is trivially complete. Per the baseline guidance for 0-param tools, a score of 4 is appropriate; the description correctly omits parameter details because there are 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 states a specific verb ('Show') and a clear resource ('login status for all configured subdomains and the active one'). It distinguishes itself from the many login-related sibling tools (login, login_all, etc.) by being the only status check among them. The scope is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives. The description merely states what it does, without mentioning that it should be used before login actions or to verify session state. Since the siblings are all mutation/login tools, some context on when to query status would be helpful, but none 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?

With no annotations, the description must disclose behavioral traits, and it fails to do so. 'Order/choose' implies a mutating action, but the description does not state whether a prior meal selection is overwritten, whether the order can be reversed, what side effects occur, or what happens if the chosen number is invalid.

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 and front-loaded: one sentence for purpose, one for parameter shorthand. No filler words, but the second sentence is very terse and could have been clearer with proper formatting or a full 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 mutating action with no annotations and no output schema, this description leaves important gaps: no auth requirements, no date format guidance, no mention of what the API returns, and no warning about irreversible side effects. More context is needed to call it confidently.

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. It does add meaning for meal_type ('snack'|'lunch'|'afternoon_snack') and number (1-based among chooseable menus), but date_str and subdomain remain semantically undefined despite being properties in the schema.

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

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

The description states a specific action and resource: 'order/choose a meal for a date', and it valuably defines meal_type allowed values and the numbering scheme. It does not explicitly contrast with siblings like get_meals, sign_off_meal, or rate_meal, but the verb and the meal-specific focus make the primary purpose 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?

No explicit when-to-use or when-not-to-use guidance is provided. The phrase 'among the chooseable menus' vaguely implies a prerequisite step, but the description never tells an agent that they should first query available meals (e.g., via get_meals), nor does it mention prerequisites such as authentication or active sessions.

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

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

With no annotations, the description carries the behavioral burden. It importantly discloses the broad effect of omitting a subdomain: clearing the cache for ALL schools, which is a critical side-effect warning. It does not elaborate on permissions or exact cache mechanics, but the provided context is solid.

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

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

The description is two sentences with no filler. The first sentence states the action, the second gives usage guidance and scope behavior. Everything earns its place.

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

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

For a simple one-parameter cache-clearing tool with no output schema, this description is nearly complete. It covers why to call, when, and the global scope default. A minor gap is that it does not specify the format for the subdomain, but this is low-risk given the optional and scope-limiting nature of the parameter.

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 simply declares 'subdomain' with a default of null and no description. The description compensates by explaining the scoping effect: without a subdomain, the cache for all schools is cleared, implying that providing one limits the operation. It does not document the expected subdomain format, but it adds meaningful semantics beyond the schema.

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

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

The description uses a specific verb phrase 'Force refresh' targeting 'cached student data', which clearly identifies a cache-invalidation action. It distinguishes itself from sibling data-fetching tools like scan_students and find_student by naming them as sources of stale results.

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

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

Explicitly states when to call the tool: after students are added/removed from a school, or when scan_students/find_student return stale results. This gives concrete trigger conditions and names the relevant sibling tools, leaving little ambiguity about the intended use case.

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

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

No annotations are provided, so the description carries the full burden. It mentions 'active session' and returns status code and body, but doesn't disclose that this is an advanced tool that can modify data (since it allows POST), potential security risks, or that it depends on prior login. The mention of 'active session' is some context, but insufficient for a raw request tool.

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

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

The description is concise and front-loaded with the core purpose. It provides method guidance but still leaves gaps. Overall, it's efficient with two sentences, though the second sentence could be integrated. It's not overly verbose.

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

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

Given the tool's complexity (5 params, raw request, no annotations, no output schema), the description is incomplete. An agent needs to know how to construct the url, what the subdomain parameter does, and given the many sibling getters, when to use this. The description only partially fulfills that.

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

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

Schema coverage is 0%, so description must compensate. It mentions 'method: 'GET'|'POST'' which adds clarity to the method parameter, and implicitly that data and headers might be used for POST, but doesn't explain the subdomain parameter, which is non-trivial and defaults to null. It doesn't clarify the url format or the data/headers string formats.

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

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

The description clearly states the tool sends a raw request to the Edupage server and returns status code and body text, which is specific. However, it doesn't explicitly differentiate from siblings, though siblings are mostly specific getters and this is the raw request tool, so differentiation is implicit.

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 explicit guidance on when to use this tool versus alternatives. It says 'send a raw request' but doesn't explain when an agent should prefer this over the many specialized getter tools, nor does it mention any prerequisites like being logged in (though 'active session' is mentioned, it doesn't say login is required).

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

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: searches all logged-in schools without a subdomain, returns one result per school, and provides match confidence tiers (1-4). It also hints at an authentication requirement by mentioning 'logged-in schools.' It doesn't detail error handling or exact return fields, but the tiered matching and multi-school behavior are well explained. This is more transparent than many read-only tools.

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 compact paragraph where every sentence adds value. It opens with the core purpose, then explains the scoping behavior, then the output format with confidence tiers, and ends with a practical chaining tip. No fluff or redundancy—it's front-loaded and well-structured.

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

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

Given there's no output schema and no annotations, the description covers the essential runtime behavior: search scope, result cardinality, match tiers, and how to leverage results with another tool. It could be more specific about the exact fields returned in the student info (beyond student_id), but it provides sufficient detail for an agent to understand what to expect. The chaining hint also adds practical context. Overall, it's complete enough 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%, so the description must explain both parameters. It explains 'name' as first/last/full name and 'subdomain' via the contrast: 'Without a subdomain, searches ALL logged-in schools' (implying with subdomain it scopes to a specific school). It also clarifies the output includes student_id, which is used for chaining. The description fully compensates for the lack of schema descriptions, giving operational meaning to each parameter.

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

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

The description states a specific action: 'Look up a student by first/last/full name using tiered matching.' It clearly distinguishes from siblings like get_students (which presumably list all) by focusing on name-based lookup with matching tiers. This is a specific verb plus resource, and the tiered matching detail differentiates it from other student-related 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 provides clear context: 'Without a subdomain, searches ALL logged-in schools and returns one result per school.' It also gives a chaining recommendation: 'Use student_id from results with get_student_timetable for unambiguous lookups.' This implies when to use the tool and how to follow up, though it doesn't explicitly compare to alternatives like get_students or get_all_students. It's clear enough for an agent to decide when to invoke this instead of a bulk listing tool.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure. It implies a read-only operation, but it does not mention whether the tool is safe, whether it modifies anything, whether pagination is involved, or how it handles missing absence data.

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 one compact sentence with no filler, and the main resource is front-loaded. It is appropriately short, though the brevity sacrifices some needed detail that other dimensions are forced to 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 tool with no output schema, no annotations, and an undocumented parameter, the description is incomplete. It explains the basic purpose but omits the meaning of 'subdomain', how the absence records are scoped, and any behavioral or output details an agent would need to invoke it confidently.

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 a single 'subdomain' parameter with no description, and the tool description never mentions it. With 0% schema description coverage, the description needed to explain what subdomain means and why it is needed, but it does not.

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 resource ('absence records') and a source ('timeline notifications'), so the purpose is reasonably clear. It does not, however, explicitly differentiate itself from sibling tools like get_notifications or get_notification_history.

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 about when to use this tool versus alternatives, prerequisites, or authentication context. The description only states what it returns, which forces the agent to infer when it is the correct choice.

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

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

No annotations are present, so the description bears full disclosure responsibility. It only discloses that the result is a 'short list', which hints at limited fields but does not state auth requirements, subdomain behavior, or whether data is cached. Minimal value beyond what the name implies.

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; the core purpose comes first. Very efficient, though arguably too sparse to be complete.

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

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

The tool has one undocumented parameter and no output schema, and there are several sibling student-listing tools. The description does not explain subdomain, result shape, or selection criteria, so an agent cannot confidently invoke it correctly.

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

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

The only parameter, subdomain, has no schema description and is not mentioned in the description. At 0% schema description coverage, the description should explain the parameter but does not, leaving the agent without 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 identifies a specific action and resource: retrieving a short list of all students in the school. It is distinguishable at a high level, but it does not differentiate from sibling tools like get_students, get_my_students, or find_student, 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?

No information is provided about when to prefer this tool over alternatives such as get_students or get_my_students, and there are no exclusions or prerequisites. The agent must infer usage from the 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?

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions the tool is read-only (get) and returns data from the timeline, but it does not disclose any details about response format, pagination, or potential variations in behavior. For a tool with no annotations, this is a significant gap.

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

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

The description is a single, concise sentence that front-loads the purpose without any extraneous content. It is efficiently structured and covers the core action.

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

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

The tool is relatively simple with one optional parameter and no output schema, but the description does not account for the subdomain parameter or any contextual details like date filters. It is complete for the basic action but missing key context for effective use, especially given the lack of annotations and 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?

The schema has one parameter 'subdomain' with a default of null, and description coverage is 0%. The description does not explain the purpose of the 'subdomain' parameter. However, since the tool is part of a context that likely involves subdomains (as seen in sibling tools like login), the agent can infer its meaning. The lack of explicit explanation sets a baseline of 3, as the description does not add beyond the schema.

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

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

The description clearly states that the tool retrieves all assignments including homework, tests, exams, and projects from the timeline, which is a specific verb-resource combination. It distinguishes it from the sibling tool 'get_homework' by mentioning a broader scope, although it doesn't explicitly name the 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 usage: it is for getting assignments from the timeline)Skip. However, it does not provide explicit guidance on when to prefer this over the closely related 'get_homework' tool, nor does it specify any conditions or alternatives. This is a minimal acceptable level for a simple retrieval tool.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It does not mention authentication requirements, data scope beyond 'school,' pagination, return shape, or whether the operation is strictly read-only. The verb 'get' implies a read, but the description adds no meaningful behavioral context.

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

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

The description is a single front-loaded sentence with no filler or repetition. It is concise and easy to parse; the trade-off is the lack of substance, but that is penalized in the other dimensions.

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 there is no output schema and no annotations, this one-sentence description leaves important context undeclared: the subdomain parameter is undocumented, and no usage guidance is provided. An agent can guess that it lists classes, but cannot confidently determine how the subdomain parameter should be used or when this tool is the correct choice.

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, subdomain, with no schema description (0% coverage). The description does not mention it at all, so the agent receives no explanation of what subdomain means, whether it is required, or how it relates to 'the school.'

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

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

The description uses a specific verb and resource: 'Get all classes in the school.' This is enough to distinguish it from siblings like get_students or get_classrooms, though it does not explicitly disambiguate 'classes' from timetable-related concepts such as get_periods or get_subjects.

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 about when to call this tool versus get_periods, get_subjects, or get_timetable, and no alternatives or exclusions are mentioned. The only inference is that the agent should use it when it wants 'all classes,' which is minimal and indirect.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read operation ('Get') but gives no details such as authentication requirements, response format, pagination, or consequences. It also does not mention whether the 'subdomain' parameter is required or optional, or what happens if omitted. For a tool with zero annotation support, this is insufficient.

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 short sentence, which is concise, but it achieves brevity at the expense of essential information. It is front-loaded with the purpose but omits any details about usage or parameters. While it is not bloated, its extreme brevity makes it under-specified rather than appropriately 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?

Given the tool has one parameter with no schema documentation, no output schema, and no annotations, the description is wholly inadequate. It does not explain the role of the parameter, the expected return, or any operational context. An agent attempting to use this tool correctly would have to guess or rely on external knowledge. The description provides almost no value beyond stating the basic action.

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%, meaning the description must explain the 'subdomain' parameter, but it does not. The description makes no mention of any parameters, leaving the agent with no idea what 'subdomain' means, its purpose, or its format. This is a critical gap for a tool with one parameter.

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

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

The description 'Get all classrooms in the school' clearly states the verb (get) and resource (classrooms in the school), and the word 'all' indicates a comprehensive retrieval. It distinguishes itself from sibling tools like get_classes or get_students by focusing on classrooms specifically. However, it does not specify any nuance beyond that, but the core purpose is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives. Siblings like get_classes, get_students, or get_subjects might be relevant for similar retrieval needs, but the description doesn't mention any selection criteria, prerequisites, or exclusions. An agent is left to guess whether this should be called first or in what context.

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

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

No annotations exist, so the description carries the full burden and mostly succeeds: it discloses the discovery-first default behavior, the full=True escape hatch, and the section-isolation contract (a failed section returns {'ok': false, 'error': ...} without failing the report). It does not state auth/permission requirements or rate limits, leaving a small gap.

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

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

Front-loaded with the core purpose and the section list, then bulleted conditions for each parameter mode; every bullet carries distinct routing information. The section enumeration is long but earns its place by telling the agent exactly what is aggregated.

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 annotations and no output schema, the description does the necessary work: it explains return semantics (per-school child index vs full report vs logged-in account report) and the degradation behavior on section failure. It stops short of describing the concrete report schema, but given the isolation contract that is a minor omission.

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, and it does for four of five params: date_str (default today), name/student_id (student selection, cross-school unless subdomain scopes it), subdomain (scoping), and full (full report per child instead of index). Only minor ambiguity remains, e.g. the exact name vs student_id precedence.

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 composite action (one-call daily school report for a date) and enumerates the exact sections it aggregates (timetable, substitutions, grades, meals, etc.). It explicitly distinguishes itself from the many sibling section tools by saying it 'composes the individual section tools' so the agent needn't fire 8-10 calls.

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?

Gives explicit branching conditions: with name/student_id it reports for that student; omitted for a parent it returns a lightweight per-school child index (discovery-first); omitted for student/teacher it uses the logged-in account; full=True builds the full report for every child. This is precisely the when-to-use/when-not guidance an agent needs against siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it returns a list of grades, without mentioning side effects, authentication requirements, or data scope. It does not state whether it requires a pre-existing session or if it affects any state. This is a significant gap for a tool that likely requires login but does not say so.

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 extremely concise: one sentence with an optional filter clause and a brief note on the return content. There is no filler or redundant wording. It achieves clarity with minimal length, which is ideal for efficient agent parsing.

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 the description covers the basic purpose and optional filters, it lacks essential context for a robust tool: no output schema, no mention of error conditions, no authentication requirements (though sibling login tools suggest auth may be needed), and no note on whether the data is scoped to a particular user or session. For a tool that likely requires login and returns sensitive data, this is incomplete.

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

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

The description adds valuable information for two of the three parameters (year and term), including acceptable term values ('FIRST' or 'SECOND'), which is not in the schema. However, the third parameter, 'subdomain', is entirely omitted from the description, leaving it undocumented. Since schema coverage is 0% and there is no description field, the tool relies on the description text, which is incomplete.

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

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

The description clearly states the verb 'Get' and the resource 'grades', and mentions it returns a list with subject, teacher, percent. It is distinct from sibling tools like get_homework or get_periods by focusing on grades. However, it does not explicitly contrast itself with other grade-related tools, so it doesn't fully achieve the top score for 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?

The description provides clear context on when to use it (when you need grades) and mentions optional filters for year and term. It does not explicitly state when not to use it or point to an alternative, but the optional filter syntax gives operational guidance. Since it is a straightforward read operation, this is clear 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?

With no annotations, the description responsibly identifies a key behavioral constraint: results come from 'recent timeline notifications,' not a general assignments store. However, it does not clarify the recency window, authentication needs, or what happens when no matching notifications exist.

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 sentence with no filler; the verb, object, and source are stated directly. The source qualifier 'recent timeline notifications' earns its place by narrowing the tool's behavior.

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 tool with no output schema and no annotations, a one-line description is thin: it omits the meaning of the subdomain parameter and any expectations about return data. An agent could select it, but would have to guess about input and result 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?

The single parameter 'subdomain' has zero schema documentation and the description never mentions it. The name is somewhat self-explanatory, but the description adds no meaning about optionality, format, or how it affects 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?

States a clear action and object: 'Get homework assignments' with a specific source, 'recent timeline notifications.' This separates it from broader siblings like get_assignments and get_notifications, though the distinction is implicit rather than explicit.

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

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

No when-to-use guidance or alternatives are mentioned. The phrase 'recent timeline notifications' implies a context, but the description never tells an agent when to choose this over get_assignments or get_notifications.

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

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

With no annotations, the description carries the behavioral burden. It discloses the fallback behavior between the personal endpoint and public widget, default returned meals, and the constraint that extra meals are only available through the public widget. Authentication and return format are not covered, but the read-only nature is clear.

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

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

Three sentences cover the defaults, endpoint fallback, and parameter behavior without filler or redundant schema repetition. The most important usage 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 description provides the key invocation knowledge: default date, returned meal categories, optional expansion flags, and fallback endpoint behavior. It omits return shape and auth preconditions, but those are less critical given the fully optional parameter set.

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

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

The schema provides no parameter descriptions, and the description compensates well for date_str and include_breakfast/include_dinner. However, subdomain is never explained and the expected date format is left unspecified, so the coverage is good but incomplete.

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 concrete read operation: get the meal menu for a date, and lists the meal categories and default date. It also distinguishes itself from action-focused sibling tools like choose_meal, sign_off_meal, and rate_meal.

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

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

It explains default usage, how to extend with include_breakfast/include_dinner, and when the public fallback endpoint is used. It does not explicitly cross-reference sibling tools or state when not to use them, but the usage 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?

With no annotations, the description must carry the behavioral burden. It discloses the default date behavior but does not explain what 'missing' means operationally, the return format, potential side effects (though 'get' implies read-only, it is not stated), or any permission requirements. This is minimal disclosure.

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 short sentence, which is concise, but it omits critical details. It does not structure information about parameters, usage context, or output; it is under-specified rather than efficiently complete.

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 tool with two parameters, no annotations, and no output schema, the description is severely incomplete. It fails to define 'missing', provide parameter details, describe expected output, or mention any preconditions like login. An agent would be unable to reliably invoke this 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?

Neither parameter is described in the schema or description. date_str can be inferred as the date to check, with a default of today, but its format is unspecified. subdomain is entirely unclear, likely the school subdomain, but not explained. With 0% schema coverage and no textual explanation, agents cannot correctly supply 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 clearly states the action: retrieving teachers missing on a date, with a default of today. It distinguishes itself from sibling get_teachers through the 'missing' qualifier, making the purpose specific. However, it does not explicitly contrast with other date-related tools like get_absences, so it's clear but not fully differentiated.

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 versus alternatives such as get_teachers or get_absences. There is no mention of preconditions like authentication or data context, leaving an agent without basis to choose it over other tools.

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

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

The description discloses that data is cached ('Uses cached data') and that parent data is parsed from the school homepage, which is useful behavioral context. It also states the output fields (person_id, name, class_id). With no annotations provided, the description carries the burden, and it does a good job of revealing the caching behavior and the parsing source.

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

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

Three sentences with no filler. The first sentence states the core behavior, the second adds the caching detail, and the third lists the return fields and related tools. Every sentence earns its place.

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

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

For a simple one-parameter tool with no output schema, the description covers the main behavioral aspects: what it returns, who sees what, caching, and how the output can be used downstream. It could mention the subdomain parameter explicitly, but the overall context is sufficient for an agent to invoke it correctly.

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

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

The only parameter is subdomain, and the schema description coverage is 0%, so the description does not explain what subdomain means or how to fill it. However, the tool name and context imply it is the school subdomain, and the description's focus on account-visible students is more important. The description does not add parameter-level detail, so a baseline 3 is appropriate.

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

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

The description states a specific verb ('Get'), a specific resource ('students visible to the logged-in account'), and distinguishes between parent and student account behavior. It also names sibling tools (switch_to_student, get_student_timetable) that the returned data is usable with, which helps differentiate it from get_students/get_all_students.

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 explains when to use it: for parent accounts it returns linked children, for student accounts it returns classmates. It does not explicitly say when NOT to use it or name alternatives like get_students/get_all_students, but the account-type context is clear enough for an agent to select it appropriately.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions the default 'today' behavior and implies read-only via 'Get', but does not state authentication requirements, potential rate limits, error behavior, or any side effects. The disclosure is minimal and insufficient for a full understanding.

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 filler. It front-loads the purpose and includes key details (date format and default) efficiently, 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?

With two parameters, no output schema, and no annotations, the description must provide enough context for a correct call. It misses the subdomain parameter, return format, and any prerequisites. The description is too sparse to be adequate for a tool in this 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?

The schema has 0% description coverage, so the description must explain both parameters. It explains 'date_str' with format and default, but completely omits 'subdomain'. The description adds value for one parameter but fails to cover the other, leaving a significant 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 clearly states a specific verb ('Get'), resource ('timetable'), and scope ('for the logged-in user'), and specifies the date format with a default. This distinguishes it from sibling tools like get_student_timetable or get_timetable, which imply other scopes, without needing to read their schemas.

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

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

The description provides context that this is the logged-in user's timetable, implying it is for the current session, but it does not explicitly mention when to use this over alternatives like get_student_timetable or get_timetable, nor any exclusions. The guidance is implied but not 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?

No annotations accompany this tool, so the description carries the full burden of disclosure. It only states that the tool retrieves news; it does not describe pagination, ordering, authentication requirements, or the absence of side effects for this read operation.

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

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

The description is a single front-loaded sentence with no filler words. It is concise, though the brevity comes at the cost of important contextual details.

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

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

For a tool with no output schema and no annotations, the description is too thin. An agent cannot tell what 'news' includes, how the optional subdomain parameter affects the request, or how the result relates to the sibling notification tools.

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 only parameter, subdomain, is not mentioned in the description. The description does not compensate for the schema's silence, leaving an agent to guess what the parameter means and whether it is needed.

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 (get) and resource (school news) and locates the source in timeline notifications. It is not a tautology, but it does not explicitly differentiate from the sibling get_notifications tool.

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 rather than get_notifications, get_notification_history, or get_upcoming_events. The phrase 'from the timeline notifications' hints at context, but no alternatives or exclusions are 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It makes the read-only nature clear via 'Get' and specifies the output contents, plus the ISO/default-now behavior. However, it omits timezone handling, auth expectations, return shape, and edge cases like no next ringing.

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 entire description is a single compact sentence that front-loads the main action and output. Every phrase earns its place and there is no redundant or filler content.

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

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

For a simple lookup tool this is minimally adequate, but there are notable gaps: subdomain is not explained, the exact return format is absent, and no output schema or annotations exist to fill those holes. An agent would still have to guess about timezone and failure 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 must compensate. It does add meaning for date_time_str by specifying ISO format and default-now behavior, but it completely ignores the subdomain parameter, leaving its role and possible values unexplained.

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 ('Get') and names the exact resource ('next ringing') plus the returned fields ('type (break/lesson) and time'). This clearly distinguishes it from sibling tools like get_periods or get_timetable.

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 'for a given datetime (ISO, default now)' implies the main use case, but the description gives no explicit when-to-use or when-not-to-use guidance and names no alternatives. With many get_* siblings, a direct comparison would help.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states this is a read operation (get) and indicates the output (timetable grouped by weekday), which is transparent for a simple read-only tool. However, it does not disclose any side effects, auth requirements, or what happens if the user is not logged in. It is adequate but not rich.

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

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

The description is a single sentence that manages to convey the object, scope, and grouping without any redundant words. It is concise, front-loaded, and uses 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?

The description provides enough context for a simple read-only timetable query, mentioning the specific days and grouping. Yet it omits any explanation of the subdomain parameter and does not mention authentication state or possible edge cases (e.g., holidays). Given the tool's simplicity and the lack of an output schema, the description is acceptable but leaves some gaps.

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

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

The schema has one parameter (subdomain) with 0% description coverage. The description does not mention subdomain, leaving the agent to guess whether it is required, what values it accepts, or its purpose. For a read-only tool with a single param, this is a clear gap that the description fails to compensate for.

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 (get), the resource (Mon-Fri timetable for next week), the user scope (logged-in user), and the output grouping (by weekday). It specfically differentiates itself from sibling tools like get_timetable_range or get_my_timetable by naming the exact time window and days.

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 versus alternatives. It does not mention conditions like 'use get_timetable_range for a custom date range' or clarify whether it requires prior authentication. The only implied context is that it is for the next week's timetable, but no explicit when-to-use or when-not-to-use instruction 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only hints at the inclusion of older notifications ('including older ones') but does not clarify auth requirements, rate limits, pagination, or return format. There is no explicit statement that it is read-only, though the verb 'Get' implies it. The description adds minimal behavioral context beyond the obvious.

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 front-loads the key constraint ('since a date') and includes the important nuance of 'including older ones'. There is minimal wasted text, and the structure is efficient.

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 minimal schema (2 params, no enums, no output schema) and the existence of a highly related sibling (get_notifications), the description is incomplete. It does not explain how 'timeline notifications' differ from regular notifications, what 'including older ones' implies about ordering or limits, or when this tool is the appropriate choice. An agent would likely need additional information to use it correctly in 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?

The schema has 0% description coverage, so the description must compensate. It does provide the date format (YYYY-MM-DD) for the required date_from parameter, which is helpful. However, it completely ignores the optional subdomain parameter, leaving its meaning and usage undocumented. With two parameters and only one partially described, this is a significant 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 clearly states the action (Get) and the resource (timeline notifications) with a specific date constraint, providing a clear purpose. However, it does not explicitly differentiate this from the sibling tool get_notifications, which likely serves a similar function, so it falls 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 description provides no guidance on when to use this tool versus alternatives. It does not mention get_notifications or any other sibling, nor does it explain any conditions that would make this tool preferable. There is no context about whether this is for historical retrieval vs. current notifications.

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

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

With no annotations, the description carries the full behavioral burden. It implies a read operation ('Get') and adds category context, but it does not disclose auth prerequisites, whether results are paginated or filtered, or what happens when there are no notifications.

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 one tight sentence with the action front-loaded and no filler words. It could add useful context, but its existing text is appropriately 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?

For a tool with no annotations and no output schema, the description is thin: it omits auth context, parameter semantics, and meaningful differentiation from get_notification_history. The category examples are helpful but not enough to fully specify correct invocation in 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% and the description never mentions the subdomain parameter or its meaning. The input schema only provides the name and default, so the agent receives no semantic information about how to fill it.

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

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

The description states a clear verb and resource: 'Get the list of available timeline notifications' and provides category examples (homework, tests, messages, grades, events). It is unambiguous about what the tool returns, but it does not explicitly distinguish itself from the sibling get_notification_history.

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 such as get_notification_history or other notification-related getters. The description implies current timeline notifications but never states exclusions or 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?

No annotations are provided, so the description must convey behavior. It clearly states it reads schedule data, which is non-destructive, and notes reliance on 'logged-in data' indicating the need for prior authentication. However, it does not disclose any potential side effects (e.g., caching) or clarify whether it returns the schedule for the current day only or a specific date range. Given the lack of annotations, more detail on the output format or behavior would be beneficial.

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 that front-loads the core purpose. It is concise and to the point with no redundant information. Perfectly sized for the task.

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

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

The tool is simple with one parameter and no output schema, so the description is mostly sufficient. However, it omits specifics like whether the schedule is for the current day or a chosen date, and it does not mention return structure or any caveats about authentication. For a tool with low complexityholistic, the completeness is adequate but not stellar.

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 should compensate. It explains that the tool uses logged-in data, implying the subdomain parameter is optional or used for context. However, it does not explicitly explain what 'subdomain' means or how it affects the request于点. The description provides some context, but not enough to fully compensate for the lack of 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 clearly states the tool's purpose: to retrieve the bell schedule (periods with start/end times) from the logged-in data. This is specific enough to distinguish it from related tools like get_my_timetable or get_timetable. However, it does not explicitly differentiate it from potential alternatives like get_timetable_range, which might also return schedule information, so it loses one point.

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

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

The description provides no guidance on when to use this tool versus other schedule-related tools. It explains that it gets the schedule from logged-in data, which implies it must be used after login, but it does not explicitly state that a login is required or that this tool is the go-to for the current user's schedule. No alternatives or exclusions are mentioned.

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

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

With no annotations, the description carries the full burden and it does well: it explicitly lists the returned fields (subdomain, login state, role, 2FA pending status, user id) and the source of the data. The 'List' verb implies a read-only operation, and the description does not hide any major behavioral trait.

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

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

The description is two sentences with zero filler. The primary action and scope are front-loaded ('List all schools the server is logged into'), and the follow-up sentence enumerates the return fields efficiently. Every sentence earns its place.

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

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

For a zero-parameter, no-output-schema tool, the description tells the agent exactly what it will receive and where that state comes from. Nothing critical is missing to invoke the tool correctly or to interpret its result.

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

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

The tool has zero parameters, so the schema is trivially complete. The description adds value by explaining what the operation returns, which is the relevant semantic content for a parameterless getter. A baseline of 4 applies because there are no parameters to document.

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

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

The description states a specific verb ('List') and a clearly bounded resource ('all schools the server is logged into'), and it names the data source ('from auto-discovery or login_all'). This distinguishes it from sibling tools like auth_status or user_id by focusing on the multi-school session scope.

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 by explaining when this data is relevant (after auto-discovery or login_all), implying the agent should call this to inspect the current school-session state. It does not explicitly name alternatives or exclusions, but for a zero-parameter listing tool the usage situation is fairly obvious from the phrasing.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says "Get," which is already implied by the name, and does not mention authentication, permissions, what "class" means in this system, or whether results are paginated/limited. This is a sparse description for a tool operating in an authenticated context, leaving an agent to guess at side effects or constraints.

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

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

The description is a single, front-loaded sentence with no wasted words. It communicates the core action efficiently. However, it is so terse that it omits crucial details, which is a structural balance issue, so it does not earn a 5.

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

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

Given the tool has one undocumented parameter and no output schema, the description should compensate by clarifying the meaning of subdomain and the scope of "class." It does neither. An agent cannot confidently invoke this tool without inferring that subdomain might be the school's domain. This is a major gap for an otherwise simple tool.

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

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

The input schema contains a single parameter, subdomain, with default null and no documentation. Schema description coverage is 0%, so the description must compensate, but it does not mention subdomain at all. An agent has no idea what to pass or whether it matters, making this description unhelpful for parameter usage.

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

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

The description clearly states a specific verb and resource: "Get all students in the logged-in user's class." This gives a scoped, actionable purpose. However, it does not explicitly differentiate from sibling tools like get_all_students or get_my_students, leaving some ambiguity about which is appropriate in overlapping contexts.

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 use case (when you need students in the logged-in user's class) and gives a clear context. But it provides no guidance on when not to use it or which alternative to prefer (e.g., get_all_students or get_my_students). There are no exclusions or conditions 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?

With no annotations, the description carries the full burden and does well: it discloses the multi-school fan-out and one-result-per-school behavior, the side effect of switching to (and back from) the student account when logged in as a parent, and the shape of the return. It omits auth/permission requirements and any rate-limit or caching notes, so it stops 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?

The core purpose and lookup keys are front-loaded, and the follow-on sentences about discovery scope and account switching are relevant. The paragraph is slightly dense in the parenthetical scope explanation, but no sentence 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 tool with no output schema and no annotations, the description covers a lot: what is returned, the per-school multiplicity, and the account-switch side effect. The main gap is the undocumented date_str parameter, which an agent would need to guess at.

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 explains name-based lookup and the subdomain scope well, but never mentions the date_str parameter at all, and it refers to 'person_id' while the schema's key is 'student_id' — a naming mismatch that could confuse an agent mapping the lookup key to the argument.

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 ('Get a student's timetable') and immediately scopes it as student-targeted, which separates it from siblings like get_my_timetable and get_timetable. It also names the two accepted lookup keys (first/last name OR person_id), so an agent can tell what resource is being fetched and for whom.

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 describes what happens when subdomain is omitted and notes the parent-account behavior, which implies when the tool is useful. However it never explicitly says when to prefer this over find_student, scan_students, get_timetable, or get_my_timetable, nor when subdomain should be supplied, leaving routing 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?

No annotations are provided, so the description carries the full burden. It only restates the operation implied by the name ('Get all subjects') and does not disclose potential side effects, authentication needs, pagination, or error behavior. Minimal value beyond the tool name.

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 that front-loads the core purpose. It avoids unnecessary detail, though this brevity comes at the cost of missing useful context.

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 annotations and no output schema, the description must provide context like authentication requirements, whether a subdomain is needed, and what data is returned. None of this is present, so the description is under-specified for an agent choosing among many sibling tools.

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% description coverage, and the description does not explain the 'subdomain' parameter at all. Since the parameter is optional and undocumented in both schema and description, an agent cannot infer its meaning or effect on the result.

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 ('Get'), identifies the resource ('subjects'), and specifies scope ('all... in the school'). It distinguishes the tool from sibling getters for other entities (e.g., get_periods, get_students), though it doesn't clarify what qualifies as a subject or how it differs from similar getters like get_classes.

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 context is given for when to use this tool versus alternatives such as get_periods or get_timetable. There is also no mention of required prerequisites—like being logged in—despite the presence of authentication-related siblings (login, auth_status). The agent is left without routing guidance.

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

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

With no annotations, the description carries the burden. 'Get' implies a read-only retrieval with no side effects, which is transparent at a basic level, but it does not disclose authentication requirements, output format, or any behavior tied to the optional subdomain 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?

The description is a single, front-loaded sentence with no filler. It is appropriately concise for a simple list 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?

Despite the tool's low complexity, the description is incomplete: it omits parameter semantics, output shape, and any usage conditions. There is no output schema or annotations to fill these gaps, so the agent cannot fully predict the call's requirements.

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 the subdomain parameter. The property name gives some clue, but the agent gets no explanation of how subdomain affects results or how the default null should be interpreted.

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

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

The description uses a specific verb and resource: 'Get all teachers in the school.' It clearly states the scope (all teachers), but it does not explicitly distinguish itself from related sibling tools such as get_missing_teachers or get_my_students.

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 about when to use this tool versus alternatives, and there are no prerequisites or exclusions. The statement merely restates the operation; an agent is left to infer that this is the choice for a complete teacher list.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It states it gets a timetable but doesn't reveal any constraints like authentication requirements, date format expectations, or potential errors for invalid target types. For a read operation, this is a notable gap.

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

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

The description is two sentences, one of which is a compact enum listing for target_type. It is front-loaded with the core purpose and avoids fluff, though it could be slightly more structured with parameter explanations.

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

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

Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is incomplete. It lacks guidance on required parameters, date formatting, and how to interpret the response, leaving significant gaps for an agent to navigate.

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 only lists the possible values for 'target_type' but does not explain 'target_id', 'date_str', or 'subdomain' beyond their names. An agent is left guessing what ID format is expected or how to specify the date, so the description fails to compensate for the schema's lack of detail.

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

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

The description states a specific verb ('Get') and a resource ('timetable') with clear target types (teacher, student, class, classroom), which distinguishes it from related tools like get_my_timetable or get_student_timetable. However, it does not explicitly contrast with these siblings, so it's clear but not fully differentiated.

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 it (when you need a timetable for a specific target on a date) but does not explicitly mention alternatives or when not to use it. Given the large number of timetable-related siblings, more explicit guidance would be beneficial.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It only mentions the default date behavior and does not disclose output format, required auth state, or whether the changes are scoped to a specific user or subdomain.

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 one efficient sentence with the key action and default behavior front-loaded. Every word contributes value and there is no fluff.

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?

Despite the tool being simple, the absence of parameter semantics, return-value information, and any usage context leaves gaps. An agent cannot reliably determine the date format, what subdomain means, or what the response contains.

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

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

Schema coverage is 0% and the description only partially clarifies date_str via 'for a date (default today)'. The subdomain parameter is entirely unexplained, leaving the agent unable to determine its format or role.

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 ('Get') and resource ('substitution/timetable changes') plus the relevant date scope. It distinguishes itself from sibling timetable tools by emphasizing 'changes' rather than the regular timetable or ranges.

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 about when to use this tool versus alternatives such as get_timetable, get_timetable_range, or get_next_week_timetable. There is no mention of prerequisites like authentication or subdomain 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?

No annotations are provided, so the description carries the burden for behavior disclosure. It mentions what happens for days with no published data (empty lessons list), which is useful, but does not specify return type beyond 'dict', or any potential auth requirements or rate limits. For a read-only tool, this is partly adequate but not fully transparent.

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 well-structured sentences with high information density. Key information (range, inclusivity, target types) is front-loaded, and the edge case is addressed compactly. No fluff.

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 tool with no output schema, the description explains the return structure (dict keyed by date, each value a `get_timetable` result) and the empty-data edge case. It lacks explicit mention of `subdomain` semantics and `target_type` accepted values, which are necessary for correct invocation, but given the complexity (5 params), it is reasonably 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 explains that `target_type` and `target_id` identify the entity, and dates are inclusive and formatted (YYYY-MM-DD), which adds meaning beyond the plain schema properties. However, it does not clarify the allowed values for `target_type` or whether `subdomain` is used for multi-tenant access, leading to some gaps.

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 ('Get timetable') and scope ('for a target... for every day between start_date and end_date'), and distinguishes it from the sibling `get_timetable` by explicitly framing it as a range query that returns per-day results.

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

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

It explains the range behavior (inclusive dates, per-day dict) but does not explicitly mention when to use this versus `get_timetable` (though the difference is implied). No exclusions or alternative references beyond the implicit contrast.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies read-only retrieval, but the description does not disclose return format, ordering, timezone handling, or how 'upcoming' is defined. Without an output schema, more behavioral detail is needed.

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 one compact, front-loaded sentence with useful examples in parentheses and no filler. It is concise and scannable, though it sacrifices needed parameter and behavioral detail.

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 getter the description gives a minimal starting point, but with no output schema, no annotations, and an undocumented optional parameter, it is not complete enough for an agent to confidently understand the result shape or whether subdomain affects the response.

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 the 'subdomain' parameter. The single parameter is left to be understood only from its title, and the description adds no meaning, allowed values, or optionality context.

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 ('Get') and a clear resource ('upcoming school events'), with concrete examples in parentheses. It distinguishes the tool's subject from siblings like get_news or get_meals, though it does not explicitly name a differentiating 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?

There is no guidance on when to use this tool versus alternative event- or schedule-related siblings, no exclusions, and no prerequisites. The agent must infer usage solely from the purpose phrase.

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

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

The description discloses important behavioral traits: each call adds/replaces that subdomain's session, env vars are used as fallback, and 2FA returns instructions for follow-up calls. This goes beyond what annotations (none provided) would cover. It doesn't mention side effects like invalidating other sessions, but the add/replace note covers the key stateful behavior.

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

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

The description is compact and front-loaded: the core action is stated first, then fallback behavior, then multi-school nuance, then 2FA routing. Every sentence earns its place with no fluff.

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 tool with no output schema and no annotations, the description covers the essential call flow, env var fallback, multi-school behavior, and 2FA follow-up. It doesn't describe the success response format or error cases, but the 2FA routing and session semantics are the critical context an agent needs.

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 explains that username, password, and subdomain can be omitted and fall back to env vars, which adds meaning beyond the bare schema. It doesn't detail each parameter's format, but the env var fallback and multi-school semantics are the most important context.

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

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

The description clearly states the tool's purpose: logging in to Edupage for a subdomain. It specifies the resource (Edupage subdomain) and the action (log in), and distinguishes it from siblings like login_all and login_auto by explaining the multi-school behavior.

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 explains when to use this tool vs alternatives: it mentions login_all for multiple schools, and two_factor_check_confirmed/two_factor_finish for 2FA flows. It also documents env var fallback behavior, giving clear context for when parameters can be omitted.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states a batch login process but does not disclose behavioral traits such as authentication requirements, rate limits, side effects (e.g., creating sessions), error handling, or what happens on partial failure. For a mutation-like login operation, this is a significant gap.

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

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

The description is concise and packed with necessary information in three sentences. The primary purpose is stated upfront, followed by parameter syntax and fallback behavior. No redundant content; each sentence contributes meaning. It is well-structured and easy to parse for 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?

Considering the tool's complexity (batch login, multiple parameters, env var fallback) and the lack of output schema or annotations, the description covers the main usage aspects but omits behavioral details such as response format, error handling, and requirements (e.g., authentication). For a login tool, these are important for an agent to handle results correctly. It is minimally adequate but not fully complete.

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

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

Schema description coverage is 0%, and the schema only gives parameter names and types (all strings) with defaults of null. The description adds essential meaning by explaining that parameters take comma-separated values, how pairs are formed ('subdomains', 'usernames', 'passwords' aligned), and that env vars are used for unspecified ones. This is crucial for correct invocation and compensates well for the bare schema.

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

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

The description clearly states the tool's purpose: 'Log in to one or more schools using multiple subdomains in a single call.' It identifies a specific verb (Log in), resource (subdomains/schools), and distinguishes it from sibling 'login' by highlighting the batch aspect. However, it could be more explicit about the difference from other login variants like 'login_auto' or 'login_from_session'.

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

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

The description implies usage: 'Log in to one or more schools using multiple subdomains in a single call' and provides format details for parameters. However, there is no explicit when/when-not guidance or mention of alternatives. Siblings like 'login', 'login_auto', 'login_from_session' exist, but the description doesn't explain when batch login is preferred over these, leaving some ambiguity for the agent.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It mentions creating a session and optional subdomain tagging, but does not disclose credential requirements, two-factor authentication behavior, session replacement, error handling, or side effects. This is minimal disclosure for an authentication tool.

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

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

The description is two sentences with no filler. The first sentence front-loads the core action and key differentiator, and the second sentence explains the only notable optional parameter. Every phrase earns its place.

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

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

For an authentication tool with no annotations, no output schema, and three undocumented parameters, this description is incomplete. It doesn't state whether credentials are required, what happens on success or failure, whether two-factor is involved, or how the resulting session is returned or made available to other tools.

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 adds meaningful context only for subdomain, explaining it is a session tag for multi-school tools. It provides no meaning for username or password, leaving those parameters semantically undefined beyond their names and string 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 clearly states the action ('Log in to Edupage') and the resource ('via the portal'), with the distinguishing feature 'auto-detect school.' It also explains the optional subdomain tagging purpose. However, it does not explicitly name or contrast sibling login tools like login or login_all, so differentiation is implied rather than explicit.

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 login_auto is appropriate—when school auto-detection is desired—but it gives no explicit guidance on when to use this versus login, login_all, or login_from_session. No exclusions, prerequisites, or comparison to alternatives are 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?

No annotations are provided, so the description carries the full burden. It states the tool creates an instance but gives no indication of side effects, auth checks, error behavior on an invalid/expired cookie, or whether any remote calls are made. For an authentication-related tool this is a significant transparency gap.

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

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

A single sentence that names the action and source. It is front-loaded and economical, though the brevity comes at the cost of behavioral and parameter detail.

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 three required parameters, zero annotations, and no output schema, the description is too thin. An agent needs to know what the returned instance supports, how session validity is handled, and what format subdomain/username must take.

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 the parameters itself. It only identifies session_id as an existing PHPSESSID cookie; the role of username and subdomain is left unexplained, which is particularly important for a login 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 action ('Create a logged-in Edupage instance') and identifies the source ('existing PHPSESSID cookie'), which clearly differentiates it from credential-based login tools. However, it doesn't explicitly name siblings or say why this tool exists over alternatives.

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

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

The phrase 'from an existing PHPSESSID cookie' provides clear usage context: use this when you already have a session cookie rather than credentials. It does not explicitly state when not to use it or mention alternatives like login, but the condition 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?

With no annotations to carry the burden, the description is thin on behavior: it does not state whether an existing rating is overwritten, whether a meal must already exist, what side effects occur, or what the response contains. It only states the basic action.

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 clear, front-loaded sentence with no filler. Every phrase adds meaning: the action, the scale, and the selecting dimensions (date and meal type).

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 five parameters, zero schema descriptions, no output schema, and no annotations, the description is too sparse to be complete. It omits date format, meal type values, subdomain semantics, auth requirements, and overwrite 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?

The description clarifies that quality and quantity are rated on a 1-5 scaleasiendoish, which the schema lacks. However, it does not explain date_str format, valid meal_type values, or the optional subdomain parameter, leaving important semantics unexplained at 0% schema description coverage.

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 'Rate' plus object 'a meal' states the core action clearly, and the rating scale (1-5) is included. However, it does not explicitly differentiate itself from sibling meal-related tools such as choose_meal or sign_off_meal.

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 for when to use rate_meal versus other meal-related tools, nor any prerequisites like authentication or an existing meal record. The phrase 'for a date and meal type' gives context but no selection 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?

With no annotations, the description carries the full burden and does well: it discloses the discovery scope (EDUPAGE_SUBDOMAINS or every school), account-type-conditional output, one-record-per-student-per-school granularity, and that results are cached to avoid redundant API calls. It omits auth/permission requirements and failure modes, keeping 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?

Front-loaded with the core action and scope, then adds account-type and granularity detail. Four sentences with minimal waste; the multi-school clarification is slightly wordy but earns its place by pinning down the return cardinality.

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?

Zero params and no output schema mean the description must convey the return shape, which it does (one entry per student per school). Scope, account dependence, and caching are all covered; only auth/error conditions and cross-sibling disambiguation are 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?

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly avoids inventing parameter behavior and instead clarifies what the no-argument call returns.

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?

Names a specific verb ('Discover') and resource ('all students') and clearly scopes it to the logged-in account across the discovery scope. However, it never distinguishes itself from close siblings like get_students, get_all_students, get_my_students, or find_student, so an agent cannot route between them from the description alone.

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

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

It explains account-dependent semantics (parent = linked children, student = classmates), which implies the tool's context of use. But it gives no explicit when-to-use, when-not-to-use, or alternative ('use X instead'), leaving the agent to infer which of the several student-listing siblings to call.

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?

There are no annotations, so the description carries full responsibility for behavioral disclosure. It only states that the tool returns a value, with no mention of authentication requirements, whether the subdomain affects the result, or error behavior. For a tool that likely depends on session/auth state (given the login/auth siblings), this is a meaningful gap.

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

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

The description is a single concise sentence with no filler. The key output ('current school year') and a clarifying parenthetical ('starting year') are front-loaded and each part 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 tool with no annotations, no output schema, and an undocumented optional parameter, the description is too sparse. It fails to explain the subdomain parameter, whether authentication is required, or what exact value format is returned. An agent may call it correctly by chance, but the definition does not provide enough context to ensure 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 mention the 'subdomain' parameter at all. The schema only gives a name and default, leaving the agent to guess what subdomain means and how it affects the school year. The description adds no semantic value for the parameter.

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

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

The description clearly states a specific verb ('Return') and resource ('current school year'), and adds a useful clarification that it returns the starting year. This unambiguously distinguishes it from the sibling tools, none of which overlap with this purpose.

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 explicit when-to-use or when-not-to-use guidance is provided, and no alternative tools are mentioned. Usage is only implied by the description: an agent would infer to use it when the current school year is needed. This is acceptable for a simple getter but leaves context unstated.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Send a message,' implying a mutation, but it does not mention required authentication, side effects (like notifications to recipient), rate limits, or success/failure behavior. This is a significant gap for an action tool.

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

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

The description is a single, focused sentence that front-loads the purpose and then gives a practical detail about recipient_id. There is no redundancy or fluff; 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 tool with three parameters and no output schema, the description leaves too much unstated. It does not explain the body parameter, what subdomain means or when to override it, whether login is required, or what the call returns. The recipient_id hint is good but insufficient for reliable 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%, so the description must compensate. It does clarify the recipient_id format and points to lookup tools, which is valuable. However, it leaves body and subdomain undefined. body is likely the message content but not explicitly stated, and subdomain is not explained at all. Partial compensation only.

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

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

The description states a clear verb ('Send') and resource ('a message') with a recipient, and it explicitly defines the recipient_id format. It stands apart from all sibling tools (which are mostly get_* or auth-related), so there is no ambiguity about what this tool does.

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

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

There is no guidance on when to use this tool versus alternatives, nor any exclusions. The only hint is pointing to get_students/get_teachers for recipient_id formatting, which is about parameter values, not usage context. No mention of prerequisites (e.g., being logged in) 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?

No annotations are present, so the description carries the full burden. Although it states that the action is cancelling a meal, it does not disclose consequences such as irreversibility, permission requirements, or what happens if the meal is not currently ordered. This is sparse for a destructive mutation tool.

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

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

The description is two sentences with no filler. The first sentence front-loads the action, and the second sentence adds a useful constraint that the schema does not enumerate. Every sentence earns its place.

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

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

For a 3-parameter mutation tool with no annotations and no output schema, this description is too thin. It leaves out date_str format, subdomain semantics, and any postcondition or return behavior, leaving an agent to guess at critical 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?

With 0% schema coverage, the description must compensate. It provides allowed values for meal_type, but date_str format is not explained and subdomain is never mentioned. The added value covers only one of three parameters and is incomplete.

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

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

The description clearly states a specific verb and resource: 'Cancel an ordered meal for a date.' It also narrows meal_type to the valid options, which helps distinguish this from sibling tools like choose_meal, get_meals, and rate_meal.

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

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

The description implies when to use the tool—when an ordered meal needs to be cancelled—but it does not explicitly contrast it with alternative tools or state prerequisites or exclusions. The usage context is clear but left to inference.

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

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

There are no annotations, so the description carries the full burden of disclosing session effects, authentication requirements, and reversibility. 'Switch back' hints at a prior state but does not explain whether the switch mutates the session, whether it can be undone, or what occurs if invoked outside a parent session.

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 short sentence with no filler, which is concise. However, it repeats 'parent' in both the action and the parenthetical, and the ambiguous restriction reduces the clarity that strong conciseness should provide, so it is not a model of efficient structure.

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 this is a simple one-parameter tool with no output schema, it is an auth/session transition with a completely undocumented optional parameter. The description leaves critical context missing—parameter semantics, preconditions, and behavioral effects—so an agent cannot confidently invoke 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 contains one optional parameter, subdomain, with zero schema description coverage, and the description does not mention it at all. The agent is given no information about what value to pass, why it is optional, or how it affects the switch, so parameter semantics are effectively absent.

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 action ('switch back') and resource ('parent account'), and the sibling list includes switch_to_student, making the directionality reasonably clear. However, the parenthetical 'parent accounts only' is ambiguous: it could mean only parent roles can call this, or that the tool operates only in a parent context, which prevents 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 description provides no explicit guidance about when to use this tool versus alternatives such as switch_to_student or login. It implies a return from a student context to a parent context, but it does not state preconditions, when not to use it, or which sibling covers the opposite direction.

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

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

With no annotations, the description carries the full burden of behavior disclosure. It says 'switch', implying a state change, but does not explain what that means for the session, whether it requires authentication, whether it is reversible, or what side effects it might have on subsequent calls. This is a significant gap for a mutation-like tool.

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

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

The description is in two concise sentences with no redundant or unnecessary wording. It starts with the primary action, then provides the essential parameter guidance, all in minimal space.

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

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

The tool has 3 parameters, none marked required, no output schema, and the description leaves the `subdomain` parameter undefined and no required parameter relationship. This means an agent could easily call it without any of the identifiers or with the wrong subdomain, and side-effect information is entirely absent in the absence of annotations. The definition is incomplete for safe and correct invocation.

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

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

The description adds meaningful semantics for two of the three parameters: 'student_id' is clarified as `person_id`, and `name` is clarified as first/last/full name and the 'or' relation between them. However, it does not mention the 'subdomain' at all, nor the parameter combination rules, and the schema has 0% coverage, so the conceptual transformation is incomplete.

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: 'Switch to a student account' and restricts it to 'parent accounts only', which unambiguously identifies the target resource. However, it does not explicitly contrast with the sibling tool 'switch_to_parent', so it does not fully differentiate itself from its inverse.

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

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

The description gives a clear usage condition: 'parent accounts only', and indicates how to identify the target ('Provide student_id (person_id) or name'). It lacks a when-not-to-use statement or mention of alternatives, but the condition provided is explicit enough for a basic 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?

With no annotations, the description carries the burden. It states that it returns a boolean indicating confirmation, but does not disclose what happens if 2FA is not required, whether it blocks, or any side effects (though it's likely a read-only check). Missing details about error handling or timing, but the core behavior is clear.

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

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

The description is two sentences with no fluff. It front-loads the context (after login) and states the return value and purpose. Perfectly 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?

Given the complexity (a simple check tool with one optional param and no output schema), the description is mostly complete. It lacks information about potential errors, rate limits, or what 'confirmed' means precisely (e.g., does it auto-approve? Is it a poll?). But for a simple gate, it is adequate.

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 optional parameter `subdomain` with no description. The description does not explain its purpose, but with only one parameter and it being optional, the agent might infer it targets a specific domain. Since coverage is 0%, the description should compensate, but it does not. However, the parameter is likely obvious from sibling tools like `login` that also use subdomain, so score is moderate.

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: check 2FA confirmation status after login, and explains the return value (True when safe to proceed). It distinguishes itself from `two_factor_finish`, which is the next step, and from `login` variants.

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 when to use: after a login that required 2FA. It implies the sequence: call this before `two_factor_finish`. However, it does not explicitly mention alternatives like `auth_status` or `login_from_session` for checking auth state, but the context is clear 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?

It discloses an important runtime branch: the presence or absence of `code` changes the flow, and the device-confirmation flow has a prerequisite. Since no annotations are provided, this behavioral context carries real weight. However, it does not mention side effects on the session, possible errors, or what happens after a successful finish, leaving the behavioral picture incomplete.

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

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

Two sentences with no filler. The main purpose is front-loaded, and the conditional behavior plus prerequisite are packed into a compact second sentence. 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 2-parameter auth step, the description covers the essential branching and prerequisite despite having no annotations or output schema. The missing `subdomain` semantics and lack of return/error behavior prevent it from being fully complete.

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

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

Schema description coverage is 0%, so the description must add meaning to the parameters. It does clarify that `code` is an email/app code and distinguishes it from the no-code confirmation flow. However, `subdomain` is never explained, leaving one of two parameters semantically 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 phrase 'Finish 2FA authentication' names a specific auth step, and the conditional clause clarifies the two modes: using a provided code or falling back to device confirmation. Referencing two_factor_check_confirmed helps distinguish this tool from the related 2FA sibling. It is clear, though the term 'finish' is slightly less concrete than naming a resource or outcome.

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

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

The description gives an explicit rule: if `code` is provided, use it as an email/app code; otherwise, use the device-confirmation flow. It also tells the agent to call two_factor_check_confirmed first in the no-code path. This is actionable guidance, though it does not address broader auth-tool selection among login-related siblings.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It accurately indicates a read-only return of the current user's ID, but it does not mention error behavior when not logged in or any other operational details.

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

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

The description is a single, front-loaded sentence with no filler or redundant information. It is appropriately sized for the tool's apparent 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 description is too sparse for a tool with an undocumented optional parameter and no output schema. It omits subdomain semantics and auth-state behavior, leaving meaningful gaps even for a simple getter.

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 the 'subdomain' parameter at all. The agent gets no explanation of whether the parameter is required, what it controls, or how it affects the result.

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

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

The description uses a specific verb and resource: 'Return the logged-in user's Edupage user id,' which makes the action unambiguous. It does not explicitly distinguish itself from sibling tools like auth_status, so it misses the top score.

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

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

The description provides no guidance on when to use this tool versus alternatives such as auth_status or login, nor does it state prerequisites like requiring an active session. Usage context is only implied by the phrase 'logged-in user.'

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