Matematyka Gryzie

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context that the annotations cannot: it discloses the payload's shape (description, contents, access variants, prices) and that purchaseUrl points to checkout, which matters since 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?

A single front-loaded sentence: resource and lookup key first, then a compact enumeration of what comes back. No filler, no repetition of the 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?

Because there is no output schema, the description carries the burden of describing the return value, and it does so concretely (variants, prices, purchaseUrl). It omits what happens for an unknown id or slug, which would be the remaining useful detail for a single-item lookup 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?

Only one parameter, and the schema already documents it fully ('courseId albo slug strony kursu') at 100% coverage, so the baseline is 3. The description restates the same duality and adds that the value originates from search_courses, but contributes no format or validation detail beyond the schema.

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

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

The description names a specific resource and scope ('Jeden kurs po id albo slugu') and explicitly ties the identifier back to search_courses, so an agent can distinguish it from the search/list siblings. The verb itself is implicit rather than stated, which keeps it just short of a 5.

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

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

'po id albo slugu z search_courses' establishes the prerequisite chain: obtain an id from search_courses, then call this. There is no explicit when-not or statement about alternatives for fetching course details, but the usage context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive behavior, and closed-world scope. The description adds useful context beyond annotations: the data provenance is the CKE communiqué and the tool includes result, additional, and retake dates, with a mandatory source-linking instruction.

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 short sentences with no wasted wording. The content scope is front-loaded, and the required source-link instruction follows directly.

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 lookup with annotations covering safety and idempotency, the description adequately explains the data source and scope. It is incomplete on parameter behavior and does not clarify how the optional subject and examLevel filters affect results.

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

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

Schema description coverage is 0%, and the description does not explain the subject or examLevel parameters, their optionality, enum meaning, defaults, or filtering behavior. It only broadly mentions exam types, leaving the parameter semantics to be inferred from enum values.

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

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

The description states a specific resource and scope: start dates and times for egzamin ósmoklasisty and matura from the CKE communiqué, plus result, additional, and retake dates. It is clear what the tool returns, though it does not explicitly distinguish itself from siblings such as get_exam_task or search_exam_papers.

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 content, and a concrete output requirement is given: always provide the student with a link to the CKE communiqué (source). However, there is no explicit when-to-use guidance or named alternative among 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?

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds genuinely new behavior: the no-questionNumber list-return mode, duplicate-number handling via position, LaTeX delimiters ($ vs $$), fully-qualified image URLs, and the instruction to surface pageUrl to the student. This is context an agent could not infer from structured fields.

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

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

Front-loaded with what the tool returns, followed by the conditional-return rule and the format/usage notes. Every sentence carries actionable information; nothing is redundant with the schema or annotations.

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, so the description carries the burden of describing return contents, and it does: task statement, step-by-step solution, final answer, LaTeX-delimited formulas, absolute image URLs, plus the list mode. An agent has everything needed to call it and interpret the result.

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

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

With 50% schema coverage, the description compensates by explaining where slug originates and how questionNumber versus position interact, going beyond the schema's own notes. examLevel's four enum values are self-documenting in the schema, so their absence from the description is minor.

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: fetch a single math exam task (identified by slug from search_exam_papers) including the statement, step-by-step solution and final answer. It is clearly distinct from the sibling search_exam_papers, which produces the slug this tool consumes.

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 the slug comes from search_exam_papers, and explains the important branch: without questionNumber it returns the task list, and when numbers repeat you must pass position from that list. No explicit 'when not to use' or exclusion statements, but the retrieval workflow is unambiguous.

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 safety (read-only, idempotent, closed-world), so the description's job is to add operational context — and it does: it enumerates the returned metadata and discloses that the PDF itself is not fetched here but downloaded on the page after submitting an email address. It stops short of saying what happens for an unrecognized or omitted exam level.

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 sentence that front-loads what the tool returns before adding the download caveat, with no filler. Slightly compact for the amount of information packed in, but nothing is wasted.

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 does cover the returned fields, which is the main gap it needed to fill. However, for a tool with an optional enum parameter it leaves the no-argument case undefined, and the Polish-only text may be inconsistent with the English sibling tooling.

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

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

Schema coverage is 0% and the single parameter is undocumented, so the description must compensate. It partially does by naming the three exam tiers in prose, which maps loosely onto the enum values, but it never references the examLevel field by name, never says selection is optional, and gives no default behavior.

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

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

Names a specific resource (CKE math formula sheet cards) and the exact fields returned (name, page count, page where the card appears), scoped to three exam levels. It is clearly distinct from siblings like get_exam_task or search_exam_papers, though the Polish phrasing assumes the agent understands the domain term 'karty wzorów'.

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 by listing the exam levels covered, but never states when to prefer it over get_exam_dates or search_exam_papers, nor that the parameter is optional. It does add a useful caveat that the actual PDF is retrieved elsewhere, which implicitly bounds the tool's scope.

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 bar is covered; the description adds the non-obvious fact that the actual booking happens off-tool on bookingUrl and that the agent must not attempt enrollment. It does not describe response format beyond mentioning bookingUrl, but that is the main behavioral point here.

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 tight sentences: content description first, critical usage constraint second. No filler, nothing repeated from the schema or annotations.

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 info tool with no output schema, the description covers everything an agent needs: what the payload contains and the required follow-up action (share the link, do not book). Nothing material 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?

The tool takes zero parameters, so the baseline is 4. The description correctly implies a parameterless call and instead highlights bookingUrl as a returned field the agent should surface.

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

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

The description names a specific resource (free telephone consultation with an advisor) and enumerates exactly what the response contains: subject matter, how it runs, and the booking URL. This clearly separates it from the sibling tools, which all deal with courses, exams, funding or guarantees.

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 an explicit behavioral rule — never sign the user up yourself, hand over the link and let the student/parent pick a slot and submit their data. That is a real when/how-to-use instruction, though it does not explicitly contrast with sibling tools or state 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 readOnly/idempotent/non-destructive, and the description adds real behavioral context: enrollment is closed, the agent must not submit an application or redeem a code on anyone's behalf, and it should surface pageUrl so the parent completes the action themselves. That is a meaningful constraint beyond the structured hints, though it does not describe the response 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?

Content is front-loaded: what is covered first, then when to use it, then the operational constraints. The sentences are dense but each carries information; a mild tightening would be possible but nothing is filler.

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

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

For a read-only lookup with one optional enum parameter, no output schema and rich annotations, the description covers what is returned (the four funding/discount topics and eligibility/current period), who may use it, and the hands-off rule. An agent has everything needed to call 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 coverage is 100% and the enum values carry their own Polish descriptions, so the schema already does the heavy lifting. The description's only implicit link is that the four topics map to the four section values, and it never explicitly says that omitting section returns everything — though the schema does.

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

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

The description names the exact resource (course funding and discounts) and enumerates the four sub-topics it covers: IKR Junior scholarship, Large Family Card discount, multi-course discount and discount codes. This is clearly distinguishable from every sibling tool (course search, exam dates, formula sheets, consultations).

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 explicit trigger phrases: use when a parent asks about course funding, IKR Junior, tutoring scholarship, Large Family Card, or a multi-course discount. It also states a when-not condition: IKR Junior enrollment is closed, so help only families who already hold the scholarship. It names no alternative sibling tool, which keeps it from 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?

Beyond the read-only annotations, the description discloses that responses are verbatim regulation text, warns that Zdana Matura only covers basic-level mathematics and does not guarantee a result, and instructs the agent to quote terms, avoid summarizing or overpromising, and supply termsUrl. This adds substantial behavioral context for safe, accurate use.

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 front-loaded with the substantive policy areas, followed by concrete usage triggers and then the quoting constraint. Every sentence contributes either content scope, invocation guidance, or behavioral rules, with no filler.

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 retrieval tool with one optional enum parameter and no output schema, the description is complete: it explains what verbatim material is returned, when to use it, how to present it, and what URL to include. Nothing needed for correct invocation or response handling 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 100%, and the single section parameter is fully documented in the schema, including the behavior when omitted. The tool description itself does not add further parameter semantics beyond that, 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 specifies the exact content returned: verbatim policy statements about the 30-day satisfaction guarantee, the Zdana Matura program, and installment/deferred payment via PayU. It clearly distinguishes the resource from sibling tools like get_course, get_exam_dates, and get_funding_options by focusing on regulations and payment terms.

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 explicit triggering cases: when a parent asks about refunds, returning a course, the pass guarantee, what happens if the child fails, installments, or deferred payment. It does not name alternative tools or exclusions, but the intended usage is otherwise clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: that the tool returns signup URLs and that the student registers on that page themselves, which tells the agent not to look for an enrollment tool. It does not say how many items come back or whether results are ordered by date.

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 short sentences with zero filler; the resource definition comes first and the external-signup caveat second. Nothing is redundant, though the phrasing is a field enumeration rather than a purpose statement, which slightly slows front-loading.

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?

There is no output schema, so the description carries the return-shape burden and does describe the four fields returned. For a one-parameter read-only list tool this is close to sufficient; the only real gaps are the count/ordering of results and confirmation of the optional subject filter.

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 'subject' is never mentioned in the description, and schema description coverage is 0%. The enum values are largely self-explanatory subject names, so ambiguity is low and the baseline for a filter with a self-documenting enum is a 3, but the description does not confirm that subject filters the list or that omitting it returns all subjects.

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: free online trainings run by the platform's teachers, and enumerates the returned fields (topic, instructor, nearest date, signup page). It is clearly distinguishable from search_courses or get_course, though it never names the closest sibling get_free_consultation, so the agent must infer the free-training vs free-consultation split.

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 only implied: the reader infers this is a browse-list tool for free webinars. The sentence 'Uczeń zapisuje się sam na stronie (signupUrl)' usefully signals that enrollment is external and should not be attempted via a tool, but there is no explicit when-to-use versus get_free_consultation or search_courses, and no statement that the subject filter is optional.

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, non-destructive, and closed-world behavior, so safety is covered. The description adds useful behavioral context: it should question the user sequentially, it returns priced courses with links, and it should supply formula information after a failed matura.

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

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

The description is short and mostly front-loaded: it first establishes the matching behavior, then the questioning sequence, then the return values and special formula case. It avoids repetition, though the external quiz reference could be less prominent for agents unfamiliar with that path.

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

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

For an 8-parameter recommender with a nested subjectLevels object and no output schema, the description is largely complete: it covers the interaction flow, main parameters, return contents, and the retake/formula exception. The only notable omission is bookCourseId, but the schema fully documents 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?

Schema description coverage is 100%, so the schema already explains most parameters. The description adds value by specifying the elicitation order for audience, school, class, goals, subjects, and subject levels, and by emphasizing formula after a failed matura; bookCourseId is left to the schema.

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

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

The description states a specific matching/recommendation behavior: it elicits student/parent details sequentially and returns courses with price and course-page link. It also distinguishes this from raw search by referencing the same matching logic as the /dopasuj-kurs quiz, though it does not explicitly contrast with sibling search_courses.

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 an implied usage flow by listing the questions to ask in order and notes the special case for a failed matura/retake. However, it does not explicitly say when to use this tool instead of search_courses or get_course, nor does it state 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 cover read-only/idempotent/non-destructive, but the description adds real behavioral facts: prices are in grosz in PLN, every result carries a pageUrl that must be surfaced to the student, and there is a business policy against 1:1 tutoring. Pagination, result limits and sorting are not mentioned.

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?

Four short sentences, front-loaded with what is returned and then how to filter, with the operational rule last. Dense and free of filler, though the register shift and mixed Polish/English phrasing make it slightly less crisp.

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, so the description carries the return-value burden; it discloses the two most important output facts (price unit and pageUrl). For a read-only filtered search with fully documented params this is nearly complete, missing only result ordering and limits.

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 every parameter, including the three enums, is documented in the schema itself. The description only lists the filter names and repeats that q matches name and description, so it adds little beyond structured data — baseline 3.

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 resource precisely: courses and packages of this brand, with the price as shown on the course page and amounts in grosz (PLN). The search verb is only implied by the filter list, and no sibling tool (recommend_course, get_course) is named for contrast, so it falls short of a 5.

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

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

It gives explicit usage context: list the available filters, tell the student to use pageUrl, and a clear when-not rule (no 1:1 tutoring lessons — recommend a course instead). What is missing is routing between this and sibling tools such as recommend_course or get_course.

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 safety (readOnly, idempotent, non-destructive, closed-world), and the description adds important behavior: without examLevel it returns available levels and subjects, and math papers live on a separate site. It also instructs the agent to provide the student with the paper's pageUrl. It does not cover pagination or result shape, but those are secondary for a read-only search 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 compact and front-loads the resource type and source context. The fallback rule and final instruction are clear, though the domain-specific parenthetical adds density without much extra structure.

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

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

The description covers the key missing-parameter branch and tells the agent what to hand to the student. It is less complete on year and limit semantics, and without an output schema it only partially characterizes what a normal search returns.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It mentions examLevel and subject behavior, including the special missing-examLevel fallback, but it entirely omits year and limit semantics, leaving half the parameters undocumented.

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 as CKE and mock exam papers with solutions, including the source websites and newest-first ordering. It is distinguishable from siblings like get_exam_task and get_exam_dates, though it does not explicitly name those alternatives for contrast.

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 for finding exam papers, and the description gives a useful fallback branch when examLevel is missing. However, it does not explicitly say when to use this tool instead of get_exam_task, get_exam_dates, or get_formula_sheets.

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