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

Annotations already establish readOnly, idempotent, closed-world behavior, so the remaining burden is light. The description adds genuinely useful context beyond that: the return shape is IDs plus page numbers, and question text is deliberately omitted for NCTB copyright reasons, which prevents a caller from wrongly expecting content.

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 what is returned, followed immediately by the critical constraint and the workaround. No filler and nothing dangling.

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 6-parameter, fully optional list tool with no output schema, the description covers return content, the copyright limitation, and the alternative path adequately; per-parameter defaults are carried by the schema. The only minor gap is behavior when no id or chapter is supplied.

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 high at 83%, so baseline is 3, but the description earns a bump by decoding the cryptic enum values — mcq, cq, sq, num become multiple choice, creative/সৃজনশীল with parts ক-ঘ, short answer, and numerical. That mapping is meaning not present in the schema itself.

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 pair — listing end-of-chapter exercise items and in-chapter worked examples — and enumerates the four exercise kinds. It clearly distinguishes itself from siblings like get_topic or list_chapters by being about the exercise/example inventory rather than curriculum content.

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 follow-on route when the caller needs actual question text: read it via pdf_page, or author your own practice questions. It does not explicitly state when to prefer this over the other four siblings, but the resource scope makes that nearly self-evident.

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=false, so the safety profile is covered. The description adds the useful resolution semantic that any ID nested inside the chapter will work, but is silent on what happens when a chapter has no listed objectives, on the response shape, and on behaviour when called with no parameters at all (all five are optional).

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, front-loaded with what is returned and followed by the addressing guidance. The bilingual quote earns its place by making the resource unambiguous, and nothing is 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?

With no output schema, the description carries the burden of saying what comes back, and it does convey that the result is the chapter-opening learning outcome list. The remaining gaps — no-match behaviour and the all-optional parameter situation — are minor for a simple read-only leaf 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 80%, so the schema already documents id, class, subject and version, including defaults. The description restates the two accepted addressing modes but adds no syntax or fallback detail beyond the schema, and the unannotated `chapter` parameter is not clarified.

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 concrete resource — the learning outcomes printed at the start of an NCTB chapter — and even quotes the recurring heading in both Bangla and English, so an agent can recognise it immediately. It does not explicitly contrast itself with siblings like get_topic or list_chapters, which would be the only thing separating a 4 from 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?

Usage context is only implied: it says how to address a chapter (ID anywhere inside it, or chapter number with subject/version) but never states when to choose this over get_topic or list_chapters, nor any exclusions or prerequisites. The caller is left to infer that this is the leaf lookup once a chapter is identified.

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=false, so safety and determinism are covered. The description adds genuinely new behavior: each ID kind returns different structure (sections, subtopics, neighbours), every result carries an official PDF page and a verified flag, and textbook text is explicitly out of scope. It is silent on what happens with an invalid or ambiguous ID, which is the main residual 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?

Three sentences, front-loaded with the returned-resource description and ending on the important scope boundary. The first sentence is long and parenthetical-heavy, embedding three item types in one clause, which makes it dense on first read 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?

For a tool where all six parameters are optional, the description does the essential work of explaining that some addressing scheme must be supplied and that two schemes exist. With no output schema, it also correctly sketches the return shape (page number, verified flag) and the scope boundary. Missing are failure modes for unknown IDs and any note on how the topic's "neighbours" relate, leaving a small but real gap for a zero-required-parameter 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 coverage is 100%, so all six parameters are already documented, which sets the baseline at 3. The description does add structural meaning the schema cannot express: that id and the chapter/topic/subject/version combination are alternative addressing paths, and it gives concrete example ID strings. That relationship between parameters is the main value added, but per-parameter syntax is still carried by 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?

"Details for one curriculum item" names a specific resource, and the description enumerates the three ID kinds (chapter, topic like "3.2", objective/worked-example/exercise) with the shape of each result. It does not name the siblings it is distinct from, but the granularity of what each item type returns implicitly separates it from search_curriculum and list_chapters.

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

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

The description explains the two invocation modes clearly: pass an nctb: ID, or pass chapter plus optional topic with subject/version. That is invocation guidance rather than selection guidance — no sibling tool is named, and the only implicit exclusion is "Does not return textbook text," which suggests a different tool without pointing to it.

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

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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuinely new context: the v0.1 scope limit (Class 9-10 / SSC Physics, 2026 edition only) and the warning that bn and en are separate books with different page numbers. It stops short of describing ordering or result size, but the scope constraint is the load-bearing disclosure 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?

Three tight sentences: entry-point cue first, payload and scope second, downstream routing last. No filler and 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?

With no output schema, the description compensates by listing the returned fields, and the v0.1 edition limitation prevents an agent from assuming broader coverage. Only the ordering of results and pagination behavior go unmentioned, which is minor for a chapter listing of a single book.

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 each parameter already documents examples, defaults and the bn/en page-number distinction. The description only echoes the class range and the two available versions, adding no syntax or semantics beyond the schema, so 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?

Names a specific verb and resource ("Lists the chapters of a Bangladesh NCTB textbook") and enumerates the payload (chapter IDs, titles, page ranges, topic counts). The leading "Start here" positions it as the entry point relative to get_topic, get_objectives and get_exercises, so an agent can place it in the sibling set without opening a 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?

"Start here" gives an explicit sequencing instruction and the second sentence names the exact downstream tools to use with the returned IDs. What is missing is any contrast with search_curriculum, the other plausible entry point, and no when-not condition is 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?

Annotations already declare readOnly, idempotent and closed-world, so the safety bar is lower. The description adds real context beyond them: the searchable fields, that hits are small and carry IDs and page numbers, and the non-obvious behavior that query language determines which book version is searched by default. It does not mention empty-result behavior or pagination, 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 tightly packed sentences, front-loaded with purpose and examples, then search scope plus return shape plus handoff, then the version nuance. The bilingual example strings earn their length by demonstrating the query format directly. No filler or restated field names.

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 carries the return-shape burden and does so (small hits with IDs and pages). It covers scope, bilingual behavior, follow-up routing, and version defaults, and the remaining details (limit, subject defaults) live fully in the schema. Nothing an agent needs in order 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 baseline is 3, but the description genuinely adds meaning the schema cannot: the interaction between query language and the version parameter's effective default. The bilingual query examples also clarify what the query parameter accepts in practice. The limit and subject defaults are left to the schema, which is fine.

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 gives a specific verb and scope: "Find where a concept is taught," then enumerates exactly what is searched (chapter titles, section headings, learning objectives). It also names what it returns (small hits with IDs and pages) and routes detail lookups to get_topic, so an agent can distinguish it from list_chapters and get_objectives without opening schemas.

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

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

It states the use case clearly (locating where a concept is taught) and gives an explicit follow-up path: "call get_topic on an ID for details." It also explains the version defaulting rule with a conditional ("unless version is set"). It stops short of stating when NOT to use it (e.g., browsing all chapters, which is what list_chapters is for), so it is clear but not fully exclusionary.

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