Australia Wide First Aid courses

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

Annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds genuinely useful behavioral context about the scope of returned data (assessment method, certificate issue timing and currency period), which tells the agent what questions this call can answer.

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 the payload summary front-loaded, then the use case, then the parameter hint. No filler, no repetition of the title, and each sentence carries distinct information.

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

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

An output schema exists, so return structure need not be spelled out, yet the description still conveys the semantic content of the response. For a single-parameter read tool with full annotations, nothing an agent needs to invoke 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 baseline is 3; the description goes beyond the schema by clarifying that the value is the id obtained from list_courses and that a unit code such as HLTAID011 is also accepted. That resolves the ambiguity of an undocumented identifier format.

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 ('Full details for one course') and then enumerates the exact payload (coverage, assessment, pre-course work, what to bring, certificate issuance and currency). This clearly distinguishes it from the sibling list_courses, which only lists courses rather than detailing one.

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 a concrete use case ('answer whether a course meets a workplace or childcare requirement') and tells the agent where the key input comes from ('course is the id from list_courses'). It does not explicitly state when NOT to use it or name an alternative tool for adjacent needs (e.g. search_sessions for scheduling), so it falls short of a full routing statement.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds the topic-filtering behavior, but doesn't explain how topics are matched (keyword/fuzzy) or the return shape, though an output schema 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?

Front-loads the resource and topic list, then the parameter behavior. The topic enumeration is long but informative; no filler sentences.

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?

Adequate for a simple read-only lookup with a rich output schema, but omits matching semantics for the topic and any guidance on fallback when no FAQ matches.

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 the schema describes the topic parameter with an example, so the description adds little beyond repeating 'pass a topic'. 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?

Clearly states it retrieves FAQs with answers, and enumerates concrete topics it covers. It distinguishes itself from siblings (courses, sessions, booking) by being the Q&A resource, though it doesn't explicitly name a 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: pass a topic for relevance, omit for all. But it gives no guidance on when to prefer this over siblings like get_course_details or search_sessions for answering course questions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds that courses are nationally recognised and lists returned attributes (unit code, price, duration, delivery, renewal), but the output schema already carries those fields, so added behavioral value is modest.

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 core purpose in the first clause and ends with a routing instruction. The enumeration of returned fields is somewhat redundant with the output schema, slightly diluting conciseness, but overall it's 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?

With an output schema present, return-value detail needn't be in the description; it focuses on purpose and usage. It's complete enough for a no-arg catalog tool, though it doesn't note ordering or completeness guarantees of the listing.

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

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

The tool takes zero parameters, so the baseline is 4. There are no parameter semantics to document and the description appropriately doesn't attempt to.

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

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

States a specific verb (List) and resource (nationally recognised first aid and CPR courses) with clear scope (Australia Wide First Aid). It implicitly distinguishes itself from get_course_details by being the catalog-level listing rather than a single-course lookup.

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 says to use it to turn a need like 'first aid for work' or 'childcare certificate' into a course id for the other tools, which gives a clear entry-point context. It doesn't name a when-not condition or explicitly contrast with get_course_details, but the usage context is well defined.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond them: results are grouped by state, distance is reported in km, and venue ids feed search_sessions. It omits pagination and default-listing behavior, which keeps it from a 5.

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

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

Three sentences, all front-loaded: purpose first, then the two parameter modes, then the id hand-off. No filler and every clause carries information an agent will use.

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

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

With an output schema present, the description need not explain return values, and it still usefully mentions grouping and distance units. The main remaining gap is disambiguation from the similarly shaped search_nearby_sessions sibling.

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 all three parameters are already documented, including 'state' being ignored when 'near' is given. The description reinforces the near/state interplay and the postcode-or-suburb format but adds little syntax or semantics the schema lacks. Baseline 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?

States a specific verb+resource: 'List training venues with address, grouped by state,' and ties its output to a sibling by noting the venue id is 'the location for search_sessions.' It does not, however, distinguish itself from search_nearby_sessions, which the 'near' mode appears to overlap with.

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 mode-selection guidance: pass 'state' to narrow to one state, or 'near' to get the closest venues with distance. It stops short of explaining when to prefer this tool over search_nearby_sessions/search_sessions, leaving the closest alternative unresolved.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds meaningful behavior beyond them: results are merged 'soonest first,' each venue carries a distance in km, and an ambiguous suburb produces candidate states requiring a follow-up call. That is useful operational 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?

Three dense sentences with no filler; the core behavior and the required-input caveat are front-loaded. It is compact for the amount of nuance conveyed, though the last sentence is somewhat long.

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?

An output schema exists, so return values need not be spelled out, and the annotations carry the safety profile. The description still supplies the ordering, distance unit, and the recovery flow for ambiguous suburbs, leaving nothing an agent needs 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?

Schema description coverage is 100%, so all six parameters are already documented in the schema, including defaults, caps, and formats. The description reinforces the required nature of 'near' but adds no syntax or format detail beyond what the schema provides, so the baseline 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 states a specific verb and resource: 'Upcoming sessions of one course across the venues closest to a postcode or suburb,' with the added ordering and distance semantics. It is clear what the tool returns. It does not, however, differentiate itself from the sibling search_sessions, which the agent must disambiguate on its own.

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 concrete context: 'near is required: this server can't tell where the person is, so ask them for their postcode or suburb,' and describes the retry path when a suburb is ambiguous. That is real when-to-use guidance for a required input. It stops short of stating when to prefer this over search_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?

Annotations already cover readOnly/idempotent/non-destructive/closed-world, so the bar is lower. The description still adds real behavioral context beyond them: result ordering, the return fields, the caveat that seat counts are shown as the site displays them (e.g. '5+'), and that session_id chains into start_booking.

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, both front-loaded: the query scope and ordering come first, the routing rule second. No filler or restated name/title.

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 a full schema, an output schema, and rich annotations, the description supplies the missing pieces an agent needs: purpose, ordering, the venue-vs-suburb routing rule, and the downstream session_id link. Only minor operational details like empty-result behavior are absent.

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 every parameter (course, location, limit, date_from, date_to) is already documented with defaults and caps. The description adds no parameter-level syntax or format detail, so the baseline 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?

States a specific resource (upcoming sessions of one course at one venue), the ordering (soonest first), and the fields returned. It explicitly differentiates itself from search_nearby_sessions by the venue-vs-suburb input distinction.

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

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

Names the alternative tool and the exact condition that selects it ('If the person gave a suburb or postcode rather than a venue, use search_nearby_sessions instead'). The agent does not have to infer routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered; the description adds the operationally critical context that nothing is actually booked, no seat held, no personal or payment details taken, and the user completes on the enrolment site. That prevents an agent from falsely telling a user they are booked — information no annotation conveys.

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 action is front-loaded in the first sentence, followed by the handoff flow, the critical "this tool books nothing" warning, and the group exception. No sentence is filler — each one guards against a plausible agent error.

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?

An output schema exists, so return-value explanation is unnecessary; the description covers the input source, downstream user flow, capability limits, and the group alternative. Nothing an agent needs to call and message 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% and the single parameter is fully documented in the schema itself ("The session_id from a search_sessions or search_nearby_sessions result"). The description reinforces the provenance of the id but adds no syntax, format, or constraint beyond what the schema already provides, so the baseline 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?

States a specific verb and resource ("Get the link that books one place in a session") and immediately names the sibling tools that produce the required input, search_sessions and search_nearby_sessions. An agent can distinguish this from the search tools without opening any 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?

Explicitly states where the session_id comes from, what to do with the result (give the link to the person), and the exclusion case for groups ("book each person separately or use the corporate enquiry page"). Both the when and the when-not are covered.

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