Server Quality Checklist

Tool Scores

• run_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 the description's 'Read-only' adds no new behavioral information. The description mentions the endpoint and high-level behavior but does not disclose insights like default limits, pagination behavior, or response format beyond what the schema already provides. It is consistent with annotations, so no contradiction, but adds limited transparency value.

  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: the first sentence states the core functionality, the second provides a key prerequisite. It is front-loaded with the most important information, avoids redundancy, and contains no filler. Every word 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?

  Given the tool's complexity (14 parameters) and the absence of an output schema, the description is adequate because the schema thoroughly documents each parameter. It adds essential context with the endpoint and the get_metadata-advice. It could ideally mention what the response looks like, but the schema's fullResponse parameter and the tool's name imply a tabular report, so completeness is high.

  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 baseline is 3. The description only restates what metrics, dimensions, and filters do, which is already in the schema. It does not add extra semantic detail such as the 'protect context' rationale for limits or the namespace mixing restrictions that the schema descriptions already cover.

  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 queries a Yandex Metrica table report (/stat/v1/data), naming key operations (metrics, dimensions, date range, filter, sort). This specific verb+resource distinguishes it from sibling tools like run_timeseries and run_drilldown, which target different report shapes.

  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 provides clear context by instructing to use get_metadata first to discover valid ids and counters, and labels the tool as read-only. It does not explicitly exclude alternatives or mention when not to use it, but the guidance about prerequisites and the tool's scope is sufficient for a clear context without exclusions.

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

• run_drilldownA
  4.1/5.0
  Behavior4/5

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

  Annotations already convey readOnlyHint and openWorldHint. The description adds useful behavioral details: each row has an 'expandable' flag, parentId carries the key path, and the tool returns only one level. The statement 'Requires dimensions' is ambiguous and conflicts with the schema's required field (metrics only), which slightly undermines transparency but does not contradict 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?

  The description is three short sentences with the purpose front-loaded. It is concise, but 'Read-only' repeats the annotation and 'Requires dimensions' is marginally misleading, so it does not earn a 5.

  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 tool with 15 parameters and no output schema, the description covers the essential navigation logic (parentId path, expandable flags, one-level scope). The response format is partially documented in the fullResponse parameter, so the description plus schema provide adequate context for invocation.

  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%, and each parameter has a detailed description. The description adds minimal semantic value beyond echoing parentId behavior; 'Requires dimensions' is not even schema-accurate. Baseline 3 applies because the schema does the heavy lifting.

  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 uses a specific verb ('Return') and resource ('one level of a hierarchical report'), and includes the endpoint path. This clearly differentiates it from sibling report tools like run_report or run_timeseries, which presumably return flat or non-hierarchical data.

  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 context is clear: this is for hierarchical tree reports, and the description explicitly explains how to expand deeper using parentId. It also states a prerequisite ('Requires dimensions'). However, it does not explicitly name alternative tools or provide exclusion criteria, stopping 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.

• submit_codeA
  4.1/5.0
  Behavior3/5

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

  Annotations provide only readOnlyHint=false and openWorldHint=true. The description adds useful context about the copy-paste flow and that the code comes after approval, but does not disclose side effects such as code invalidation, session state changes, or potential errors. With minimal annotations, this is adequate but not deeply transparent.

  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, well-structured sentence that front-loads the action and includes necessary context. There is zero fluff; every word adds value.

  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 simple one-parameter submission tool with no output schema, the description covers the full flow: prerequisite (login), the data to pass (code), and the expected action (complete sign-in). The annotations and schema fill the remaining gaps, making it sufficiently complete.

  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 fully documents the only parameter 'code' with a clear description. The tool description restates the same meaning ('the code Yandex showed you') without adding new syntax or behavior details. Since schema coverage is 100%, the baseline of 3 is appropriate.

  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 uses a specific verb 'Complete' with a clear resource ('copy-paste sign-in') and states the exact action: pass the code. It distinguishes itself from the sibling 'login' tool by referencing it as the starting point, making the tool's role unambiguous.

  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 states this completes a sign-in 'started by login', giving clear contextual guidance for when this tool is appropriate. It doesn't explicitly list when-not-to-use or name alternative tools, but the reference to login implies the intended sequence, 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.

• logs_cleanA
  4.2/5.0
  Behavior4/5

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

  The description discloses that the tool dispatches based on current status and adds a specific destructive consequence: 'cleaned data must be requested again to download later.' This goes beyond the annotations (destructiveHint=true) by explaining the exact impact of the destructive action. However, it does not elaborate on other behaviors like auth requirements or error cases.

  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, front-loaded with the primary action and purpose, and includes a warning about destructive consequences. Every sentence adds value without unnecessary verbosity, making it highly concise and well-structured.

  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 two-parameter tool, the description covers the core functionality, usage context, and a key behavioral consequence. Annotations capture the destructive nature, and the schema handles parameter details. Minor gaps exist (e.g., what happens for statuses other than finished/prepared), but the description is largely complete for its complexity.

  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 provides 100% description coverage for both parameters (counterId and requestId), so the description does not need to add parameter semantics. The tool description focuses on behavior rather than parameter details, and no additional meaning is provided beyond the schema. This matches 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 clearly states the tool's action: 'Free the counter storage quota by cleaning a finished (processed) log request, or cancel one still being prepared.' It specifies the resource (Metrica log request) and distinguishes itself from sibling tools like logs_download, logs_status, and logs_request by focusing on cleaning/cancelling to reclaim quota.

  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 provides clear context on when to use the tool: to free storage quota by cleaning finished requests or cancelling pending ones. It mentions 'Dispatches by current status' but does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusionary guidance.

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

• logs_statusA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only' while adding behavioral context: the polling workflow, the fields returned (status, parts, size, next step), and the storage-quota usage listing. This goes beyond the annotation and provides useful operational detail, though it does not cover rate limits or error semantics.

  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, front-loaded with the primary action, and every clause adds value. 'Read-only' is slightly redundant with annotations but short. It is efficiently structured with no filler.

  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 status tool with strong annotations and no output schema, the description adequately covers the two usage modes and the critical polling instruction. It does not detail return formatting or define 'parts'/'next step', but these are minor given the tool's simplicity and the absence of output schema requirements.

  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% with parameter descriptions already explaining requestId's role and the option to omit it. The description rephrases this behavior and adds usage context (polling), but does not add new semantic meaning beyond the schema. Baseline of 3 is appropriate since the schema carries the load.

  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 purpose: inspecting a Logs API request by request_id or listing all requests and quota usage. It uses specific verbs ('Inspect', 'list') and resource ('Logs API request'), and distinguishes from siblings like logs_request (submission) and logs_download (download) by focusing on status and quota.

  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?

  Provides explicit usage guidance: 'Poll this after logs_request until status="processed"' clearly indicates when this tool should be used. It also explains the optional request_id behavior. However, it does not explicitly mention alternatives like logs_download or state when not to use this tool, so it lacks full when-not/alternative coverage.

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

• run_timeseriesA
  4.2/5.0
  Behavior4/5

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

  With annotations already declaring readOnlyHint=true, the description adds valuable behavioral detail about output shape (array of values per interval) and optional dimension grouping. It does not contradict the annotations, and it discloses the endpoint path.

  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?

  Three sentences, each with a distinct purpose: output format, use case, and optional grouping/safety. No wasted words.

  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?

  The description captures the core value proposition and output structure. With 12 parameters fully documented in the schema, the description doesn't need to enumerate them. It could benefit from an explicit alternative to run_report, but overall it's adequate for selection and invocation.

  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 baseline is 3. The description adds minimal parameter-specific meaning beyond the schema; it references topKeys rows but otherwise relies on the extensive param descriptions in the 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 explicitly states 'Return metrics split into a time series' and names the endpoint (/stat/v1/data/bytime), clearly distinguishing it from sibling reporting tools like run_report and run_drilldown by its time-interval output format.

  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 says 'Use for trends and charts', giving clear context for when to use this tool. It does not explicitly name alternatives or when-not-to-use conditions, so it stops short of a full 5.

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

• describe_counterA
  4.4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, and the description adds context beyond that: the goals section returns IDs needed for conversion metrics in run_report, and sections are selectable via include. No contradiction with annotations. It does not describe return format, but the read-only safety is covered.

  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?

  Three concise sentences: the first states purpose, the second gives a specific use case and ties to run_report, the third distinguishes from get_metadata. Every sentence earns its place; no fluff.

  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 complexity and rich schema/annotations, the description is nearly complete: it covers purpose, selectable sections, a conversion-metric use case, and the sibling alternative. The only minor gap is not describing the return structure, but the included sections and schema cover the essentials.

  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%, so baseline is 3. The description reiterates the include parameter's role ('choosing sections with include') and the goals purpose, but adds no new meaning beyond what the schema's parameter descriptions already state.

  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 opens with 'Read a single counter's configuration' — a specific verb, resource, and scope. It enumerates the sections (settings, goals, segments, filters, operations, access grants) and distinguishes from get_metadata for listing counters.

  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?

  The description explicitly states when to use this tool: 'call this with include=["goals"] before any conversion question' and points to an alternative: 'To list the account's counters, use get_metadata.' This gives clear context and exclusions.

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

• logs_downloadA
  4.5/5.0
  Behavior5/5

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

  Beyond the readOnlyHint and openWorldHint annotations, the description discloses mode-specific behavior: sample mode is cheap and bounded, while file mode streams the full export to a file and never loads raw content into context. It also reiterates the read-only nature, adding safety context without contradicting 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 four short, information-dense sentences, front-loaded with the primary purpose. Every sentence contributes valuable context (modes, boundedness, output behavior, read-only), with no fluff or redundancy.

  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 tool with moderate complexity (5 params, no output schema) and annotations providing read-only behavior, the description covers purpose, prerequisites, output behavior for both modes, and memory safety. It gives an agent sufficient context to select and invoke the tool correctly within the workflow.

  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%, so each parameter is already documented. The description adds contextual trade-offs between modes but does not provide significant per-parameter detail beyond what the schema states. Baseline of 3 is appropriate when the schema carries the semantic load.

  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 uses the specific verb 'Download' and identifies the resource 'prepared log data' for a request_id, clearly distinguishing this tool from siblings like logs_request and logs_status. It also specifies the required status condition, making the tool's function unambiguous.

  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 the prerequisite that request_id must have status 'processed' and points to logs_status for verification, providing clear when-to-use context. It also explains the two modes (sample vs. file) to guide selection based on need, though it does not explicitly mention when not to use the tool relative to other siblings.

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

• logs_requestA
  4.5/5.0
  Behavior5/5

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

  The description discloses important behavioral traits beyond the annotations: 'Not read-only: preparing data consumes the counter storage quota' and 'Checks feasibility, then queues preparation (takes minutes).' It also explains the async nature and the request_id polling mechanism, adding significant context on top of readOnlyHint=false and openWorldHint=true.

  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 compact paragraph of four sentences, each adding value: raw/un-sampled distinction, sources, check/queue behavior, workflow, field discovery, and storage quota warning. It is front-loaded with the main purpose and contains no filler.

  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?

  Given the tool's complexity (7 parameters, no output schema), the description is complete: it explains the return value (request_id), the full follow-up workflow (logs_status, logs_download, logs_clean), prerequisites (date constraints, field discovery), and a key side effect (storage quota). It adequately informs the agent on how to invoke and use the tool 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 description coverage is 100%, so the baseline is 3. The description does not significantly add parameter-level meaning beyond the schema; it reinforces that fields must match the source prefix and that date2 must be earlier than today, but those are already in the schema. No extra parameter details are provided, so a 3 is appropriate.

  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: 'Create a Yandex Metrica Logs API request for RAW, un-sampled rows' with specific sources (visits/hits) and date range. It distinguishes from sibling tools by describing the full workflow (request → status → download → clean) and mentioning related tools like get_metadata.

  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 provides explicit workflow guidance: 'Returns a request_id to poll with logs_status; then logs_download, then logs_clean.' It also tells users to discover field ids with get_metadata. However, it does not explicitly contrast with aggregated report tools (e.g., run_report) or state when to choose this tool over them, though 'RAW, un-sampled rows' implies the distinction.

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

• loginA
  4.6/5.0
  Behavior5/5

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

  The description goes well beyond the annotations (readOnlyHint=false, openWorldHint=true) by disclosing that it opens a browser, handles an automatic redirect, may fall back to a URL when local port is unavailable, and that the token lasts about a year. This provides essential behavioral context for an agent.

  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 composed of three sentences, each serving a clear purpose: stating the function, explaining the normal flow, and providing fallback plus usage guidance. Every sentence earns its place, and the information is front-loaded with the core purpose.

  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?

  With no output schema, the description should clarify return values. It does mention the fallback returns a URL, but it does not explicitly describe what a successful call returns. Despite this minor gap, the description thoroughly covers the login flow, token duration, and prerequisites, making it largely complete.

  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 provides 100% coverage for the one parameter `oob`, described as 'Force the copy-paste flow instead of the automatic local redirect.' The description does not mention the parameter, but since the schema already fully documents it, no additional value is added, hence the baseline score of 3.

  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 'Sign in to Yandex from here' with a specific verb and resource. It also distinguishes itself from sibling tools, especially submit_code, by explaining that this is the primary sign-in flow and submit_code is only used as a fallback for code submission.

  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?

  Explicitly provides when to use: 'Run this once (the token lasts ~1 year); needed before the data tools if you are not signed in yet.' It also gives conditional guidance for the fallback path when the local port is unavailable, directing the user to submit_code.

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

• get_metadataA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint, and the description reinforces read-only behavior. It adds contextual value by noting the lack of an enumeration API, token scoping, and the curated nature of the catalog, which goes beyond the annotations without contradicting 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 three sentences, front-loaded with the primary action ('Lists') and key contents, followed by usage context and sibling differentiation. Every sentence earns its place with no redundancy.

  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 discovery tool with no input parameters and no output schema, the description is complete: it states what is returned, when to use it, and how it relates to alternatives. No critical gaps remain.

  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 parameter semantics are not applicable. The absence of parameters is accurately reflected, and the description doesn't need to add parameter-level detail; baseline 4 applies.

  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 uses a specific verb ('Lists') and clearly identifies the resource: counters, dimensions/metrics, attribution options, and Logs API fields. It also differentiates from describe_counter, which handles counter-specific metadata, making the purpose unambiguous.

  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?

  Explicitly instructs to call this tool before run_report or logs_request to get real field names and a counterId, and directs users to describe_counter for counter-specific goals, segments, filters, or grants. This provides clear when-to-use and alternative guidance.

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

• run_comparisonA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, but the description adds meaningful behavioral details: the delta is computed server-side with the exact formula (delta = B − A, delta_pct = (B − A) / A × 100), and a positive delta means growth. This goes beyond the annotation's safety profile.

  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 and front-loaded: it states the core purpose first, then explains the delta calculation and defaults, and ends with 'Read-only.' Every sentence contributes useful information with no redundancy or fluff.

  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?

  There is no output schema, but the description explains the return structure: per-metric values for A and B plus absolute and percentage delta. It also covers defaults, read-only nature, and the delta computation. Given the richness of the input schema, this is sufficient 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.

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by explaining the default date range (last 7 days vs prior 7 days), which is not in the schema's parameter descriptions. This helps the agent understand the date parameters without needing to infer defaults.

  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 opens with a specific verb and resource: 'Compare two segments/periods (A vs B) for the same metrics and dimensions', clearly distinguishing it from sibling tools like run_report or run_timeseries. It also specifies the endpoint path and the output (per-metric values and deltas).

  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 clearly states the intended use case—comparing two segments/periods—and explains the default period behavior ('last 7 days (B) vs the prior 7 days (A)'). However, it does not explicitly mention when not to use it or name alternative tools, so it falls 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.