AnySkills

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the percentage counts only mandatory published lessons, last-access information, cohort completion share, and the privacy rule that names only appear on stage 3. These details tell the agent what kind of data to expect and how it is computed beyond what any structured annotation provides.

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 packs several distinct facts into three compact sentences without redundancy. It leads with the central output (per-student percentage), then adds recency data, cohort-wide completion, and the anonymization rule. Every sentence carries a distinct piece of useful information; 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?

For a read-only tool with a single parameter and no output schema, the description communicates what data will be returned: student name or placeholder, percentage, last visit, days since, and completion share. It does not document the exact response format or JSON shape, but with no output schema, giving the natural-language semantics of each field is reasonable and sufficient for an agent to call the tool 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?

There is only one parameter, cohort_id, and the schema title says 'Cohort Id' while the description implies it identifies the cohort. With schema description coverage at 0%, the description partially compensates by making clear the output is for the cohort's students, but it does not spell out where to find cohort_id or that it must be an existing cohort. Baseline for one clearly-implied parameter is acceptable.

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 and resource with precise scope: per-student progress in a cohort. It details exactly what is computed (course percentage, last activity, days since, completion share), how the percentage is calculated (mandatory published lessons), and the name anonymity rule by stage. Even without pushing the title, it does not merely restate 'cohort progress'—the resource is well delimited and distinct from siblings such as stuck_students or get_school_summary.

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 does not explicitly say when to use this tool versus alternatives and gives no exclusions or alternative names. However, its level of detail clearly implies that it is the cohort-level progress view: to inspect completion and activity across a cohort's students, use this tool. It does not instruct the agent when not to use it (e.g., for a single student or for school-wide stats), so the guidance remains implicit.

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 are mostly false hints, so the description carries the behavioral burden. It discloses key behaviors: draft visibility, publication dependency, unlimited drafts, access-mode semantics, author identity as key owner, and idempotent replays with the same Idempotency-Key. The conditional idempotency does not contradict idempotentHint=false because it only applies when the client supplies that key.

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 dense sentences, each adding a distinct fact: draft status, publishing step, tariff policy, access modes, ownership, and idempotency. The most important behavior is front-loaded, and nothing repeats what the schema or annotations already provide.

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 creation tool with an output schema and one required parameter, the description covers lifecycle, visibility, access-mode semantics, ownership, and retry behavior. An agent has enough information to decide whether to call it and what to expect.

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 compensate. It fully explains the only non-obvious parameter, access_mode, with all three enum values and their meanings. The title and description parameters are self-explanatory from their names and schema constraints, so their omission is acceptable.

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 starts with a specific verb and resource: it creates a course draft, not a published course, and clearly states that the course is invisible to students until published via `publish_course`. This distinguishes it from publish_course and from the sibling create_lesson/create_module/create_test tools. The access-mode details reinforce the tool's scope.

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 clear usage context: use this tool to create a draft, then publish it with `publish_course`, and drafts are unlimited on any plan. It does not explicitly enumerate when not to use this tool versus sibling create_* tools, but the resource type makes the main decision obvious.

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?

It discloses key behavioral traits beyond annotations: lesson always goes to the end of the module, unknown blocks are discarded, markup is cleaned, allowed block types are listed, and the document format is Editor.js. This is substantial behavioral context that annotations (only booleans) do not provide.

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 packs a lot of useful detail into a few lines. The Editor.js example is necessary and front-loaded. It could be slightly more structured with separate notes for the `document` parameter, but it is not bloated.

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 output schema exists, and annotation booleans are present. The description covers the key tricky part (`document` format) and mentions where to get a sample (`get_lesson`). It does not cover restrictions on `module_id` or how the lesson kind/test parameter interacts with create_test, but overall it is sufficient for correct invocation.

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 compensate. It thoroughly explains the `document` parameter with a detailed Editor.js example, allowed block types, and test format. Other parameters like module_id, title, kind, is_required, duration_minutes have no descriptions, but their meaning is fairly inferable from names/title; still, the description does not fully cover all param semantics.

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 title states a clear action+resource ('Добавить урок в модуль') and the first sentence says the lesson is appended to the end of the module. The description does not explicitly name sibling update_lesson/create_module, but the resource and placement are clear enough. It loses a point because the tool name and title are nearly identical in meaning, and it does not differentiate the action from update_lesson or create_test in the text.

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 is for creating a lesson and places it at the end of a module; it also mentions 'Образец готового документа отдаёт get_lesson' (a sample document is returned by get_lesson), which informs the agent where to learn more. However, it does not explicitly say when to use this tool versus update_lesson or create_test, nor when not to use 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?

The description adds meaningful behavioral context beyond the annotations: the module is placed at the end of the course, only module metadata is created here, and module order is mutable later. Annotations only indicate a non-read-only mutation, so this placement and scope information is useful.

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 concise sentences with no filler. It front-loads the key placement behavior, then gives the most important sibling-tool pointer and reorderability note.

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 create operation with two straightforward parameters and an output schema available, the description covers what the tool does, where the module is placed, what it does not do (lessons), and how ordering can be handled. Nothing essential is missing for correct invocation.

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 define course_id or title. It only refers to the course and module conceptually, leaving the parameter meanings to self-descriptive names. With low schema coverage, the description should compensate but does not.

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 clear action: a module is appended to the end of a course. It also explicitly distinguishes this tool from create_lesson by noting that lessons are added separately, so an agent can tell what resource this tool operates on.

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 explicitly routes lesson creation to create_lesson ('Уроки добавляются в модуль отдельно, create_lesson'), and it tells the agent that module order can be adjusted later, so ordering is not a concern at creation time. This is clear when-to-use and when-not-to-use guidance.

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 adds meaningful behavioral context beyond annotations: the whole test is created in a single call, question types have specific answer semantics, and placement rules are stated. Annotations already signal a non-read-only, non-idempotent, non-destructive operation, and the description clarifies what the mutation actually does.

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, front-loaded with the core promise, and organized into clear blocks for question types and placement. Every sentence contributes value without 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?

The description covers the most complex parts of the schema: question kinds, correct-answer fields, and placement semantics. It works well with the schema's constraints, though it omits subtle validation guidance such as options being needed for one/many and the meaning of max_attempts=0; with no output schema, a little more would make it fully 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?

With 0% schema description coverage, the description must document parameters. It explains the important nested semantics: kind values, correct_text for text/number, reference_answer and criteria for open, and lesson_id/module_id placement. However, pass_score, max_attempts, and the meaning of weight/is_correct are not addressed, leaving gaps.

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+resource: creating a complete test with questions in one call. It enumerates question kinds and placement targets, making it unambiguous and distinguishable from sibling create_course/create_lesson/create_module 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?

Clear placement guidance is provided: lesson_id places the test as a block at the end of a lesson, module_id as the module's final test, and both or neither are allowed. It does not explicitly name sibling alternatives or state when not to use this tool, so it stops short of 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 readOnlyHint and idempotentHint annotations, the description adds valuable behavioral detail: modules are in order, lessons are in order, each lesson includes type/duration/mandatory flag, and module final tests are named by number. It also discloses what is NOT included, preventing false expectations.

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 focused sentences deliver the core behavior, ordering guarantees, and cross-references to sibling tools. The most important information is front-loaded and 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 read-only single-parameter tool with no output schema, the description fully conveys the return shape: ordered modules, ordered lessons with relevant metadata, and the naming convention for final tests. It also tells the agent where to go for related content, leaving no critical ambiguity.

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 never explains course_id. It does not say how to obtain it, what format is expected beyond the schema's integer type, or that it selects which course to fetch. The parameter is simple, but the description provides no explicit guidance to compensate for the missing schema 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 exactly what the tool returns: one complete course with modules and lessons in order, including lesson type, duration, and mandatory flag. It also distinguishes itself from get_test and get_lesson by naming what those tools cover instead.

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 explicitly routes to get_lesson for lesson text and get_test for module test questions, making the boundaries between sibling tools clear. It also implies the appropriate use case: retrieving the full structural skeleton of a single 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the return format, compatibility with create_lesson, and the legacy empty-document behavior. This is useful, though it does not discuss errors or availability.

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-loaded: it leads with the return format, then the relationship to create_lesson, then the edge case. Every sentence earns its place and no information is redundant.

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 with no output schema, the description is complete enough. It tells the agent what data will be returned, which block types to expect, how to use the result with create_lesson, and what to expect for older lessons. No critical information 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 0%, so the description carries the burden of parameter explanation, but it does not explicitly discuss lesson_id. However, the single parameter is self-explanatory from its name and type, so the lack of description is not a serious obstacle. It adds no extra parameter semantics, but none are really needed here.

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 (lesson) and the format (Editor.js blocks), and names the specific block types returned. It also distinguishes the tool from siblings by noting that the response can serve as a template for create_lesson, making its purpose and scope immediately clear.

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 an explicit use case: the response is suitable as a sample for create_lesson. It also explains the old-lesson edge case where the document may be empty and content lives in blocks. It does not enumerate exclusions or alternatives like update_lesson, but the guidance is sufficient for a read-only retrieval tool.

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 behavior. The description adds useful context by stating that the numbers are real and come from the same key, implying data scoping and authenticity. It also guides the AI’s downstream presentation behavior, which is beyond what annotations provide.

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 each part serves a purpose: the first sentence states the returned data, the second explains invocation timing and presentation, and the third reinforces data authenticity. No redundant wording is present.

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 parameterless read-only summary tool, the description covers what the tool returns, when to invoke it, how to interpret the data, and how to use it in conversation. Annotations handle safety, and the lack of an output schema is mitigated by the explicit field list in the description.

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 and schema coverage is 100%, so there are no parameter semantics for the description to add. The description instead focuses on the return content and usage context, which fully compensates for the lack of parameters.

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 specifies the tool's content: school name, tariff, number of courses and published ones, students, streams, and key permissions. It also distinguishes the tool's role by stating it is called first upon connection, setting it apart from the listed siblings.

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 explicitly says the AI should call this tool first when connecting and use its data to present itself in a human-friendly way. It gives clear context for when to use the tool, though it does not explicitly mention when not to use it or list alternative conditions, so a perfect score is not warranted.

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 mark the operation as read-only and idempotent. The description goes beyond that by disclosing that correct answers are returned, which is unusual and sensitive, and by explaining the permission rationale. It also reveals structural behavior such as question ordering and included fields, adding real context 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 compact and front-loaded: the first sentence states the resource and main contents, the second details question structure, and the third justifies the sensitive answer-key behavior. Every sentence earns its place without 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 no output schema, the description does a good job explaining what the return value contains: threshold, attempts, ordered questions, answer types, and correct answers. It lacks error cases, formatting details, or explicit permissions, but for a simple read-only getter it is nearly 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 has one parameter, test_id, with 0% description coverage in the schema, and the tool description adds no explanation of what test_id refers to or how it should be obtained. The parameter name is self-explanatory to a degree, but the description does not compensate for the missing schema-level documentation.

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 ('get') and resource ('the whole test'), then enumerates what is included: passing threshold, attempt count, and ordered questions with types and correct answers. This clearly distinguishes it from other getters like get_course or get_lesson.

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: whenever a complete test object with questions and answer keys is needed. It also provides audience context by noting the key belongs to school staff, not students. However, it does not explicitly mention alternatives or when not to use this tool.

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 non-destructive behavior. The description adds useful behavioral context: the endpoint returns only cohorts with a common schedule, excludes students without a cohort, and distinguishes progress as a separate resource. For a zero-parameter read-only tool this is sufficient.

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-loaded with the core output fields, followed by a definition and boundary/edge-case routing. Every sentence earns its place 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 simple, parameterless, read-only list endpoint with no output schema, the description fully covers what is returned, the concept of a cohort, exclusions, and pointers to related tools. Nothing needed 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?

The tool has zero parameters and 100% schema coverage (empty schema), so there is nothing for the description to clarify about arguments. The baseline for zero-parameter tools 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 identifies the resource (cohorts/потоки) and the fields returned (course, start/end dates, enrollment count), and it distinguishes this tool from cohort_progress and stuck_students by scope. However, it lacks an explicit verb such as 'list' or 'returns', relying on the tool name and context to convey the action.

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 that students outside cohorts are not included and directs the agent to stuck_students without cohort_id for that case, while also pointing to cohort_progress for progress data. This provides clear when-to-use and when-not-to-use guidance with named alternatives.

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 provide readOnlyHint, idempotentHint, and destructiveHint, so the description only needs to add extra behavior. It explains that drafts are included, how drafts differ via is_published, and that students only see published courses, which is valuable context 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 three short sentences with no wasted words. It front-loads the core purpose, then covers output fields, usage order, and a meaningful distinction between drafts and published courses.

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 listing tool with no output schema, the description is complete: it states what is returned, why it should be called first, and how to interpret the is_published field. Nothing essential is missing for an agent to invoke and use this tool 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 no parameters, so the baseline is 4. The description adds relevant context about the output (course names, publication status, counts, course numbers) even though it does not need to explain parameter semantics.

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 lists all school courses including drafts, with name, publication status, and module/lesson counts. It also distinguishes this from other course-related tools by explaining it returns course numbers used by other requests, which is a specific and useful differentiation.

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 explicitly says to call this tool first to learn course numbers for subsequent requests, giving a clear usage context. It does not explicitly name alternatives or state when not to use it, but the 'call first' guidance and mention of student-visible published courses provide strong situational guidance.

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 annotations (readOnlyHint=false, destructiveHint=false), the description explains that publication is subject to the tariff limit, only published courses count toward the limit, hitting the limit returns a 409 with guidance, and unpublishing is always available. This gives the agent actionable behavioral detail and does not contradict 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 three tight sentences: primary behavior first, then business rule, then error/unpublish clarification. Each sentence adds distinct information without redundancy, making it well-structured and easy to parse.

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 two-parameter mutation with no output schema, the description covers the core action, the tariff restriction, the error case, and the unpublish behavior. It does not describe the success response format, which is a minor gap given the absence of an output schema, but overall it is substantially 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?

Schema coverage is 0%, so the description must compensate. It explains the effect of the published flag through the two states (open to students vs draft) and mentions the tariff check, but it never explicitly maps course_id or published to the schema fields, leaving some inference required.

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: 'Открывает курс ученикам или возвращает в черновики', clearly indicating the tool toggles publication status on a course. This differentiates it from siblings like create_course or update_lesson, which handle creation and lesson edits respectively.

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 clear context for when to use the tool: publishing is the same as the dashboard button, runs through the tariff limit, and unpublishing is always possible. It does not explicitly name alternatives or exclusions, but no sibling tool offers the same publish/unpublish capability, so the guidance is sufficient.

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 the tool read-only and idempotent, so the description's additional value is its non-obvious counting semantics: only completed attempts are considered, and ALL attempts are counted rather than just the last one. It also provides an interpretation heuristic. No contradiction with 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?

Three short, purposeful sentences: the first states the core report contents, the second adds the crucial all-attempts behavior, and the third gives practical interpretation guidance. There is no filler or repetition of schema/annotation 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?

For a low-complexity, one-parameter read-only report, the description covers the metric definitions, the attempt scope, and the meaning of low percentages. It does not specify the output format or ordering, but given no output schema and a simple integer input, the description is sufficiently complete for an agent to invoke the tool 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 sole parameter test_id has no schema description, and the description only indirectly refers to 'the test' without explicitly stating that test_id selects which test's questions to analyze. This is a gap at 0% schema coverage, but the single integer parameter is simple and the description does provide some semantic link by framing the tool around a specific test.

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 exactly what the tool computes: for each test question, the number of answers and the share of correct answers across completed attempts. It also adds the distinctive all-attempts-vs-last-attempt nuance, which differentiates it from other analytics tools, though it does not 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 gives clear usage context: it is meant to reveal questions where people stumble, and it explains why counting all attempts is necessary ('a question stumbled on from the first time is visible only this way'). It offers an actionable interpretation threshold (<50% correct means the question should be reviewed), but it does not explicitly name alternatives or say when not to use 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond annotations: the queue is sorted from oldest, contains specific metadata, and cannot be used to accept or reject submissions. No contradictions with 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 compact sentence that front-loads the purpose, includes the essential data fields, and ends with a clear capability limit. Every part adds value with no redundancy.

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 tool with thorough annotations, the description is complete. It tells the agent what the queue contains, how it is ordered, and that only viewing is possible. No output schema exists, but the description adequately covers what to expect.

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 and schema covers 100% of them vacuously. Per baseline, 0 params gets a 4; the description correctly explains what the no-parameter call returns, so no parameter documentation gap exists.

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 (works waiting for curator review), the relevant fields (who submitted, assignment, time, hours waiting), and the sorting (oldest first). It also explicitly states the tool is read-only, distinguishing it from action-oriented tools among the siblings.

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 makes the use case clear: to inspect the review queue. It also states a firm when-not-to-use boundary: accept or return actions are not available via this API. It does not name an alternative tool explicitly, but the context is sufficient for an agent to avoid misusing this as a write tool.

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 readOnly/idempotent/non-destructive annotations, the description explains the exact inactivity criteria, the meaning of `days`, the cohort scoping behavior, and that course drafts are excluded. This gives the agent a clear behavioral model of what the tool computes.

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 focused sentences, front-loaded with the core definition and followed by scoping and exclusion details. Every sentence adds value and no unnecessary text is present.

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 two optional parameters and rich annotations, the description is complete. It covers the definition, parameter semantics, scope behavior, interpretation guidance, and edge cases like drafts. Nothing essential is missing for correct selection and invocation.

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 carries the full burden for both parameters. It clearly explains `days` as the inactivity threshold and `cohort_id` as an optional cohort filter, including behavior when omitted. Both parameters are fully compensated for.

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 tool's purpose: listing students who have been inactive for more than `days` days, with a precise definition of inactivity. It differentiates itself from sibling tools by framing this as a curator-facing address list rather than a progress or evaluation tool.

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 clear context on when to use the tool, including how `cohort_id` scopes the query and that without it the entire school is included. It also warns that this is not a student evaluation, but it does not explicitly name alternative tools or state when not to use this one.

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 annotations by disclosing that there is no edit history, replacement is irreversible, and concurrent modifications are rejected with 409 instead of silently overwriting. This is critical behavioral context for a destructive mutation and is fully consistent with destructiveHint=true.

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 dense, purposeful sentences front-load the action and immediately warn about irreversibility. Every clause earns its place, and the critical get_lesson-then-update workflow is stated concisely.

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 mutation with no output schema and minimal schema descriptions, this definition provides the essential context: what changes, what cannot be undone, and how to avoid data loss via optimistic concurrency. 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?

With 0% schema description coverage, the description compensates by explaining the concurrency semantics of updated_at and identifying title and document as the updatable fields. It does not explain lesson_id or nullability, but the schema covers those structural details.

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 action ('Меняет') and specific resource elements ('название и/или документ урока'). It distinguishes this as an update operation on an existing lesson, though it does not explicitly contrast it with sibling tools like create_lesson or publish_course.

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 explicit usage guidance: first call get_lesson, then pass updated_at when replacing a document, and expect a 409 if the lesson changed since then. It does not explicitly mention when not to use this tool or alternatives such as create_lesson, but the workflow is clearly stated.

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