Server Quality Checklist

Tool Scores

• list_payoutsC
  2.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, covering the safety profile. The description adds context about the deal stages (draft, inwork, accepting, completed, paying, paid) which helps interpret results, but it does not disclose behavioral traits such as default ordering, pagination, or filtering behavior. Since the bar is lowered by annotations, this partial addition earns a 3.

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

  Conciseness4/5

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

  The description is compact, with a direct opening that defines the resource and then a succinct enumeration of stages. It avoids fluff and front-loads the main purpose. No redundant sentences; it is appropriately sized for the content.

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

  Completeness2/5

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

  With 5 parameters, two enums, no output schema, and only 40% schema coverage, the description is insufficient for reliable invocation. It does not explain the meaning of filters, pagination, or the output format. The business context (deal stages) is useful but does not fill the gaps needed to correctly call the tool.

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

  Parameters1/5

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

  The description does not mention any parameters, leaving q, kind, page, limit, and status unexplained. The schema covers 40% of parameters (only q and kind have descriptions). The description does not compensate for the remaining 60% and does not clarify what each parameter controls or how the stage vocabulary relates to the status enum. This is a significant gap.

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

  Purpose4/5

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

  The description identifies the resource as payments to self-employed through Rocket Work deals ('Расход денег: выплаты самозанятым через сделки Рокет Ворк') and elaborates on deal stages. This makes the tool's domain clear, and the name 'list_payouts' implies the action. It is distinct from other list tools because it specifically targets payouts, though it does not explicitly state the action or contrast with siblings.

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

  Usage Guidelines2/5

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

  No guidelines are provided on when to use this tool versus alternatives. The description explains the stages and hints at interpretation ('Зависшие draft и inwork — это те, кто держит свои же деньги') but never states conditions like 'use this for payout queries' or 'prefer list_payments for X'. The agent is left to infer usage from the name alone.

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

• list_enrollmentsB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so safety is covered. The description adds behavioral context by stating it exposes remaining paid hours and balance status, which is useful for understanding the return data. However, it does not discuss pagination behavior, default sorting, or open-world data completeness, so it falls short of rich disclosure.

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

  Conciseness5/5

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

  The description is two concise sentences. The first front-loads the core meaning with a colon and list of key attributes; the second adds a practical use case. No fluff or redundancy.

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

  Completeness3/5

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

  While the core domain is clear, the description lacks essential details for a 5-parameter list tool with no output schema. It does not describe the response shape, how status filtering works, or provide usage examples. The annotations cover read-only safety, but the description is not complete enough on its own.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description fails to explain any of the five parameters (page, limit, status, student_id, teacher_id). It mentions domain concepts like rates and hours, but these are not mapped to filter parameters, leaving the agent to infer their semantics from names alone. This is insufficient compensation for the schema gap.

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

  Purpose4/5

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

  The description clearly identifies the resource as contracts linking students and teachers, with subject, rates, and remaining paid hours. The mention of balance depletion ('у кого кончаются деньги') differentiates it from sibling list tools by highlighting its unique purpose, making the tool's role clear.

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

  Usage Guidelines3/5

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

  The description implicitly suggests when to use the tool ('Именно здесь видно, у кого кончаются деньги на балансе'), but it does not explicitly state alternatives or exclusion criteria. The use case is clear but there is no direct comparison to siblings like list_payments or finance_report.

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

• list_tasksB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the description carries a lighter burden. It adds background on how quality tasks originate, which provides context about the data, but it does not disclose operational behavior such as default ordering, pagination, or whether results are scoped to the current user. This is adequate but not rich.

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

  Conciseness5/5

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

  The description is compact—two sentences that front-load the core purpose and then explain the quality-context relevant behavior. There is no filler or redundancy, and every clause adds meaning.

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

  Completeness3/5

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

  For a list tool with no output schema, the description omits crucial invocation details like default result size, ordering, or the fact that openWorldHint may return results beyond the filter criteria. It also does not clarify whether all employees' tasks are returned or only those visible to the caller. Given the sibling list tools and the parameter count, more operational context would help an agent call it correctly.

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

  Parameters3/5

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

  Schema covers 3 of 4 parameters with descriptions (assignee_id, is_completed, only_quality), leaving limit undocumented. The description adds real value only for only_quality, explaining its meaning and purpose. No extra semantics are given for the other parameters, so the description does not fully compensate for the missing limit description.

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

  Purpose4/5

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

  The description clearly states the tool returns employee tasks, and explains the quality-control subset with the only_quality filter. It distinguishes this resource from other list tools by naming the specific object (tasks) and the semantic split (quality vs. regular). However, it never explicitly says 'list' or 'retrieve', relying on the tool name and title to imply the action.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives like search or other list tools. The description only explains internal table mechanics (quality tasks created by robot/AI) and does not mention any scenario where a sibling tool would be more appropriate. The only_quality filter is described, but that is a parameter-level hint, not usage guidance.

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

• get_leadB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to repeat safety. It adds context about the funnel steps history, which hints at data structure, but does not disclose other behavioral aspects like error handling or authorization. No contradiction 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.

  Conciseness5/5

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

  A single, front-loaded sentence with zero filler. The main purpose is stated first, followed by specific fields, making it efficient and easy to parse.

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

  Completeness4/5

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

  For a single-parameter retrieve-by-ID tool with read-only annotations, the description is sufficient. It lists the key content returned, so an agent knows what to expect. No output schema exists, but the described fields cover the expected payload. Minor omission of error behaviors, but not critical.

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

  Parameters3/5

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

  Schema description coverage is 100%, with lead_id described as 'id заявки'. The description adds no additional meaning about the parameter, such as how to obtain it or edge cases. Given high coverage, the baseline of 3 applies.

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

  Purpose4/5

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

  Description explicitly states the tool returns the full lead card with specific fields: parent contacts, subject, teacher, and funnel steps history. This is a clear verb+resource with enumerated content, differentiating it from list tools though not explicitly mentioning a sibling.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus the alternatives like list_leads or search. The need for a lead_id is implied by the parameter, but there is no explicit statement such as 'use this to get detailed info for a single lead'.

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

• get_teacherA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds useful context about the data fields (rate, contacts, etc.) but provides no additional behavioral traits like response format or limitations. With annotations covering the safety profile, the description adds modest value beyond them.

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

  Conciseness5/5

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

  The description is very concise: two sentences, the second being a directive to a sibling tool. Every word adds value, and the critical purpose is stated first. No filler or redundancy.

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

  Completeness4/5

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

  For a simple single-parameter read tool with no output schema, the description is largely complete. It lists the main data points and identifies a related tool for a specific sub-case. It does not specify the return format, but that is minor for a simple get operation. Overall, an agent can confidently call this tool based on the description.

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

  Parameters3/5

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

  The schema fully describes the single parameter teacher_id as 'id преподавателя' with exclusiveMinimum>0, giving the agent sufficient meaning. The description does not add any additional parameter context, but since schema coverage is 100%, the baseline of 3 applies.

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

  Purpose4/5

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

  The description states it provides a teacher card with specific fields (rate, contacts, self-employed status, availability), clearly indicating it retrieves a single teacher's details. It explicitly distinguishes itself from list_trial_scores, though it does not contrast with list_teachers, which is a likely sibling for listing teachers. The purpose is clear and specific.

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

  Usage Guidelines3/5

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

  The description gives a partial usage guideline by directing users away from this tool for trial scores to list_trial_scores. However, it does not explicitly state when to use this tool versus list_teachers (e.g., when you need details for a specific teacher rather than a list). The context implies it is for single-teacher details, but explicit guidance is lacking.

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

• list_paymentsA
  3.6/5.0
  Behavior4/5

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

  Annotations include readOnlyHint=true and openWorldHint=true, so the description doesn't need to repeat safety. The description adds valuable context: currency normalization to rubles and the q parameter's search scope. It doesn't mention pagination or status filtering, but with annotations covering read-only behavior, the bar is lower. The description adds useful behavioral context beyond annotations.

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

  Conciseness4/5

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

  Two sentences, front-loaded with the core purpose and currency normalization, then the search hint. No fluff, efficient. Slightly lacks structure for parameter details but overall concise.

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

  Completeness3/5

  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 6 parameters and no output schema, the description covers the main purpose, currency, and q parameter. Missing details on pagination, status filtering, date range usage, or return format. Since annotations show readOnlyHint and openWorldHint, the tool is safe, but an agent might need more info on how to filter or paginate. The description is adequate for basic use but not complete for all parameters.

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

  Parameters3/5

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

  Schema description coverage is 50% (q and date_to/date_from have descriptions; page, limit, status lack descriptions). The description explains the q parameter's semantics ('имя ученика, родителя или преподавателя') which goes beyond the schema's 'Имя ученика, родителя или номер заказа'—adds teacher. For other parameters, it doesn't add anything beyond the schema. Baseline is 3 for 50% coverage; the description partially compensates for undocumented parameters (status, page, limit) but not fully.

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

  Purpose4/5

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

  The description states a clear verb+resource ('Приход денег: оплаты родителей через эквайринг') and explicitly notes currency normalization ('Все суммы приводятся к рублям'). It likely differentiates from list_payouts (which is about payouts, not incoming payments), but doesn't directly name siblings. Purpose is clear but sibling differentiation is implicit.

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

  Usage Guidelines3/5

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

  The description mentions 'Поиск по человеку — параметр q (имя ученика, родителя или преподавателя)' indicating a use case for searching. However, it doesn't specify when to use this vs list_payouts or finance_report, and doesn't mention any exclusions. Usage guidance is implied but not explicit.

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

• dashboardA
  3.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds useful behavioral context by defining calendar-based week and month boundaries, which is not in the annotations or schema. It does not contradict annotations and provides a small but meaningful additional behavioral detail.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that front-loads the purpose and then lists sections and period semantics. It avoids fluff and uses space well, though the long list of section names makes it dense. It could be split into a purpose line and parameter details, but it is still appropriately concise.

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

  Completeness3/5

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

  The description covers the purpose, available sections, and period semantics, but it does not describe the shape of the output or what values are returned (e.g., a single aggregated number, a table, or a summary object). With no output schema present, an agent cannot fully predict the response format, which is a notable gap for this complexity level.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by providing Russian labels for each section enum (e.g., finance = деньги) and clarifying that week/month periods are calendar-based, which helps an agent map enum values to semantics and select appropriate periods.

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

  Purpose4/5

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

  The description states the tool shows 'main indicators for the period' and enumerates ten specific sections (finance, funnel, retention, etc.), making its purpose clear as an aggregated dashboard. It is not a tautology and provides enough specificity to distinguish it from individual list tools such as list_payments or get_lead, though it does not explicitly contrast with finance_report.

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

  Usage Guidelines3/5

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

  The description explains calendar period semantics (week starts Monday, month from the 1st) and lists available sections, which helps an agent choose correct parameter values. However, it does not explicitly state when to use this tool over alternatives like finance_report or list_payments, nor does it mention any exclusions or conditions for using period=custom with dateFrom/dateTo beyond what the schema implies.

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

• list_trial_scoresA
  3.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, making the read-only nature known. The description adds value by disclosing that transcriptions are not available due to personal data, and specifies that the tool provides mechanical and semantic metrics. This goes beyond annotations, though it does not cover pagination or exact 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.

  Conciseness4/5

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

  The description is two sentences, front-loaded with purpose and followed by a key limitation. It is efficient and avoids redundancy, though it could be slightly more informative about output and parameters.

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

  Completeness3/5

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

  Given the absence of an output schema, the description should clarify return format. It states the tool allows comparing teachers and lists metric types, but does not describe the structure (e.g., per-teacher scores, aggregation) or mention pagination via 'limit'. Adequate but with notable gaps.

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

  Parameters2/5

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

  The description adds no information about the 'limit' parameter, which lacks a schema description. The 'teacher_id' is described in schema (id преподавателя), but the description does not clarify how to use it. With 50% schema coverage and zero parameter guidance in the description, the agent lacks clarity on the limit parameter's purpose.

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

  Purpose5/5

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

  The description clearly states the tool lists AI assessments of trial lessons with mechanical and semantic metrics from call transcriptions, and explicitly mentions it allows comparing teachers by trial quality. It distinguishes from siblings like list_lessons by focusing on scores rather than lesson details.

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

  Usage Guidelines3/5

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

  The description implies usage for comparing teachers' trial lesson quality but does not provide explicit when-to-use or when-not-to-use guidance relative to alternatives. It does mention a limitation (transcriptions unavailable) but no exclusions or alternative tool suggestions.

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

• list_teachersA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds valuable domain context by explaining that the «Статус в РВ» = validated means FNS rights are confirmed and payments are possible.

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

  Conciseness5/5

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

  The description is short and efficient: one front-loaded sentence stating the resource and its key fields, followed by one sentence clarifying an important status value. No filler or duplication with the title or schema.

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

  Completeness4/5

  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 one optional parameter and no output schema, the description covers the main purpose, relevant fields, and the meaning of a critical status. It does not detail the exact output shape or default behavior, but that is not a major gap for this simple endpoint.

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

  Parameters3/5

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

  The input schema already documents the single optional 'q' parameter as a filter by name or phone, so schema coverage is 100%. The description does not add additional parameter-level semantics, warranting the baseline score of 3.

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

  Purpose4/5

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

  The description clearly identifies the resource as a list of teachers and names the key content: rates, workload, and payment readiness via Рокет Ворк. It is distinct from get_teacher or list_students, though it does not explicitly name sibling tools for differentiation.

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

  Usage Guidelines3/5

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

  The description implies when to use this tool by stating what data it provides, especially payment readiness. However, it does not give explicit guidance on when to choose it over alternatives like list_students or get_teacher, nor any exclusions.

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

• list_lessonsA
  3.9/5.0
  Behavior3/5

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

  Annotations include readOnlyHint=true and openWorldHint=true, so the read-only nature is already disclosed. The description adds behavioral context about the unmarked filter (only for completed lessons) and type filter, but doesn't go further—no mention of pagination behavior, default limits, or other data handling. Since annotations carry the safety profile, the description's contribution is modest.

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

  Conciseness5/5

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

  The description is two sentences long, with the primary purpose front-loaded and the special filters highlighted concisely. Every sentence adds value, no fluff or repetition. The structure makes it easy to parse quickly.

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

  Completeness3/5

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

  Given 9 parameters and no output schema, the description leaves gaps: it doesn't explain pagination (page/limit), the meaning of status values, or the response format. It covers the core use case but omits details that an agent might need for correct invocation, such as sorting or default bounds. Adequate for a simple list tool but not fully comprehensive.

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

  Parameters4/5

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

  Schema description coverage is 67%, so some parameters (page, limit, status) lack descriptions. The description adds crucial meaning to 'unmarked' and 'type', explaining their exact semantics beyond the schema's bare descriptors. This compensates for the gaps and helps an agent use these parameters correctly.

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

  Purpose5/5

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

  The description clearly states the tool's function: listing lessons within a date period with filters by teacher, contract, and status. It also highlights two specific use cases (unmarked and type=TRIAL) that distinguish it from sibling list tools like list_enrollments or list_trial_scores. The verb 'Уроки за период' implies listing lessons, and the mention of filters makes the resource and action explicit.

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

  Usage Guidelines3/5

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

  The description provides context for when to use specific filters (unmarked=true for unclosed lessons, type=TRIAL for trial lessons) but never explicitly contrasts this tool with alternatives or states when not to use it. It doesn't mention any sibling tool or exclusion criteria, so an agent must infer from the title and sibling names. This is adequate but not exemplary.

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

• list_studentsA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and openWorldHint, covering the safety and open-world nature. The description adds that the result includes parent contacts and subject, which is content context but not behavioral detail like pagination, sorting, or error behavior. With annotations in place, the added value is moderate.

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

  Conciseness5/5

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

  Two crisp sentences, the first stating the core function and the second the key usage distinction. No filler, and the critical routing hint is front-loaded after the purpose.

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

  Completeness3/5

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

  While the description conveys the purpose and the included fields, it does not specify the full return structure (e.g., student name, contact details) or any pagination/limitation behavior. The lack of an output schema means this context would be helpful, but the tool is simple enough that the description may be adequate for basic selection.

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

  Parameters3/5

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

  The sole parameter tag_ids is fully documented in the schema (100% coverage) with a description 'id тегов через запятую'. The tool description adds no extra meaning about the parameter, so it meets the baseline for high schema coverage.

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

  Purpose5/5

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

  The description states the tool lists students with parent contacts and subject, which is a specific verb, resource, and content detail. It clearly distinguishes itself from the search tool by noting that search is for finding specific people by name/phone, so an agent can tell when to use which.

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

  Usage Guidelines4/5

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

  It explicitly points to the search tool when looking for a specific person by name or phone, giving a clear exclusion. However, it does not mention alternatives like get_student for retrieving a single student's details or list_teachers for analogous lists, so it covers only one routing case.

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

• alertsA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by explaining that the tool shows automatically tracked issues and that output mode changes based on the key parameter. No contradiction with annotations exists.

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

  Conciseness5/5

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

  The description is two sentences with no filler: the first defines the tool's scope with concrete examples, and the second explains parameter-driven behavior. Every sentence contributes actionable information.

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

  Completeness4/5

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

  For a simple tool with one optional parameter and no output schema, the description adequately explains both modes of use and the kinds of issues returned. It does not detail the summary structure, but the provided context is sufficient for an agent to call it correctly.

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

  Parameters3/5

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

  Schema coverage is 100%, so the parameter 'key' is already documented as a problem-type code from the summary and as optional. The description adds the detail that using key yields specific records for one type, but this is marginal beyond the schema. Baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly identifies the tool as a registry of system-tracked problems and enumerates concrete categories, so an agent understands what resource it addresses. It lacks an explicit contrast with sibling tools, but the nature of the resource is distinct enough to avoid confusion.

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

  Usage Guidelines4/5

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

  The description gives clear operational guidance: without the key parameter it returns a summary across all problem types, and with the key it returns specific records for one type. It does not discuss when to use this tool instead of siblings, but the parameter-level usage is explicit and useful.

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

• finance_reportA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds useful behavioral context by specifying that periods are calendar-based (week starts Monday, month starts first), which is valuable beyond the annotations. However, it does not describe output format or default behavior when optional months are omitted.

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

  Conciseness5/5

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

  Two sentences with no fluff. The first sentence states the core purpose, the second details the report types and period rules. All 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.

  Completeness4/5

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

  For a read-only report tool with three parameters (one required), the description covers report selection and period semantics. It does not mention default ranges or output structure, but given the annotations and that there is no output schema, this is sufficient for an agent to call it correctly in most cases.

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

  Parameters4/5

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

  Schema coverage is 100%, but the description enriches meaning by clarifying the report enum (pnl, cashflow, cohorts) and explaining that periods are calendar-based, which the schema descriptions only hint at via YYYYMM format. This adds value beyond the structured schema.

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

  Purpose5/5

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

  The description clearly states the tool provides summary financial reports (p&l, cash flow, cohorts), distinguishing it from the sibling tools which are all list/get operations. The verb 'Сводные' (summarize) plus specific report types makes the purpose unambiguous and not a tautology.

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

  Usage Guidelines3/5

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

  The description implies usage for financial reporting but does not explicitly state when to use this tool versus alternatives or provide exclusions. Since no sibling tools are financial in nature, the context is clear, but explicit guidance is absent.

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

• get_studentA
  4/5.0
  Behavior3/5

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

  The readOnlyHint and openWorldHint annotations already convey that this is a safe read operation. The description adds the return content (contacts, contracts, etc.) but does not disclose behavioral details like error handling, response shape, or potential variability. Since annotations cover the main safety trait, the added value is modest.

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

  Conciseness5/5

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

  The description is a single front-loaded sentence, efficiently packing the resource type and content list with zero filler. It follows a clear pattern—key term first, then comma-separated details—making it easy to scan.

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

  Completeness4/5

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

  For a simple get-by-ID tool with one parameter, no output schema, and readOnlyHint provided, the description adequately tells the agent what data to expect. It could be slightly more complete by mentioning what happens if the student is not found (e.g., empty response or error), but given the simplicity, it does not warrant a 5.

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

  Parameters3/5

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

  Schema description coverage is 100% (the sole parameter student_id is described as 'id ученика'). The tool description adds no further meaning about the parameter, so it remains only adequate; baseline 3 is appropriate when the schema already documents it fully.

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

  Purpose5/5

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

  The description clearly states the tool retrieves a student's detailed card, listing specific components (contacts, subject, tags, contracts, payments). This distinguishes it from sibling tools like list_students (a list) and other get_* tools (get_lead, get_teacher) by referencing a unique resource and content scope.

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

  Usage Guidelines4/5

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

  The description implies usage for fetching a single student's full profile, contrasting with listing tools, but does not explicitly state when not to use it or name alternative tools. It provides clear context but lacks explicit exclusions or references to siblings.

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

• searchA
  4.1/5.0
  Behavior4/5

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

  Annotations already mark the tool as read-only and open-world, so safety is covered. The description adds context by showing that a single query spans multiple CRM entity types and is meant to resolve internal IDs, which is useful behavioral information 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.

  Conciseness5/5

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

  The description is two focused sentences with no filler. It front-loads the searchable entities and immediately gives the practical use case, making it easy for an agent to scan and act on.

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

  Completeness3/5

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

  The description explains the purpose and when to use the tool well, but there is no output schema and no explicit statement about what the search returns (e.g., a list of matches with entity types and IDs). The missing return-value detail leaves a noticeable gap for an agent invoking the tool.

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

  Parameters3/5

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

  Schema coverage is 100% and the parameter description already says 'name, surname, phone or record number'. The tool description mostly repeats this, adding no new details about matching behavior, case sensitivity, or input formatting.

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

  Purpose5/5

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

  The description clearly defines a global search over many entity types (teachers, students, leads, payments, etc.) by name, phone, or record number. It distinguishes itself from the list_/get_ sibling tools by positioning search as the entry point when internal IDs are unknown.

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

  Usage Guidelines4/5

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

  The description explicitly states when to start using this tool: when a name or phone is known but internal IDs are not. It implies that list_/get_ tools should be used afterward, but it does not explicitly name alternatives or state 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.

• list_leadsA
  4.2/5.0
  Behavior4/5

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

  Annotations already mark the tool as read-only (readOnlyHint=true), so the description need not restate that. It adds meaningful behavioral detail: the precedence rule 'alert' overrides 'status' when both are specified, and each alert value is defined (e.g., overdue, trial_no_date). This goes beyond the schema's enum list, which only lists the values without semantics. The description does not contradict any annotation and provides context that affects how results are filtered.

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

  Conciseness5/5

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

  The description is a single, information-dense sentence that front-loads the purpose ('Список заявок с фильтрами') and then rolls out the alert specifics. Every clause adds value: the list of alert groups with parenthetical explanations is essential and not duplicated verbatim in the schema. There is no fluff, no repetition of annotations, and the structure is natural – a clear statement of function followed by detail.

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

  Completeness4/5

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

  Given the tool's moderate complexity (5 parameters, no output schema), the description covers the most intricate part – the alert semantics and precedence – which is not in the schema. The other parameters (page, limit, status, owner_id) are self-explanatory via their schema descriptions, so the description need not elaborate. It lacks an explicit mention of pagination defaults or return format, but those are either in the schema or not required for calling the tool. Overall, the description provides enough for correct invocation without knowing the output structure.

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

  Parameters4/5

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

  The input schema covers 100% of parameters, so the baseline is 3. However, the description enriches the 'alert' parameter by explaining each enum value in prose, something the schema does not do (the schema only says 'Проблемная группа; важнее статуса'). It also reinforces the precedence rule. This adds semantic depth for the most complex parameter, going beyond the schema's minimal descriptions. Other parameters (page, limit, status, owner_id) are adequately described in the schema, and the description does not need to repeat them.

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

  Purpose5/5

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

  The description clearly states the action ('Список заявок') and the resource (leads), and further specifies filtering capabilities. It explicitly enumerates the alert groups and their meanings, making the tool distinguishable from siblings like get_lead (single lead) and search (free-text) without needing to inspect the schema. The inclusion of alert semantics adds precision beyond a generic list description.

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

  Usage Guidelines3/5

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

  The description communicates that this is a filtered list tool, so an agent can infer when to use it for querying leads by status or problem groups. However, it does not explicitly state when to avoid it (e.g., for free-text search use 'search', for a single lead use 'get_lead'), nor does it mention any exclusions or alternatives. This leaves the routing decision to inference from sibling names, which is adequate but not fully explicit.

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

• whoamiA
  4.7/5.0
  Behavior4/5

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

  Annotations already flag readOnlyHint and openWorldHint, so the description adds value by explaining what the tool reveals (identity and accessible sections). It does not contradict the annotations and gives context on the nature of the output.

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

  Conciseness5/5

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

  Two concise sentences: the first defines the purpose, the second provides a practical trigger context. No filler, and the key information is front-loaded.

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

  Completeness5/5

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

  For a zero-parameter, read-only diagnostic tool, the description fully covers what an agent needs: what it does and when to use it. The annotations cover safety, and there is no output schema to complicate expectations.

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

  Parameters4/5

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

  The tool has zero parameters, so the schema is trivial. The description correctly adds no parameter details, and the baseline of 4 applies since there is nothing to explain.

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

  Purpose5/5

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

  The description states a specific verb ('shows') and resource ('whose behalf the key works and which sections are accessible'), clearly distinguishing this tool from siblings like list_leads or search. It immediately tells the agent what type of information it will retrieve.

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

  Usage Guidelines5/5

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

  It explicitly provides a use case: 'useful when the tool answers insufficient rights' — telling the agent when to invoke this tool to diagnose permission gaps. This is direct, actionable guidance.

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