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

Beyond the annotations (readOnlyHint=false, idempotentHint=true), the description adds behavioral details: it explains the meaning of permission values ('edit' allows editing and using, 'view' only viewing/using) and discloses the response shape including that created_at is server-filled. It doesn't mention idempotency behavior, but annotations already hint at it, so the description provides valuable additional context without contradiction.

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

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

The description is two sentences long, immediately states the core action, and includes only necessary contextual details (permission meanings, response format). It is front-loaded and free of redundancy, perfectly sized for the tool's simplicity.

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

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

For a simple grant-creation tool, the description covers the purpose, permission semantics, and response shape. While there is no output schema, the response format is described inline, which is helpful. It could mention idempotency or duplicate handling, but the idempotentHint annotation partially covers that, making the description adequately complete.

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

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

The parameter schema covers 100% of parameters, so baseline is 3. The description adds semantic meaning for the 'permission' parameter by elaborating on each enum value, which is not fully explained in the schema. It also implicitly clarifies that segment_id comes from list_segments or creation responses, though this is also in the schema. This extra semantic enrichment justifies a 4.

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

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

The description uses a specific verb 'Создаёт' (creates) and clearly defines the resource: a permission (grant) on a segment for a specified Yandex login. It distinguishes itself from sibling tools like list_segment_grants and delete_segment_grant by its unique action and parameters (segment_id, user_login, permission).

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

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

The description clearly states the action and the permission options, placing it as the creation counterpart to list/delete grant tools. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough that an agent can infer when to use it. This aligns with 'clear context, no exclusions'.

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

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

The description adds behavioral details beyond the already informative annotations: it sends nothing to the network and does not display the token. This provides extra safety context (e.g., no side effects) that the annotations don't fully convey, though the readOnlyHint already implies no mutation.

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

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

The description is compact and well-structured, starting with the core purpose, then providing specifics (token source, expiry, file location) and ending with usage guidance. Every sentence carries meaning without redundancy.

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

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

For a zero-parameter tool with no output schema, the description is complete: it explains what the tool shows, where data comes from, that it's safe, and when to invoke it. No additional information is needed for an agent to use it appropriately.

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

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

With zero parameters, the description doesn't need to explain any, and per the baseline rule, a score of 4 is appropriate. The description correctly focuses on what the tool reports, not on inputs.

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

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

The description clearly states the tool shows connection status to Yandex Audiences, including token presence, source, expiry, and file location. It distinguishes itself from sibling tools that handle pixels, segments, and auth flows, making its purpose unambiguous.

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

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

The description gives an explicit trigger: 'Вызовите это, если инструменты Аудиторий отвечают, что подключение не настроено.' It tells when to use, though it doesn't explicitly mention when not to use or alternatives, but that's not critical for a status tool.

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

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

Annotations indicate write operation (readOnlyHint=false), not destructive. Description adds async processing behavior ('обработка занимает время, статус смотрите через list_segments') and discloses size restrictions (check_size=false allows <100 records, unusable in Direct until >100). These go beyond annotations and help agent set expectations.

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

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

Description is information-dense but efficient: two sentences pack purpose, workflow position, parameter details, constraints, and response format. No filler, but slightly long given that some info duplicates schema descriptions. Still earns its place by providing context.

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

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

For a 7-parameter mutation tool with no output schema, description covers workflow, parameter semantics, response format, and follow-up status check. It does not cover error scenarios or permissions, but those are not mandatory. Overall, agent has enough context to invoke correctly.

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

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

Schema coverage is 100%, but description adds context: explains enum meanings for content_type (idfa_gaid, mac, crm), defaults (CROSS_DEVICE), and special constraints (IN_DEVICE only for idfa_gaid, SHA256 only). It also clarifies check_size behavior with real-world implication, adding value over schema.

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

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

Description states a specific action: 'Сохраняет сегмент, созданный из файла' (saves a segment created from a file), and clearly positions it as the second step after upload tools. It differentiates from siblings like rename_segment and delete_segment by describing the save/confirm workflow.

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

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

Explicitly says when to use: 'второй шаг после upload_segment_file / upload_segment_csv_file' (second step after uploading). Also tells agent to check status via list_segments, implying not to use this for status. Provides constraints like check_size and hashing algorithm choices.

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

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

Beyond the annotations (which state not read-only, not destructive), the description discloses critical behavioral traits: asynchronous processing with status via list_segments, response shape {"segment": {...}}, and rate limits (10/min, 100/hour, 500/day). It also explains the default values for maintain_device_distribution and maintain_geo_distribution, adding significant context beyond the schema.

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

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

The description is compact but information-dense. It front-loads the core purpose, then explains parameters, response format, async behavior, and rate limits in a logical sequence. No sentence is wasted; even the quota is essential for operational expectations.

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

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

Given the tool's complexity (5 parameters, async processing, rate limits) and the absence of an output schema, the description covers all essential aspects: what it does, how parameters affect behavior, what response to expect, how to monitor completion, and rate limits. It is a model of completeness for a creation tool.

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

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

The input schema already covers all parameters, but the description adds meaningful semantics: it elaborates the trade-off of lookalike_value (accuracy vs reach) and explicitly states the default true for the two boolean flags. This goes beyond the schema descriptions, which do not mention defaults. The name parameter gains no extra detail, but overall the description augments parameter understanding.

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

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

The description clearly states it creates a lookalike segment, explaining the concept of 'similar users' and referencing the source segment (lookalike_link). This distinguishes it from sibling tools like create_pixel_segment or upload_segment_file, which serve different segment creation or upload purposes.

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

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

The description implies when to use this tool by specifying the lookalike segment type and the required source segment. It also directs the user to list_segments for checking async status, providing a follow-up action. However, it does not explicitly contrast with alternative creation tools like create_pixel_segment, so it lacks an explicit exclusion clause.

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

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

Given annotations already flag readOnly=false and destructive=false, the description adds valuable behavioral context by revealing the response structure (pixel object with url field) and the required next step (inserting code into ads). It does not contradict annotations and provides more detail than the bare schema, though it does not elaborate on side effects beyond creation.

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

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

The description is two sentences, front-loaded with the primary purpose, and every sentence adds value—first stating the creation function, second explaining the response and subsequent usage. No redundant or filler content.

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

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

For a simple one-parameter create tool with complete schema coverage and annotations, the description covers the essential aspects: creation, response shape, and downstream usage. It even explains the purpose of the returned field, making it self-contained for invocation.

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

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

The schema covers the single 'name' parameter with a description, so the baseline is 3. The description merely references 'the specified name' without adding format, constraints, or additional meaning beyond the schema. No extra parameter insight is provided.

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

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

The description clearly states the tool creates a Yandex Audiences pixel with a given name, using a specific verb and resource. It also distinguishes from sibling tools by mentioning the response and the follow-up tool create_pixel_segment, making its purpose unambiguous.

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

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

The description provides context on when to use the tool (initial pixel creation) and explains the workflow of inserting the pixel code into banners and then using create_pixel_segment. It does not explicitly contrast with alternatives like update_pixel or delete_pixel, so it lacks explicit when-not guidance, but the context is clear.

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

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

The description goes significantly beyond the minimal annotations (readOnlyHint=false, etc.) by disclosing rate limits ('Квота: 10/мин, 100/час, 500/сутки'), the response format ('{"segment": {...}}'), and the experimental nature of device_matching_type. These behavioral traits are not covered by the annotations, making the description highly transparent.

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

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

The description is concise and information-dense, covering purpose, parameter logic, experimental warnings, response format, and rate limits in a few sentences. Every clause provides useful guidance without fluff or redundancy, and the core purpose is front-loaded.

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

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

For a tool with 11 parameters and no output schema, the description is quite complete: it explains the core logic, experimental parameter, response shape, and quotas. It does not mention potential follow-up steps like confirmation (the sibling confirm_segment exists), which could be relevant context, but given that the schema fully covers parameter semantics, the overall picture is strong.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds cross-parameter meaning by stating that conditions combine via logical AND ('Дополнительные условия объединяются по «И»'), which is not in the schema. It also reinforces the pairing of times_quantity and times_quantity_operation, adding value beyond the individual parameter descriptions.

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

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

The description explicitly states the tool's function: 'Создаёт сегмент типа pixel' (creates a pixel-type segment), identifying the resource (segment) and the specific base (pixel_id from list_pixels). This clearly distinguishes it from sibling tools like create_lookalike_segment, which create different segment types.

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

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

The description provides clear usage context by explaining how to construct the segment: 'пользователи, которых пиксель видел за последние period_length дней' and that additional conditions combine by 'AND'. It even flags device_matching_type as experimental, advising caution. However, it does not explicitly mention alternatives or when not to use this tool (e.g., using lookalike segments instead), missing the top criterion for a 5.

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

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

The description adds value beyond the destructiveHint annotation by specifying the successful response format and disclosing the existence of an undelete API method via raw_request. This provides useful behavioral context about reversibility and recovery options.

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

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

The description is extremely concise at two sentences, front-loading the core purpose and adding only essential behavioral details. Every sentence serves a purpose: stating the action and providing success/recovery information.

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

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

For a simple delete tool with one well-documented parameter and clear annotations, the description covers the essential context: what it deletes, the success response, and the recovery path. No output schema exists, but the description adequately addresses return behavior.

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

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

The input schema already fully describes the only parameter, pixel_id, including its source ('id из list_pixels') and constraint (exclusiveMinimum: 0). The description adds no additional parameter semantics, so the baseline score of 3 applies.

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

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

The description clearly states the tool's function: 'Удаляет указанный пиксель Яндекс Аудиторий' (Deletes the specified Yandex Audiences pixel). It uses a specific verb and resource, distinguishing it from sibling tools like update_pixel and create_pixel.

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

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

The description implies usage from the verb 'delete' and mentions the recovery method via raw_request, providing some context. However, it does not explicitly state when to use this tool versus alternatives or exclude any scenarios, leaving the guidance implicit rather than explicit.

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

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

Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds the crucial context that the operation is irreversible and that no recovery method exists in the API. It also discloses the success response format, which is not covered by the annotations. This adds genuine value without contradicting the annotations.

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

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

The description consists of two concise sentences that immediately state the action and key caveat. There is no redundant information or filler, making it highly efficient and well-structured.

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

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

For a simple one-parameter tool, the description combined with annotations and schema provides sufficient context: what it does, how to identify the target, the irreversible nature, and the expected response. Minor aspects like error behavior are not covered, but given the tool's simplicity, this is mostly complete.

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

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

The input schema fully describes the only parameter, segment_id, including its type, constraints, and source (from list_segments or creation response). With 100% schema coverage, the description does not need to add parameter details, and the baseline of 3 is appropriate.

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

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

The description uses the specific verb 'Удаляет' (deletes) with the resource 'сегмент' (segment), clearly indicating what the tool does. The action is distinct from sibling tools like rename_segment or list_segments, making its purpose unambiguous.

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

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

The description mentions deletion of a specified segment and explicitly warns that the operation is irreversible, providing clear context for when to use it. It does not explicitly name alternatives, but the sibling toolset and the nature of the operation make the appropriate usage obvious.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds the successful response format ({"success": true}), but does not elaborate on effects such as whether an error occurs if the user has no existing grant, or whether the operation is truly idempotent in practice.

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

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

The description is a single, focused sentence followed by the success response. Every element is necessary and no redundant information is present.

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

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

For a simple revoke operation with two well-documented parameters, the description provides sufficient context to invoke the tool correctly. It mentions the success response format, which is useful given the absence of an output schema. Missing details about error cases and idempotency behavior are minor gaps.

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

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

The input schema fully describes both parameters with clear descriptions (segment_id and user_login), so the schema coverage is 100%. The description adds no additional parameter semantics beyond what the schema already provides.

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

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

The description clearly states the tool's function: 'Удаляет разрешение на управление сегментом у указанного пользователя' (deletes the permission to manage a segment from a specified user). This distinguishes it from sibling tools like add_segment_grant (which grants access) and delete_segment (which deletes the segment entirely).

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

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

The usage context is implied by the description and sibling tools: it is the inverse of add_segment_grant. However, there is no explicit guidance on when to use this tool versus alternatives, prerequisites, or scenarios where it should not be used.

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

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

The description adds useful context: token file permissions (0600), live verification against Audiences, no need to restart the client, and a 10-minute one-time code. However, the annotations declare idempotentHint=true, while the description explicitly says the code is one-time and requires a fresh start_login call if rejected. Repeated calls with the same consumed code are therefore not idempotent, so the description contradicts the annotations.

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

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

Three dense sentences front-load the primary purpose and then provide necessary side-effect, activation, and retry details. No filler or redundant restatement of schema fields.

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

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

For a single-parameter authentication tool with no output schema, the description is complete: it covers input source, token persistence, verification, immediate availability of other tools, and failure recovery. The only issue is the annotation contradiction, which is already reflected in behavioral transparency.

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

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

The schema already documents the single required code parameter with 100% coverage, so the baseline is 3. The description adds important semantics beyond the schema: the code comes from start_login, is single-use, expires after 10 minutes, and should be refreshed if rejected.

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

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

The description clearly identifies this as the second connection step: it exchanges the confirmation code from start_login for an access token. This specific verb+resource framing distinguishes it from start_login and all sibling tools.

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

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

It explicitly frames usage as the second step after start_login, states that other tools become available immediately after success, and instructs the caller to invoke start_login again for a fresh code if the current code is rejected. This gives clear when-to-use and retry guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by detailing the response fields (id, name, create_time, url, coverage counts, segments), giving the agent a precise expectation of what the tool returns. No contradictions with annotations.

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

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

The description is a single well-structured sentence that front-loads the primary purpose and then systematically specifies the response format. Every component—purpose, response envelope, field list, and nested segments—earns its place with no redundancy.

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

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

With no parameters and no output schema, the description carries the full burden of explaining the tool's contract. It provides a thorough breakdown of the response object, including coverage metrics and nested segments, making the tool fully understandable for an agent. The annotations cover safety, so nothing critical is missing.

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

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

The tool has zero parameters, so the schema is trivially covered at 100%. The description correctly adds no parameter details, and the baseline score of 4 for zero-parameter tools applies.

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

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

The description opens with a specific verb 'Возвращает' and a clearly defined object 'список пикселей Яндекс Аудиторий пользователя', which unambiguously identifies the tool as a read-only list operation for the user's pixels. The addition of the response structure further solidifies the purpose and distinguishes it from sibling tools like list_segments.

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

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

The description provides clear context for when to use this tool—when you need to retrieve the user's pixels. It does not explicitly name alternatives or exclusions, but the simplicity of the tool and the distinct sibling names make the intended usage obvious, so this is a minor gap.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable detail about the response structure, including field names and permission values (edit/view), going beyond the annotations. No contradictions.

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

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

The description is a single, focused sentence that front-loads the main action and includes essential response details. No filler or redundant content.

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

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

Despite no output schema, the description fully specifies the return format including fields and allowed permission values. For a simple list tool with good annotations and a single well-documented parameter, this is complete.

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

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

The input schema already provides thorough documentation for segment_id (source, type, constraints). The description does not add additional parameter guidance, and with 100% schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly states the tool returns a list of permissions for a segment, with a specific verb and resource. It distinguishes itself from siblings like list_segments (which lists segments) and add_segment_grant/delete_segment_grant (which modify grants).

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

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

The description implies when to use the tool (to view segment permissions) but does not explicitly state conditions or alternatives. It lacks a clear 'when not to use' or comparison with related tools like add_segment_grant.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses the full response structure, including segment fields, statuses, type-specific fields, pagination parameters, default limit, and the pixel filter. It also warns that there is no separate get endpoint, adding valuable behavioral context not covered by annotations.

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

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

The description is appropriately sized for the tool's complexity. It front-loads the main purpose, then gives a structured explanation of the response, pagination, and filtering in three additional sentences. Every sentence adds value, with no redundant or filler content.

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

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

Given that there is no output schema, the description fully compensates by detailing the response format, fields, statuses, and type-specific attributes. It also covers pagination behavior and a non-obvious caveat (no single-segment fetch method). This makes the tool's behavior clear and complete for an agent.

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

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

The input schema already covers all three parameters (limit, offset, pixel) with descriptive comments, and schema_description_coverage is 100%. The description adds only a brief restatement of pagination and the pixel filter, which does not go beyond the schema's explicit parameter descriptions. Baseline 3 is appropriate.

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

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

The description clearly states 'Возвращает список сегментов Яндекс Аудиторий, доступных пользователю' with an explicit list of segment types, distinguishing it from sibling tools that create/upload/delete segments. The verb+resource+scope is specific and unambiguous, and it also notes the absence of a single-segment method, reinforcing its purpose.

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

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

It provides explicit guidance on when to use this tool: not only for listing all segments but also as the sole way to fetch a single segment ('Отдельного метода получения одного сегмента в API нет — фильтруйте этот список по id'). This is a clear alternative usage instruction, equivalent to the get_calls example.

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

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

Beyond the annotations (destructiveHint=true, readOnlyHint=false, idempotentHint=true), the description adds critical context: it only deletes the token from disk, does not affect the env var token, and the server-side access remains active. It also mentions how to revoke access via Yandex ID, which is essential for the agent to understand the tool's full effects. 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.

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

Three sentences, each with a distinct purpose: what it deletes, what it doesn't touch, and what remains active. No fluff, all information is directly relevant. The structure is logical and front-loaded with the primary action.

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

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

Given no parameters and no output schema, the description covers all necessary aspects: action, scope, exceptions, and consequences. It fully explains the tool's behavior and implications, leaving no gaps for the agent.

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

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

The tool has zero parameters and the schema coverage is 100% (there are no parameters to document). The description doesn't need to elaborate on parameters, so a baseline of 4 is appropriate.

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

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

The description clearly states the verb+resource: 'Deletes the saved Audiences token from disk'. It distinguishes itself from login-related siblings (start_login, finish_login, auth_status) by specifying the exact action and its scope. No ambiguity about what the tool does.

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

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

The description implies when to use it (when you want to log out by removing the token from disk). It also provides important guidance about the env var token not being touched and how to handle it, which is crucial for correct usage. It doesn't explicitly name alternatives, but there are no direct logout siblings, so it's adequate.

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

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

Although annotations already disclose write, destructive, and open-world behavior, the description adds important context: the Authorization header is automatically injected, paths to foreign hosts are rejected, and query parameters must be embedded in the path. These behaviors are not captured by the annotations and help the agent understand safety and execution constraints.

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

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

The description is compact (a few sentences) and front-loaded with the core purpose ('Escape hatch'). It efficiently uses examples and procedural notes without redundancy, and every sentence contributes meaningful information about usage and constraints.

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

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

For an escape-hatch tool with no output schema and open-world behavior, the description covers the essential request aspects: relative path format, query parameter placement, JSON body handling, and automatic auth. It lacks explicit mention of response format or error handling, but these are inherently raw and unpredictable for such a tool, so the description is sufficiently complete given the context.

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

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

The input schema already provides detailed descriptions for all three parameters (path with example, body as JSON, method default GET) with 100% coverage, so the baseline is 3. The description reinforces this information but does not add new parameter-level meaning beyond what the schema already specifies. The additional notes on auth and host restrictions are behavioral, not parameter semantics.

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

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

The description explicitly identifies the tool as an 'escape hatch' for direct calls to any Yandex Audience API endpoint, using the verb 'прямой вызов' (direct call). It distinguishes itself from sibling tools by specifying it's for endpoints without a dedicated tool, and provides concrete examples (PUT reprocess, POST undelete) that are not in the sibling list.

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

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

The description states when to use this tool: 'для эндпоинтов без выделенного инструмента' (for endpoints without a dedicated tool), which clearly defines the usage context. It implicitly signals that dedicated sibling tools should be preferred when available, and the examples illustrate scenarios not covered by siblings. This provides clear guidance on tool selection.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds value by explaining that despite the generic 'change' wording, it only affects the name (effectively rename), works with any segment type, and returns the updated segment object. This provides useful context 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.

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

The description is two sentences, immediately states the primary action, and includes the key scope and response details. Every sentence earns its place without redundancy.

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

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

For a simple rename tool with two well-documented parameters, strong annotations, and a described response shape, the description is complete. It does not need to cover edge cases or errors, as the schema and annotations handle the core expectations.

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

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

Schema description coverage is 100% for both parameters (name and segment_id). The description adds no additional parameter-specific guidance beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description states a specific action ('Изменяет сегмент') and immediately clarifies that the only mutable field is name, making it effectively a rename. It also distinguishes from sibling tools by noting it works with any segment type, which sets it apart from creation tools like create_lookalike_segment and create_pixel_segment.

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

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

The description clearly implies when to use this tool: when you need to rename a segment, since only the name field is available. It doesn't explicitly mention exclusions or alternatives, but the scope is obvious given the sibling tools (delete, create, upload). The context is clear enough to guide selection.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context: the returned link is for OAuth, the code expires in 10 minutes, and only this server can exchange the code, which is a useful security disclosure. It does not contradict the annotations, but it could mention what happens if the user is already authenticated or the outcome of the step.

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

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

The description is moderately sized with six sentences, each contributing useful information: purpose, return value, user instructions, handoff to finish_login, code validity, and security. It is slightly verbose but not padded, and the key message (first step, returns OAuth link) is front-loaded.

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

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

For a zero-parameter tool with no output schema, the description is fairly complete: it explains the return value, the required user actions, the next step, and the code's validity and security. It does not describe the exact format of the returned link or edge cases, but these are not critical for invoking this tool correctly.

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

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

The tool has zero parameters and an empty input schema, so schema coverage is trivially 100%. Per the rubric, 0 parameters is a baseline 4; the description has no parameter details to add, which is appropriate since none exist.

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

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

The description clearly states this is the first step of connecting Yandex Audiences and that it returns a link to the Yandex OAuth page, using a specific verb ('start' / 'Первый шаг') and resource. It distinguishes itself from sibling tools by explicitly naming finish_login as the next step and noting that no config changes or restart are required.

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

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

The description gives explicit usage context: it is the first step, and after receiving the confirmation code the agent must pass it to finish_login. This directly indicates when to use this tool versus the sibling completion step, and the user instructions clarify the flow. It effectively communicates the when and the handoff.

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

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

Annotations provide idempotentHint=true and destructiveHint=false, but the description adds valuable behavioral context: the operation is strictly a rename, and the response format is disclosed as {"pixel": {...}} with updated data. This 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.

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

The description is a single, well-structured sentence that front-loads the primary action and includes the key constraint and response shape. No redundant information is present, making it highly concise.

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

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

For a simple 2-parameter update tool with rich annotations and full schema coverage, the description is sufficiently complete: it explains the exact scope of the update, the response format, and the requirement of pixel_id. Minor gaps like error handling are not necessary for this simple operation.

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

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

The input schema already provides 100% parameter coverage with clear descriptions for both name and pixel_id, so the description adds marginal semantic value. It reinforces that only name is changeable, but this is also inferable from the schema, which lists name as the only mutable property.

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

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

The description uses a specific verb 'Changes' with a resource 'specified pixel' and immediately clarifies the scope as 'only the name field — renaming'. This clearly distinguishes it from siblings like delete_pixel and aligns with the title 'Переименовать пиксель'.

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

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

The description conveys that this tool is for renaming only, as it explicitly states 'only the name field is available for change', providing clear context for when to use it. It doesn't explicitly mention alternatives, but the sibling list includes rename_segment for segments, so the intended use case is unambiguous.

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

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

Beyond the annotations, the description discloses important behavioral traits: the two-phase creation flow, the uploaded status and id in the response, the need for subsequent confirmation, the 100-record minimum and 1 GB maximum size, and the creation rate limits (10/min, 100/hour, 500/day).

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

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

The description is longer than average but every sentence contributes essential information: file format, constraints, two-phase flow, data source options, and quotas. It is front-loaded with the primary purpose and well-structured.

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

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

For a multi-phase tool with no output schema, the description covers all necessary context: input format, source selection, size limits, status semantics, next step, and rate limits. It is sufficiently complete for an agent to invoke correctly.

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

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

The schema already has 100% description coverage for all three parameters, including the 'exactly one' constraint. The tool description repeats this constraint but does not add new parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool creates a segment from a CSV file with CRM data, using a specific verb and resource. It also distinguishes itself from siblings by emphasizing the CSV format and the two-phase creation flow with confirm_segment.

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

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

The description gives clear context: this is the first step of a two-phase process, followed by confirm_segment. It also clarifies the data source must be exactly one of file_path or content. However, it does not explicitly contrast with the sibling upload_segment_file, so it lacks a direct when-not-to-use statement.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description reveals important behaviors: creation is non-idempotent (first step of two-phase), creates a segment with status 'uploaded' and an id, requires subsequent confirmation, and imposes quotas (10/min, 100/hour, 500/day). These details add substantial context beyond the structured annotations and are not contradicted by them.

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

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

The description is three sentences long, front-loaded with the primary purpose, and each sentence provides necessary information (create action, format/constraints, two-phase workflow, parameter source, quotas). There is no redundancy or filler; every word contributes to understanding the tool.

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

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

For a tool with no output schema, the description adequately covers the response (segment with status 'uploaded' and its id), the mandatory follow-up (confirm_segment), and edge constraints (min records, max size, quotas). It also clarifies the parameter exclusivity rule, making the tool fully understandable for correct invocation despite its complexity.

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

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

The input schema already provides 100% coverage with descriptions for each parameter (content, file_name, file_path) and explicitly states the 'exactly one' exclusivity. The description adds value by reinforcing the source data choice ('ровно одно из двух') and contextualizing the parameters with file format constraints (TSV/TXT, UTF-8, record count, size limit). Since the schema is thorough, the description supplements rather than carries the burden, but it still exceeds the baseline.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Создаёт сегмент из TSV/TXT-файла с данными' (Creates a segment from a TSV/TXT file). It explicitly differentiates from the sibling tool upload_segment_csv_file by specifying TSV/TXT format, and outlines the two-phase process, 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.

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

The description explicitly explains when to use this tool: as the first step of a two-phase process, followed by confirm_segment. It also specifies data source requirements (file_path or content, exactly one) and format constraints (UTF-8, min 100 records, max 1 GB), effectively guiding the agent on appropriate usage without needing to reference a separate tool for the same purpose.

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