AI School by Lilly Tech Systems

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 that the response includes the 'full lesson list', which is useful return-content context. It does not disclose error behavior or edge cases, but for a read-only getter this is acceptable.

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 sentence that front-loads the verb and resource, then gives the purpose. Every word earns its place; no redundant 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 simple one-parameter read-only tool, the description is complete: it states input slug, output (full lesson list), and the purpose. No output schema exists, but the description adequately conveys the return shape. Slightly more detail on lesson-list contents would push it to 5, but nothing critical 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%, with the slug parameter already described as 'Track slug, e.g. "rag"'. The description adds no additional parameter meaning beyond what the schema provides, 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 opens with 'Get one track with its full lesson list', a specific verb and resource that clearly states what the tool does. It implicitly distinguishes itself from siblings: list_tracks returns multiple tracks, read_lesson returns a lesson, search_lessons searches; this tool returns a single track with its lesson structure.

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 a clear when-to-use context: 'so you can see the structure of a course and pick the right lesson to read'. It doesn't explicitly name alternatives or exclusions, but the intended use case is evident and sufficient for an agent to route correctly.

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, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful context about substring matching on title/slug and the track concept, but does not disclose return formatting, ordering, or pagination 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?

Three concise sentences with no filler. The main action and filtering behavior are front-loaded, the domain context is brief, and the usage guidance 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 low-complexity, read-only list tool with two optional parameters, the description covers what the tool returns, how to filter, and when to use it. It lacks explicit return-shape detail, but 'List tracks' plus the schema-provided limit description keep it sufficiently complete.

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

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

The schema already documents both parameters at 100% coverage, so the baseline is 3. The description adds meaningful semantics by specifying that the filter applies to 'a substring of the title or slug,' going beyond the schema's generic 'Optional substring filter' text.

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 action and resource: 'List AI School course tracks' with optional substring filtering. It clearly distinguishes tracks from the sibling lesson tools by adding 'Each track is a structured course on one subject' and 'before drilling into its lessons.'

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 a clear usage context: 'Use this to find the right course before drilling into its lessons.' It implies this is for course discovery and that lesson-level tools are for later, but it does not explicitly name when not to use get_track or search_lessons.

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 and idempotentHint, so the description need not repeat safety. It adds useful behavioral context beyond annotations: the return value is 'readable markdown-ish text with headings and code blocks,' which informs the agent about output format.

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

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

Two sentences with no filler. The primary action and input are front-loaded in the first sentence, and the second sentence efficiently describes the output format. Every sentence earns its place.

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

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

For a simple one-parameter read-only tool, the description covers the input provenance, the action, and the output format. Annotations handle safety, and no output schema is needed because the return shape is already described. Nothing critical 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 adds meaning to the single 'url' parameter by specifying its provenance ('as returned by search_lessons or get_track'), which clarifies where a valid URL value comes from beyond the schema's static description.

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

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

The description states a specific verb ('Fetch'), a clear resource ('full text of a lesson'), and the input mechanism ('by its URL'). It also references sibling tools as the source of the URL, which differentiates this tool from search_lessons and get_track.

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 conveys clear context for use: you need a lesson URL as returned by search_lessons or get_track, and you want the full text. It does not explicitly list when-not-to-use or compare alternatives, but the usage scenario 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 declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the useful behavioral detail that results are lesson titles and URLs, and scopes the search across the given curriculum topics. It does not cover ranking or pagination, but those are minor for this kind of 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 three sentences with no filler: scope/curriculum, return value, and usage guidance with the read_lesson follow-up. It is front-loaded with the core action and remains highly readable.

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 search tool with complete parameter documentation, safety annotations, and a clear follow-up sibling, the description covers purpose, usage context, return shape, and workflow. Nothing essential for an agent 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 description coverage is 100%: 'query' and 'limit' are both documented in the input schema. The description does not add meaning beyond the schema, so the baseline 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 names a specific verb ('Search'), a specific resource ('AI School curriculum'), and the concrete output ('matching lesson titles and URLs'). It also distinguishes itself from siblings by framing read_lesson as the follow-up step rather than the search itself.

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 explicitly states when to use the tool: 'Use this before answering an AI-topic question when a concrete, citable lesson would help.' It also names the next step (read_lesson), though it does not explicitly describe when to prefer list_tracks or get_track instead.

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