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

Far exceeds the annotations (destructiveHint, non-idempotent, openWorld), which only signal that it mutates. The description discloses the confirm-gating interaction model, that phase 1 makes NO change, the exact preview payload, that the token is bound to the previewed arguments and the day as read, that a changed day is refused with a fresh preview, and that the calendar is re-read afterward to verify the default.

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 dense paragraph, but the core verb+effect is front-loaded and nearly every clause carries operationally relevant information (confirmation phases, token rules, refusal behavior). It is longer than typical but not padded.

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

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

No output schema exists, and the description compensates by specifying what phase 1 returns (child by name, date, change, exact request, confirmToken). For a destructive, confirm-gated mutation with four parameters, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the 3 baseline applies, but the description adds meaning beyond the field docs: it explains the token's role and binding in the confirmation lifecycle and why change_series_id is needed only when a date carries multiple changes. It does not restate the date/student_id formats, which the schema already covers.

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 (cancel) and resource (a previously-submitted dismissal/arrival change) plus the effect (returns the date to its default). An agent can immediately distinguish this from the sibling schoolpass_submit_dismissal_change without opening either schema.

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

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

Gives clear when-to-use context and, unusually, explains the two invocation modes (elicitation-capable clients vs. the two-step preview/confirmToken fallback) so the agent knows when a second call is required. It stops short of naming sibling alternatives (e.g. submit_dismissal_change, get_calendar) or stating exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered; the description's main additions are the default range and the fact that both defaults and changes are returned. It says nothing about pagination, volume of days, auth scope, or how changes are flagged in the response.

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, front-loaded with the action and payload scope, then prerequisites and defaults. Every clause carries information; nothing is padding.

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

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

With annotations covering the safety profile and no output schema to explain, the description supplies the action, the range default and the param source. It could go further on response shape (how per-day defaults vs changes are represented), but for a read-only lookup it is largely sufficient.

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

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

Schema description coverage is 100% — every parameter already documents its format, default and (for view) its trade-offs. The description only restates the student_id source and the date defaults, adding no new 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?

States a specific verb and resource ('Get a student's arrival & dismissal calendar') plus the scope of the payload ('the per-day default and any changes'). That content scope distinguishes it from the changes-only sibling schoolpass_list_pickup_changes without needing to name it.

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 names the prerequisite ('Requires a student id (from schoolpass_list_students)') and the default window, which is useful context, but it never says when to reach for this tool versus schoolpass_list_pickup_changes or the school-info tools. Usage is implied rather than stated.

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

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

With readOnlyHint, idempotentHint, and openWorldHint already present in annotations, the description does not need to restate safety behavior. It adds a useful scope ('for the signed-in parent') and content expectations, but it does not disclose error behavior, response envelope, or other operational traits beyond the annotations. No 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 a single, front-loaded sentence that packs the action, object, content, and scope without filler. It avoids duplicating schema details or annotation hints.

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 optional-parameter read with read-only and idempotent annotations, the definition is largely self-sufficient: the schema fully documents the only parameter)Skip and the description clarifies the resource and scope. It lacks an explicit contrast with schoolpass_whoami and any detail on the response envelope, but these are not critical for making a correct first call.

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 100% parameter description coverage-newline including a detailed explanation of the view enum and its compact/full behavior. The tool description itself adds nothing about the parameter, but the schema already provides the necessary meaning, so the baseline score of 3 applies.

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 the parent account profile', and clarifies the content with '(contact details and account settings)' and the scope 'for the signed-in parent'. It is clear about what the tool returns, though it does not explicitly distinguish itself from the sibling schoolpass_whoami, so agents must infer the boundary between identity and profile.

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

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

There is no statement about when to use this tool versus alternatives such as schoolpass_whoami or schoolpass_list_students. The phrase 'for the signed-in parent' implies a prerequisite, but it does not provide routing guidance, exclusions, or example scenarios.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful context by specifying what the response covers (features enabled, dismissal windows, etc.), but it does not disclose response shape, potential variability, or any operational behavior beyond the annotations.

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

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

The description is a single sentence that immediately states the tool's purpose and key data contents. It is front-loaded and contains no filler or redundant repetition of the tool name or schema.

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

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

For a simple read-only info tool with one optional parameter and no output schema, the description gives sufficient context about what the caller will receive. The 'etc.' is slightly vague, but the examples (features enabled, dismissal windows) give a clear enough sense of scope for an agent to invoke it appropriately.

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%, and the single 'view' parameter is thoroughly documented in the schema itself. The description does not add parameter-level detail, but the baseline of 3 applies because the schema carries the full burden.

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') and resource ('school info and per-school configuration'), giving immediate clarity about what the tool does. It also distinguishes itself from the sibling tools by referring to the configured school's general information rather than students, drivers, calendar, or dismissal changes.

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 no direct guidance about when to use this tool versus alternatives. It implies usage through its purpose, but it does not state exclusions, prerequisites, or mention any sibling tool such as schoolpass_healthcheck or schoolpass_whoami.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering safety and repeatability. The description adds value by explaining the two-part behavior (unauth probe and credential login), which is not directly implied by the annotations. It doesn't contradict annotations and provides useful context about the checks performed.

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, front-loaded with the core action and purpose. It efficiently conveys the two checks and the rationale without unnecessary 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 no parameters, no output schema, and annotations covering the safety profile, the description is complete. It explains what the tool does, why it's useful, and the distinction it provides. The agent has everything needed to invoke it correctly.

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

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

The tool has zero parameters, so the schema provides no parameter documentation. Per rubric, a tool with 0 parameters gets a baseline of 4. The description doesn't need to add parameter meaning since there are none, and it doesn't attempt to invent any.

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 with a specific verb ('Check') and resource ('SchoolPass connectivity and authentication'). It distinguishes two distinct aspects: an unauthenticated version probe for reachability and a credentials login check. This clearly differentiates it from sibling tools like schoolpass_whoami or schoolpass_list_students, which focus on specific data operations.

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 needing to diagnose whether network issues versus credential problems are at play. It explicitly states the diagnostic value ('so a network problem is distinguishable from a bad password or school code'). However, it does not name alternatives or explicitly state when not to use this tool, though the context is clear enough for an agent to infer its diagnostic role.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the behavioral context that the result serves as the reference vocabulary for dismissal changes, which is valuable beyond the annotations. It also confirms the output includes ids, giving a hint about the return shape.

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 sentence, front-loaded with the core purpose, followed by a clarifying clause about its role in dismissal changes. Every word earns its place; 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 simple list tool with no output schema, the description conveys the essential facts: it lists locations and their ids, and it is the vocabulary for dismissal changes. It does not specify the exact response structure, but given the simplicity and the annotations, this is sufficient. It could mention if it returns only active locations, but that is a minor gap.

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 'view' is fully documented in the input schema with a detailed description of compact vs full behavior. Schema coverage is 100%, so the description does not need to repeat parameter details. The tool description adds nothing about parameters, but the schema carries the load, meeting 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 states a specific verb (List) and resource (dismissal locations), and clarifies the output includes ids. It also explicitly ties the tool to the dismissal-change vocabulary, distinguishing it from sibling list tools like list_students or list_drivers.

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 by stating 'the vocabulary a dismissal change refers to', which signals it should be used before submitting or canceling a dismissal change. However, it doesn't explicitly state when not to use it or name alternatives, leaving some inference needed.

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 goes well beyond the readOnlyHint and idempotentHint annotations by explaining the default compact view drops contact and vehicle fields for carpool records, that carpool records describe other families, and that view 'full' keeps those fields. This meaningfully informs the agent about response-shape 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 two sentences with no filler. The first sentence states the core purpose immediately; the second packs necessary caveats about include_carpool, other families, and the compact/full view distinction without wasting words.

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

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

For a zero-required-parameter list operation with no output schema, this description is complete. It states what is returned, how the optional parameter changes the response, and what the default view strips. An agent can call this tool correctly with the information provided.

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

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

The schema already documents both parameters thoroughly, so the baseline is 3. The description adds valuable cross-parameter context by linking include_carpool: true to the carpools returned and explaining how the default compact view affects those carpool records, which the schema does not explicitly state.

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: 'List the authorized pickup drivers registered on the parent account.' This clearly distinguishes the tool from siblings like schoolpass_list_students, schoolpass_list_pickup_changes, and schoolpass_list_dismissal_locations.

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: this is for retrieving authorized pickup drivers on the parent account. It does not name alternatives or exclusion criteria, but the function and scope are unmistakable, and sibling tool names reinforce when this tool is appropriate.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds examples of change types and the default date, but does not describe return format, pagination, or other behavioral traits beyond the annotations.

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

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

The description is a tight two-part sentence with no wasted words. The scope and examples are front-loaded, and the required parameter note is clearly appended.

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 with a fully documented schema and annotations covering safety, the description is nearly complete. It does not explain the response shape or pagination, but no output schema exists and the parameter schema already covers response-shaping options like view.

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 date, view, and student_id semantics thoroughly. The description adds only the date default and the student id requirement, which are already stated in the schema, 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?

States a clear verb (List) and resource (pickup/dismissal changes), scoped to a student and date. The domain examples (early pickups, late arrivals, carpool moves) make the resource concrete and distinguish it from submit/cancel dismissal change 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 implies the tool's use case and states that a student id is required, but it gives no explicit when-to-use guidance or alternatives. With sibling tools like submit_dismissal_change and cancel_dismissal_change present, an agent gets only an implied sense of when to list rather than modify.

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

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

The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds a useful behavioral detail: it defaults to the signed-in parent. It does not contradict annotations.

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

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

The description is one efficient sentence that front-loads the core action and key result fields. 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 read-only list tool with one optional parameter, the description gives the essential result fields and a key default behavior. There is no output schema, but the listed fields provide enough context for an agent to understand what will be returned.

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 is fully documented in the schema, including its enum and detailed explanation of compact vs. full response shapes. The description adds no parameter information, but the schema carries the burden, 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 states a specific verb and resource: list students linked to the parent account, and names the returned fields. It clearly identifies what the tool does, though it does not explicitly contrast it with sibling tools like schoolpass_list_drivers or schoolpass_list_pickup_changes.

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 intended use is implied by the description: call this when you need a parent's linked students and their details. However, it gives no explicit guidance about when to prefer this over sibling tools or any 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?

Goes well beyond the destructiveHint/openWorldHint annotations: it discloses the elicitation-vs-preview two-step confirmation contract, that phase one makes no change, how the confirmToken is bound to previewed arguments and the day as read, and that a stale day is refused with a fresh preview. It also explains verified:true/false and warns not to resubmit when verification fails.

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-loads the purpose and the confirmation model, then the verification semantics, then id sourcing — a logical order with dense, information-bearing sentences. It is long and somewhat repetitious around the confirmToken/verified behavior, but little is pure padding.

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

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

For a destructive, open-world mutation with no output schema and 11 parameters, the description covers the full lifecycle: id sourcing, confirmation gating, submission, and post-write re-read verification including the failure interpretation. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is already 100%, so the baseline is 3, but the description adds cross-tool provenance for student_id and move_to_id and clarifies confirmToken usage (never on first call, never invented) beyond the schema's note. It does not add syntax detail for the remaining optional fields, which the schema already covers.

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

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

States a specific verb+resource (submit a dismissal/arrival change for a student on a single date) and enumerates the concrete change kinds it covers (location, carpool, early dismissal, late arrival, absent). The 'single date' scope distinguishes it from list_pickup_changes and its inverse sibling cancel_dismissal_change.

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?

Explains the confirm-gated invocation flow in detail and points to the sibling tools that source required ids (schoolpass_list_students for student_id, schoolpass_list_dismissal_locations or the calendar for move_to_id). It does not explicitly state when to prefer this over cancel_dismissal_change or list_pickup_changes, so exclusions are absent.

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

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

The annotations already declare readOnly, idempotent, and openWorld hints, and the description does not contradict them. It adds meaningful behavioral context by disclosing that it may run the login bootstrap on first use, which an agent would not infer from the schema alone.

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: the first states what is returned, and the second discloses the bootstrap side effect. No filler, no repetition of schema data, and the most important 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?

For a no-parameter, read-only identity tool, the description is complete: it names the returned fields, references the authentication context, and covers the only relevant behavioral nuance (login bootstrap). The lack of an output schema is mitigated because the return values are explicitly listed.

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

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

The tool has zero parameters, so the baseline is 4 and there is no parameter-description burden to meet. The description wisely focuses on return contents rather than inventing unnecessary parameter 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 clearly names the verb ('Return'), the resource ('the parent account this server is signed in as'), and the exact payload fields (member id, user type, name). This distinguishes it from siblings like get_profile or list_students, since it specifically targets the server's current authenticated identity.

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 context is clear: this is the tool to call when you need the server's signed-in parent identity. It also hints at a bootstrap behavior ('Runs the login bootstrap if it has not run yet'), which gives useful sequencing context. However, it does not explicitly state when not to use it or mention an alternative sibling.

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