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

Annotations already declare readOnlyHint=true, so the agent knows this is a read-only operation. The description adds useful semantic context (weekly defaults and parent-review status) but does not disclose additional behavioral traits such as authentication needs, rate limits, or no-data behavior. This is acceptable for a simple read-only 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, compact sentence that front-loads the resource and then clarifies it with an em-dash aside. Every phrase adds meaning—weekly, default, per-day dismissal, and parent-review status—with no filler or redundancy.

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

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

Given a one-parameter read-only tool with no output schema, the description sufficiently explains the return content: the default dismissal plan by weekday and the parent-review status. It could be more explicit about the exact output shape or behavior when no defaults exist, but it is otherwise adequate for selecting and invoking the tool.

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

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

The only parameter, student_id, is already fully documented in the schema with 'Student id, from pup_list_students', giving 100% schema description coverage. The description adds no parameter-level details, so it remains at the baseline.

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

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

The description clearly identifies the returned resource: a student's weekly default dismissal plan, per weekday, plus whether parent review is still needed. It conveys the 'default' nature that separates it from generic plan tools, but it does not explicitly state the verb 'get' or name sibling tools for differentiation.

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

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

No explicit when-to-use or when-not-to-use guidance is provided, and no alternatives are mentioned. The context is implied—use this when you need default dismissal plans or review status—but an agent is not told how to choose between this and related tools like pup_get_plan or pup_list_plans.

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

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

The readOnlyHint annotation already indicates this is a safe read operation, and the description adds meaningful behavioral detail: it returns the option in force, any note, the early-dismissal time, and whether the date is locked due to a passed cutoff. This goes beyond the schema and annotations by clarifying the scope and output aspects. It does not disclose error behavior, but for a read-only lookup this is a minor 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 dense sentence that front-loads the core purpose and then uses an em-dash list to enumerate the returned components. Every phrase earns its place with no filler or repetition.

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

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

For a simple two-parameter read-only tool with no output schema, the description provides enough context to understand the returned fields. It names the key output elements, though it does not fully explain what 'locked because the cutoff has passed' means in practice or what values 'option in force' can take. Overall, it is sufficiently complete for selecting and invoking the tool.

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

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

Schema description coverage is 100%, with both student_id and date fully described in the input schema. The tool description does not add new parameter-level details beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the resource: a dismissal plan for one student on one date, and enumerates its contents (option, note, early-dismissal time, locked status). It lacks an explicit verb like 'retrieve' or 'get,' but the scoping to a single student and date clearly distinguishes it from sibling tools like pup_list_plans and pup_set_plan.

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

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

Usage is implied by the phrase 'for one student on one date,' which suggests it is the single-plan lookup rather than lists or defaults. However, the description does not explicitly state when to use this tool versus alternatives such as pup_get_default_plans or pup_list_plans, nor does it mention any exclusions or preconditions.

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

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

The readOnlyHint annotation already covers the safety profile, and the description adds useful return-content detail. It does not disclose behavior such as error handling for unknown school_ids, data sourcing beyond 'profile', or response shape; with annotations present, 3 is appropriate.

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

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

A single, well-structured sentence that front-loads the core object and then appends the specific component groups. No filler, redundancy, or unnecessary 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 read-only get-by-ID tool, the description names the essential return components and the schema covers the one parameter. It is complete for basic invocation, though it does not describe error/not-found behavior or response formatting, which would be useful without an 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 input schema fully describes school_id as an integer sourced from pup_list_students, and the tool description adds no parameter-level meaning. Since schema coverage is 100%, the baseline 3 applies; there is no gap requiring the description to compensate.

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

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

The description identifies the resource (school profile) and specifies its distinctive content: per-weekday notify times, plan cutoff times, and parent-plan settings. This clearly distinguishes it from sibling getters like pup_get_student and pup_get_plan, though it states the result as a noun phrase rather than an explicit retrieval verb.

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 use case is implied: call this when you need a school's profile and plan-related settings. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions or prerequisites, leaving the agent to infer selection from the name and content.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context beyond that by naming exactly what the session contains and how it can be used to bootstrap discovery of related IDs, which is helpful given there is no output schema.

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

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

The description is two sentences with no wasted words. It front-loads the core meaning of the session object and adds the key usage hint about discovering IDs, making it easy for an agent to scan and act on.

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

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

For a zero-parameter, read-only session getter with no output schema, the description covers the essential return contents and the intended entry-point use case. It could be marginally richer by noting that the linked students contain the IDs to be extracted, but overall it is 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?

The input schema is empty with zero parameters, so there are no parameter semantics for the description to clarify. The description appropriately reinforces that the tool is a simple starting point, matching the baseline expected for a no-parameter tool.

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

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

The description identifies the resource as 'The signed-in PickUp Patrol parent account' and lists the key fields returned: name, email, last sign-in, and linked students. It also explains its role as the starting point for discovering student and school IDs, which distinguishes it from sibling student/school-specific tools, though it lacks an explicit verb like 'returns' or 'gets'.

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 'Start here to discover student and school ids' gives clear contextual guidance for when to call this tool before other tools. It does not explicitly name alternatives or exclusions, but the entry-point framing is sufficient for a zero-parameter session 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?

The readOnlyHint annotation already establishes safety, so the description's main contribution is the projection behavior: by default a summary is returned and raw:true returns the untouched API record. This goes beyond the annotation and helps an agent understand output variation, though error and edge-case behavior are not described.

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

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

Two sentences with no filler; the main deliverable is stated first and the optional raw behavior is given second. The structure is easy to scan and each 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 two-parameter read-only tool, the description covers the core return content and the summary-vs-raw distinction. No output schema exists, so a little more detail about the full shape could help, but the essentials for selecting and calling the tool are present.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description's 'Pass raw: true for the untouched API record' restates the raw parameter's meaning with slightly different wording but adds no substantive information beyond the property description.

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

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

The description identifies the resource ('one student') and a distinguishing feature: the full record includes the default dismissal plan for each weekday. It clearly differentiates this from list-style siblings such as pup_list_students, though it does not use an explicit verb like 'returns'.

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

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

The description implies the tool is for retrieving a single complete student record rather than a list or a plan-only resource, but it does not explicitly state when to choose it over siblings like pup_get_default_plans or pup_list_students. There are no exclusion criteria or alternative routes 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?

Given the readOnlyHint=true annotation, the description adds meaningful context by specifying what the read actually does: it validates credentials, checks API responsiveness, and reports server version plus visible students. This goes beyond the annotation and gives the agent a clear expectation of the tool's behavior and output scope. No annotation contradiction exists.

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 tight sentences with no filler. The primary purpose is front-loaded ('Verify the configured credentials sign in'), followed by the concrete outputs. 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 a zero-parameter, read-only health check with no output schema, the description provides everything an agent needs to decide whether to invoke it and to interpret its results: it reports server version and visible students. The only minor ambiguity is naming the student-report side effect, but the healthcheck framing makes it clear enough.

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

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

The tool has zero parameters and no input schema properties, so the description does not need to explain parameter meaning. The description appropriately focuses on what the tool returns instead.

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 ('Verify') and resource (configured credentials + PickUp Patrol API), and distinguishes this healthcheck tool from data-list siblings like pup_list_students by framing the student report as part of a connectivity check. It also names concrete outputs: server version and visible 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 use case is implied: this is the tool to run when you need to confirm credentials work and the API is reachable. However, it does not explicitly say when to prefer this over sibling tools like pup_get_session or pup_list_students, nor does it state exclusions such as 'use pup_list_students when you only need the student 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?

Annotations already declare readOnlyHint=true, so the description does not need to restate that. It adds a small behavioral detail about the dependency on usesCarNumbers, which is useful context. It does not contradict the annotations, but the added behavioral disclosure is minimal beyond what annotations already convey.

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, dense sentence that front-loads the resource ('car numbers') and immediately provides the usage condition. There is no filler or redundancy; it 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 one parameter and no output schema, the description gives the essential information: what it returns, for what purpose, and under what condition. It omits the response shape, but that is not strictly necessary given the absence of an output schema. The mention of usesCarNumbers is a key contextual detail that helps the agent decide when to call it.

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

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

The schema description for school_id is fully covered (100%), including guidance to obtain it from pup_list_students. The tool description does not add parameter-specific detail, but that is acceptable because the schema already provides sufficient meaning. The baseline of 3 is appropriate.

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

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

The description clearly states the tool returns the list of car numbers issued to a school for the account, and specifies the context (dismissal options). This differentiates it from sibling list tools like pup_list_students or pup_list_transportations, though it does not explicitly name alternatives.

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

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

The description provides a clear usage condition: it is for dismissal options where usesCarNumbers is true. This gives the agent a specific criterion for selecting this tool, but it does not explicitly state when not to use it or mention alternative tools, so it stops short of a full 5.

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

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

The readOnlyHint annotation already establishes safety, and the description adds substantive behavior: the result includes holidays, closures, and weekends, and optionally includes range dates that differ from student defaults. It does not mention output format or ordering, but it provides a meaningful semantic contract beyond the annotation.

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

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

The description is a single compact sentence that front-loads the main purpose and then adds the optional behavior. It is not verbose, though the two behaviors are packed together in a slightly dense way that could be clearer if separated.

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 list tool, the description is adequate: it explains the main result and the optional mode. However, there is no output schema, and the description does not specify the return shape or what happens when no date range is provided, such as whether all non-school days are returned or only some default window.

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

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

Schema description coverage is 100%, so the baseline is 3. The description echoes the optional start_date/end_date behavior by referencing 'dates in a range' and 'student defaults,' but it does not add new parameter syntax, formats, or details beyond what the schema already provides.

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

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

The description clearly identifies the resource (a school) and the semantic content: dates a plan cannot be set for, namely holidays, closures, and weekends, plus an optional mode for dates differing from student defaults. This differentiates it from sibling tools about students, plans, transport, and schools, though it lacks an explicit verb like 'returns' or 'lists.'

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

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

Usage context is implied: use this when you need dates when plans cannot be set at a school or when checking date-range differences against defaults. However, there is no explicit when-to-use guidance, no mention of alternatives, and no exclusions among the sibling 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 readOnlyHint annotation already signals this is a safe read. The description adds that it returns data 'as PickUp Patrol returns them,' but this is vague and doesn't clarify pagination, ordering, or limits. It provides minimal extra behavioral context beyond the annotation.

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

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

A single, front-loaded sentence that efficiently communicates the tool's purpose and scope with no wasted words. It avoids repeating schema details.

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

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

With no output schema, the description should hint at what a 'plan' contains or how results are structured. It only says 'day-by-day dismissal plans,' which is vague. The description is adequate for triggering a call but not for interpreting the response, leaving the agent to guess the structure.

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

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

Schema coverage is 100% with both parameters described as YYYY-MM-DD. The description mentions 'date range' but adds no additional semantic detail beyond what the schema already provides. Baseline 3 applies since the schema carries the meaning.

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

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

The description clearly states the verb (list) and resource (dismissal plans), and specifies the scope: day-by-day across a date range for every student. It differentiates from siblings like pup_get_plan (single student) and pup_get_default_plans (defaults) by emphasizing 'every student' and 'across a date range.'

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

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

The description implies usage context: use this to get a comprehensive list of plans for all students over a period. It does not explicitly name alternatives or when not to use it, but the scope is clear enough that an agent can infer it's not for single-student or default-plan queries.

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

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

The readOnlyHint annotation already communicates that this is a safe read operation, lowering the burden on the description. The description adds useful outcome context (each student's plan and review state) but does not disclose ordering, pagination, or other runtime behavior. No contradiction with annotations.

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

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

One compact sentence conveys scope and content with no filler. The key idea, 'every student on the account,' is front-loaded, and 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 a zero-parameter, read-only list tool with no output schema, the description sufficiently describes the returned information: all students, their default dismissal plan, and review status. Nothing essential is missing for an agent to know when to call this tool and what it will get back.

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 are zero parameters, so there is nothing for the description to explain about inputs. The description does add meaning by summarizing what the account-wide result set contains, which is sufficient given the empty schema.

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

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

The description clearly identifies the resource ('every student on the account') and what is included per student, so an agent can tell this is a list-all tool. It lacks an explicit imperative verb and does not explicitly contrast with siblings like pup_get_student, though the plural framing and account-wide scope make the purpose reasonably clear.

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

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

The description implies this is the account-wide student listing and that it surfaces dismissal-plan review status, which gives helpful context. However, it does not explicitly state when to prefer this over pup_get_student, pup_list_plans, or pup_get_default_plans, nor does it mention exclusions.

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

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

The description adds domain context about the returned data (rules for each dismissal option) beyond the readOnlyHint annotation, and reinforces that it's a read operation by advising to read it before a plan-setting write. No contradictions; it doesn't disclose every behavioral detail, but annotations already cover the safety profile.

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

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

Two sentences, no filler. The first sentence packs the essential content (what the list contains and the rule fields), and the second sentence gives actionable usage guidance. Very efficient and well-structured.

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

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

Given no output schema, the description sufficiently explains what will be returned and the domain. It could be slightly more explicit that it returns a list, but the name and plural phrasing imply it. Combined with the annotated read-only behavior and parameter descriptions, an agent can call it correctly without missing critical information.

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

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

Schema coverage is 100%, and both parameters already have clear descriptions (school_id from pup_list_students, include_inactive with default false). The tool description adds no parameter-specific guidance, so the baseline of 3 is appropriate.

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

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

The description states the tool lists dismissal options a school offers, with specific rule attributes (note required, car number, early dismissal, cutoff time). This clearly identifies the resource and differentiates it from siblings like pup_list_plans or pup_list_car_numbers.

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 'Read this before setting a plan' provides clear context and a prerequisite for using pup_set_plan. However, it doesn't explicitly compare to alternatives or say when not to use it, so it falls just short of a 5.

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 a key behavioral trait: the tool requires confirm: true, and without it, the tool returns a preview. This is valuable beyond the schema, which only says 'Must be true to proceed.' The description also explains the effect of clearing the prompt. No annotations are provided, so the description carries the burden, and it does so reasonably well.

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 waste. The main action and effect are front-loaded, and the critical confirm requirement is stated clearly. 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 mutation tool with 3 parameters and no output schema, the description covers the essential behavior: what it does, what it requires, and what happens without confirmation. It could mention the return value or side effects more explicitly, but the core is complete.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds context for confirm (required to proceed) and reviewed (defaults to true), but these are already in the schema. The description does not add new meaning beyond the schema, so 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 clearly states the action ('Mark a student's default plans as reviewed'), the resource ('default plans'), and the effect ('clearing the school's 'needs review' prompt'). It is specific and distinguishes itself from sibling tools like pup_set_default_plans or pup_get_default_plans.

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 a student's default plans have been reviewed and the school's 'needs review' prompt should be cleared. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it over 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 safety burden and does disclose the write/destructive nature ('Change... or clear every default') and the confirmation/dry-run behavior. Yet most of this is mirrored by the schema's confirm and clear_all descriptions, and it omits side effects such as reversibility, permission requirements, or impact on existing scheduled plans.

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

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

Three short sentences, front-loaded with the core operation, followed by the critical confirmation requirement and a prerequisite lookup. There is no filler or repetition beyond what is needed for quick comprehension.

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 7-parameter mutation with no output schema, the description provides the key selection context, the confirmation requirement, and a prerequisite step. It relies on the schema for parameter-level details, which is acceptable given 100% coverage, but it stops short of mentioning what the dry-run preview contains or how to combine days/transportation_id explicitly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: 'one or more weekdays' roughly restates the days array and 'clear every default' restates clear_all. It does connect the workflow to pup_list_transportations, but the schema already points transportation_id to that source.

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

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

The description opens with a specific verb and resource ('Change a student's weekly default dismissal plan') and immediately draws two distinct operations: altering specific weekdays or clearing all defaults. It also clarifies the domain ('how the child leaves school on any date without a specific plan'), which sets it apart from sibling plans like pup_set_plan.

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

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

It gives clear context for when the tool applies ('on any date without a specific plan') and states the requirement to pass confirm: true, plus a dry-run fallback. It also instructs the agent to read pup_list_transportations first. However, it does not explicitly name the alternative for specific-date plans (e.g., pup_set_plan) or state a when-not condition beyond implication.

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. It openly states this is a real-world mutation ('changes how a child actually leaves school'), requires confirm: true, and reveals that without confirmation the tool returns a dry-run of the exact payload. This is unusually transparent for a 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?

Three tight sentences with no filler. The core action is front-loaded, the critical confirm behavior is stated plainly, and the prerequisite read is included without redundancy. 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 7-parameter mutation tool with no output schema or annotations, the description covers the essential operational facts: what the tool does, what confirm does, the dry-run fallback, and the prerequisite lookup. It doesn't describe the response format, but the dry-run note softens that gap, and the schema already documents every 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by linking transportation options to their required parameters: 'options differ in whether they require a note, a car number or an early-dismissal time.' It also reinforces the meaning of null transportation_id as clearing dates back to the weekly default.

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 specific verbs and resources: 'Change how a student is dismissed on one or more specific dates, or clear those dates back to the student's weekly default.' This clearly distinguishes the tool from siblings like pup_set_default_plans by focusing on specific-date overrides rather than ongoing defaults.

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

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

The description explicitly tells the agent to 'Read pup_list_transportations first' and explains why: options differ in required fields such as note, car number, or early-dismissal time. It doesn't explicitly name when not to use this tool or mention pup_set_default_plans, but the prerequisite guidance is strong and actionable.

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