yandex-direct-mcp

by nikolaymokh-dev

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.3
Disambiguation5/5
Each tool has a clearly distinct purpose, grouped by functional area (auth, changes, dictionaries, keywordsresearch, leads, reports, v4*). Within groups, create/get/list patterns are well-separated, and descriptions clarify any potential overlap.
Naming Consistency5/5
Tool names follow a consistent area_verb pattern (e.g., auth_login, dictionaries_get, v4forecast_create). The only exception is tool_help, a meta tool. All others adhere to snake_case and predictable naming.
Tool Count4/5
26 tools is slightly above the typical 3-15 range, but it is justified by the breadth of features covered (authentication, changes, dictionaries, keyword research, leads, reporting, v4 Live API). The organization keeps it manageable.
Completeness2/5
The tool set focuses on data retrieval and analysis (reports, dictionaries, changes, forecasts) but lacks core campaign management operations such as creating, updating, or deleting campaigns, ad groups, or bids. This limits its completeness for full Yandex Direct management.
Average 3.2/5 across 26 of 26 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 53 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only says 'Deduplicate a list of keywords' without disclosing how deduplication works (e.g., deterministically, case-insensitive), what the output is, or any side effects. This is insufficient for behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not concisely helpful. The second sentence instructing to call tool_help is wasteful; it could be replaced with parameter details. The first sentence is adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is incomplete. It does not specify expected input format, return value, or any constraints, leaving the agent without enough context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain the 'keywords' parameter format (e.g., comma-separated or newline-separated). The agent cannot infer how to provide the list correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Deduplicate a list of keywords' which clearly identifies the verb and resource. However, it does not distinguish this tool from siblings like keywordsresearch_has_search_volume, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It instructs to call tool_help for parameters, but that is not a usage guideline for the tool itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it's a read operation ('Get...'), no disclosure of side effects, auth needs, rate limits, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short description but includes a redundant call to tool_help. Could be more informative in the same space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and no descriptions, the description does not cover output, error handling, or pagination. Relies entirely on external help and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and description adds no parameter meaning. Instead directs to tool_help, which is not part of the definition. Leaves agent without any parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get', resource 'v4 Live events log entries', and scope 'timestamp range'. Clear purpose, though no explicit differentiation from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The phrase 'for a timestamp range' implies context but offers no exclusions or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover safety, side effects, and authorization. It mentions a limit of 100 phrases but omits details like whether the operation is idempotent, what happens on failure, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence), but it lacks substance. Conciseness is good, but it sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the creation tool's description is too sparse for an agent to use confidently. The suggestion to call tool_help indicates the description itself is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the schema property names. It defers to tool_help instead of explaining parameters like geo_ids, currency, or dry_run.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a v4 Live budget forecast via CreateNewForecast') and a key constraint ('up to 100 phrases'). It distinguishes from sibling tools like v4forecast_get and v4forecast_list by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, and no context on when not to use it. The only usage hint is to call tool_help, which shifts the burden elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It mentions 'ready' forecast but does not explain what readiness means, nor any side effects, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, but the second is redundant given the schema. Could be more concise by removing the tool_help call, which is unnecessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return values are covered. However, description lacks context on prerequisites, error handling, data freshness, and how forecast_id relates to other tools like v4forecast_list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter forecast_id lacks explanation of its source or format. Schema coverage is 0% and the description only says 'by ID' and refers to tool_help, providing no meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a v4 Live budget forecast by ID, using the verb 'Get' and specifying the resource. It distinguishes from sibling tools like v4forecast_create and v4forecast_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool or alternatives. The description only mentions calling tool_help for parameters, which adds no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description adds no behavioral details such as idempotency, authorization needs, or rate limits. It merely restates the listing action without disclosing any behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise, but the second sentence instructing to call tool_help is unnecessary given the schema is provided, wasting half the description's space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple with one parameter and an output schema exists, the description lacks essential context about behavior and preconditions, making it incomplete for an AI agent given no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says 'Call tool_help for parameters', adding no meaning to the input schema. The schema has 0% description coverage, and the description fails to compensate, leaving the parameter 'dry_run' unelaborated.
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 'List v4 Live Wordstat reports', using a specific verb and resource. It directly addresses the tool's function and distinguishes it from sibling tools like 'v4wordstat_create_report' and 'v4wordstat_get_report'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for listing but lacks context for when not to use it or comparison with other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides minimal behavioral insight. It states the tool checks search volume but does not disclose if it is read-only, destructive, rate limits, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence and a call to action. It is front-loaded and efficient, but lacks depth for parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and sibling tools, the description is insufficient. It does not explain what 'search volume' means, how results are returned, nor the role of the 'fields' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only mentions 'keywords' and 'regions' implicitly via the purpose statement. The 'fields' parameter is completely unexplained. The description does not compensate for missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if keywords have search volume in given regions, using specific verbs and resources. It distinguishes from siblings like keywordsresearch_deduplicate and v4keywords_get_suggestion, though it doesn't provide explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as v4keywords_get_suggestion. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. It only states the action without describing side effects, required permissions, error states, or what happens if the report is not ready. It does not add value beyond the tool's name.
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 very short (two sentences) and front-loaded with the purpose. However, the second sentence directing to tool_help is redundant if the description itself provided parameter info. Still, it is concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and an output schema, the description should explain what the report contains and how to use dry_run. It covers neither. The description is incomplete for an agent to reliably use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. Instead, it defers entirely to tool_help. It provides no meaning for 'report_id' or 'dry_run', nor their requiredness, types, or usage. This fails to add value beyond the schema's basic structure.
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: 'Get a ready v4 Live Wordstat report by ID'. This is a specific verb (Get) and resource (v4 Live Wordstat report), and it distinguishes from sibling tools like v4wordstat_create_report and v4wordstat_list_reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., having a report ID from a previous creation) or conditions (e.g., report must be ready). The description lacks any context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It merely states 'check status' without mentioning side effects, authorization requirements, or whether the operation is safe/read-only. Key behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise. However, the cross-reference to tool_help is somewhat unusual and disrupts a self-contained structure. No unnecessary words, but could be more logically organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and detailed parameter info, the description is incomplete. It does not explain return values, error conditions, or when this tool is appropriate. A simple check tool should provide more context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('profile') with 0% description coverage, and the tool description does not explain its meaning or usage. The reference to tool_help does not add semantic value within this definition. The description fails to compensate for the schema's lack of parameter details.
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 purpose: 'Check the current direct auth profile status (token presence, login, expiry).' It uses a specific verb ('Check') and identifies the resource ('auth profile status') with explicit aspects. This distinguishes it from siblings like auth_login or auth_setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only says 'Call tool_help('auth_status') for parameters,' which delegates guidance elsewhere. There is no explanation of when to use this tool versus alternatives like auth_login or auth_setup. The agent receives no contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states it 'gets' entries, implying read-only, but does not confirm idempotency, side effects, or limitations like rate limits. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, first is clear and direct. The second sentence instructing to call tool_help is redundant given the input schema, but does not detract much from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 4 parameters (1 required), the description lacks detail on return format, filtering syntax, and behavior. Only high-level overview, incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions filtering by 'name' and 'region IDs', but does not explain the required 'fields' parameter or the format for 'exact_names'. Insufficient to understand parameter usage.
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 'Get GeoRegions dictionary entries', specifying the action and resource. It distinguishes from siblings like 'dictionaries_get' and 'dictionaries_list_names' by naming the specific dictionary type (GeoRegions) and mentioning optional filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as 'dictionaries_get' for other dictionary types. Does not specify when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool gets dictionary data but does not mention whether it is read-only, requires authentication, has rate limits, or any other behavioral traits. The mention of tool_help for parameters is helpful but does not cover behavioral aspects.
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 extremely concise: two sentences that efficiently state purpose and provide usage guidance in a front-loaded manner. Every sentence adds value with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (generic dictionary getter), the absence of output schema, annotations, and param descriptions means the description should compensate more. It lacks return format, param format, and behavioral info, relying on tool_help for parameters, which is insufficient for complete contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the required 'names' parameter. The description partially compensates by giving examples (Currencies, GeoRegions) and directing to tool_help for details, but it does not specify the expected format (e.g., comma-separated string vs. array). This leaves ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets reference dictionary data by names and provides examples (Currencies, GeoRegions, etc.). It distinguishes from the sibling 'dictionaries_list_names' which lists available options, and implicitly from 'dictionaries_get_geo_regions' which is more specific. However, it does not explicitly state that the tool returns data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using 'dictionaries_list_names' to see available options, which gives context on when to use this tool. It also directs to 'tool_help' for parameters. However, it does not explicitly state when not to use this tool or compare it to other siblings like 'dictionaries_get_geo_regions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks behavioral traits: no mention of side effects, permissions, rate limits, or response handling. Only constraint (10 phrases) and a meta-instruction to call tool_help.
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?
Single sentence with front-loaded purpose. Efficient, but could integrate parameter details instead of deferring to tool_help.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, description omits critical details: return value (report ID?), asynchronous behavior, error conditions. Incomplete for a creation tool with 3 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. Description adds no parameter meaning beyond names. 'phrases' and 'geo_ids' are obvious, but 'dry_run' is not explained. Defers to tool_help for parameters.
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?
Clearly states it creates a v4 Live Wordstat report via a specific API call, with explicit phrase limit (10). Distinguishes from sibling tools like v4wordstat_get_report and v4wordstat_list_reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. The name implies creation, and siblings for retrieval exist, but no direct when-to or when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states 'Get' implying a read operation but does not disclose any side effects, authentication requirements, rate limits, or other behavioral traits. Basic purpose is clear but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, but the second sentence requires the agent to invoke another tool for parameter details, which reduces efficiency. It is not optimally structured for self-contained usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with one parameter, relying on tool_help for essential parameter information. While output schema exists, the lack of parameter details makes it insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description offers no parameter guidance, simply redirecting to tool_help for parameters. The agent receives no information about the format or constraints of campaign_ids.
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 verb 'Get' and the resource 'retargeting goals for campaigns', and explicitly distinguishes from sibling v4goals_get_stat_goals by noting it's for Metrica stat goals.
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 an explicit alternative tool for a different use case (Metrica stat goals), guiding the agent when not to use this tool. However, it does not elaborate further on when to use this tool vs other siblings, though the alternative is sufficient for this context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. The description mentions 'v4 Live' but does not clarify whether the tool is read-only, destructive, or side effects. It lacks details on permissions, data freshness, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loads the purpose, but the second sentence defers parameter information to an external help tool, which reduces conciseness effectiveness. It could be more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one required parameter with no schema coverage, and the description provides no input guidance. Although an output schema exists, the lack of behavioral transparency and parameter documentation makes the description incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the campaign_ids parameter. Instead, it defers to tool_help for parameter details, adding no semantic value. The parameter's format, allowed values, and meaning are left entirely unspecified.
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 'Get Yandex Metrica stat goals available for campaigns (v4 Live)', providing a specific verb and resource. It also distinguishes from the sibling tool v4goals_get_retargeting_goals by noting the difference in goal type.
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 directs users to use v4goals_get_retargeting_goals for retargeting goals, offering clear guidance on when to choose an alternative. However, it does not specify when not to use this tool beyond that, and suggests calling tool_help for parameters, which is somewhat unusual.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavior. It only says 'save... token', implying a write operation, but omits any side effects, permissions needed, or what constitutes success/failure. The mention of token prefix 'y0_...' is a minor plus.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. The first sentence conveys the core purpose, the second offers contextual alternatives and help. Could be slightly more efficient by integrating parameter hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no output schema or annotations, the description is insufficient. It doesn't explain parameter roles, return values, or error cases, leaving the agent to rely on external tool_help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no meaning for any of the 3 parameters. The instruction to 'call tool_help' does not add semantic value to the parameters themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Save a ready-made direct OAuth token') and the resource ('direct auth profile'), and distinguishes from the sibling tool auth_login by specifying the type of token flow.
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 tells when to use auth_login instead ('use auth_login for the interactive browser flow'), providing an alternative. It also directs users to tool_help for parameters, which is helpful but doesn't give detailed context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool checks for changes and takes no parameters, ignoring return type, side effects, or safety information like read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an unnecessary second sentence directing users to tool_help for parameters, which is wasteful given the schema already shows no parameters. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description does not explain what the tool returns (e.g., boolean or list). Given the tool's simplicity, this omission leaves the agent guessing the result format.
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?
There are no parameters (schema has empty properties). The description redundantly states 'takes no parameters', but since schema coverage is 100% and baseline for 0 parameters is 4, the score 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 checks whether Yandex.Direct reference dictionaries (e.g., regions) have changed. It uses a specific verb ('Check') and resource, and distinguishes from sibling tools like dictionaries_get (which retrieves) and changes_check_campaigns (campaign-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies it is for checking dictionary change status, but no comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks behavioral details such as authentication needs, side effects, or data freshness. Only states it lists form submissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and scope. The second sentence is a deferral, but overall structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, return format unexplained, and 6 parameters are not documented. Lacks enough information for agent to use correctly without external help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description fails to explain parameters. Defers to tool_help, which shifts burden to external reference instead of providing meaning.
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?
Description clearly states 'List leads' for Turbo pages and distinguishes from campaign scoping, eliminating confusion with sibling tools.
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?
Explicitly scopes to Turbo pages and excludes campaigns, providing clear context. Lacks when-not or alternative tools, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It mentions starting interactive login and eliciting authorization code but does not disclose behavior such as return value, side effects, or user interaction requirements. Agent cannot infer what happens after login.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. First sentence conveys primary action, second gives alternative and guidance. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity (3 optional params, no nested objects, no output schema), the description is incomplete. It fails to describe parameters or what to expect after invocation. Relies on external help. Not sufficient for an AI agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not explain any of the three parameters (login, profile, force). It merely defers to `tool_help`. Description adds zero meaning beyond the schema itself.
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?
Clearly states the tool's purpose: starting an interactive OAuth login to elicit an authorization code. Distinguishes from sibling tool `auth_setup`.
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 tells when to use this tool (interactive OAuth login) and when to use `auth_setup` instead (if you already have a y0_ token). Also recommends calling `tool_help` for parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as permission requirements, side effects, or rate limits. It only describes the input constraint without explaining the operation's nature (e.g., read-only).
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 that are front-loaded with the core purpose and constraint, followed by usage guidance and a pointer to tool_help. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and no output schema, the description provides the essential constraint and sibling differentiation but relies on tool_help for parameter details and omits return format and permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds meaning to only three parameters (campaign_ids, ad_group_ids, ad_ids) by stating they are mutually exclusive. Other parameters (field_names, fields) are not explained, and the description defers to tool_help for details.
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?
Clearly states the tool checks changes since a timestamp within specific objects (campaigns, ad groups, ads) and distinguishes itself from sibling 'changes_check_campaigns' for account-wide scans.
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 guidance: use for targeted checks with exactly one of three ID filters, and suggests alternative 'changes_check_campaigns' for account-wide scans. Does not mention when not to use, but the comparison is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool lists forecasts but does not disclose any behavioral traits like pagination, auth requirements, or side effects. The existence of an output schema partially compensates for return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences. It is front-loaded but could be slightly more structured. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description is minimally complete. However, it lacks details on pagination, limits, or potential errors that might be relevant for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100% trivially. The description adds no parameter information, but with no parameters, a baseline of 4 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 explicitly states 'List v4 Live budget forecasts', providing a specific verb and resource. It distinguishes itself from sibling tools like v4forecast_create and v4forecast_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, such as filtering or expected context. It only mentions calling tool_help for parameters, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two key behaviors: a limit of 20 phrases and that it spends API points. No annotations are provided, so the description carries the full burden. It omits other typical behaviors such as authentication requirements, rate limits, or whether the tool is read-only. The disclosure of the limit and cost is helpful but incomplete.
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 extremely concise: two sentences with no wasted words. The key information (purpose, limit, cost, and guidance to tool_help) is front-loaded in the first sentence. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required parameter, no nested objects, output schema exists), the description is fairly complete. It covers the function, a major constraint, and a side effect. The output schema likely explains return values, so that gap is acceptable. The only missing element is clarifying whether the tool is read-only or has other effects, but overall it suffices.
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 has 100% required parameters but 0% description coverage. The description adds value by specifying that the 'keywords' parameter accepts 'up to 20 phrases,' which is not in the schema. However, it does not explain that the parameter is an array of strings or provide format examples. More detail would improve semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Get related keyword suggestions'), resource ('keywords'), and constraints ('up to 20 phrases'). Mentions it's via 'v4 Live GetKeywordsSuggestion', which distinguishes it from other keyword tools. However, it does not explicitly differentiate from similar keywordsresearch tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a direct usage hint: 'Call tool_help("v4keywords_get_suggestion") for parameters.' It also notes that the tool 'spends API points,' suggesting it should be used judiciously. However, it does not specify when to use this tool over alternatives like keywordsresearch_deduplicate or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a simple listing behavior with no side effects, but lacks details on caching, rate limits, or other behavioral traits. Adequate for a straightforward read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no waste. Every word serves a 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?
Given the tool has no parameters and an output schema exists (context shows has output schema: true), the description is sufficiently complete. It explains the tool's purpose and directs to tool_help for additional info.
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 tool has no parameters, so baseline is 4. However, the description's instruction to 'call tool_help for parameters' is misleading since there are none, slightly reducing clarity. The schema coverage is 100% as there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists dictionary names accepted by dictionaries_get, with a specific verb and resource. It distinguishes from siblings by referencing a specific companion tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before dictionaries_get but does not explicitly state when to use or alternatives. It directs to tool_help for parameters, which is useful but does not provide context on when this tool should be chosen over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It mentions capabilities like pagination and file output, but does not disclose whether the tool is read-only, required permissions, rate limits, or side effects. Partial transparency is given by listing features, but not comprehensive enough for a complex tool.
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 that front-load purpose and capabilities, then provide usage guidance, then suggest help. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (25 params) and the existence of an output schema, the description gives a reasonable overview of purpose and key features. However, it lacks detailed parameter semantics, which could lead to misuse. Adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with 25 parameters. Description only broadly mentions 'FieldNames, filters, ordering, etc.' without explaining individual parameter semantics. Refers to tool_help for parameters, but does not compensate within the description itself. For a high-parameter tool, this is insufficient.
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?
Description clearly states 'Build an arbitrary Yandex.Direct statistics report' with specific capabilities like FieldNames, filters, and breakdowns. Explicitly distinguishes from sibling tool reports_get: 'use reports_custom for arbitrary fields & breakdowns; use reports_get for a quick recent snapshot.'
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 when-to-use guidance contrasting with reports_get and suggests tool_help for parameters. Does not mention when not to use or alternative siblings besides reports_get, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool checks campaign-level changes and requires a timestamp, but does not describe what changes are detected, whether it's read-only, or any auth/rate limit information. It adds some context but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first covers purpose and behavior, the second gives usage guidance and a pointer to tool_help. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description covers the basic function and usage distinction. However, it lacks details on return format, errors, or authorization. For a simple tool this may be adequate, but more behavioral context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the only parameter (timestamp). The description says 'since a timestamp' implying it's the starting point, but does not specify format or example. It defers to tool_help which is incomplete. The description adds minimal value beyond the schema field name.
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 function: 'Check account-wide campaign-level changes since a timestamp' with a specific verb (check) and resource (campaigns). It distinguishes from sibling tools like changes_check by noting it's a 'broad scan' vs. drilling into specific IDs.
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 tells when to use this tool ('Use this for a broad scan') and when to use the alternative ('use changes_check to drill into specific... IDs'). It also directs users to call tool_help for parameter details, which is helpful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read-only snapshot over a short window, but lacks details on default fields, aggregation, rate limits, or authentication needs. The behavioral insight is adequate but not deep.
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 extremely concise with three sentences, each serving a distinct purpose: explaining the tool, providing usage guidance, and directing to further help. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema and output schema existence, the description provides sufficient context for basic use. However, it omits details on default fields and output format, relying on tool_help for parameters, leaving moderate gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the date parameters or their format, instead directing to tool_help. This offloading means the description adds little semantic value for the parameters.
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 it provides a quick per-campaign performance snapshot over a short recent window (~last 8 days, default fields). It distinguishes itself from the sibling tool reports_custom, meeting the specific verb+resource and differentiation criteria.
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 says when to use (for a fast overview) and when not (use reports_custom for arbitrary fields, filters, or date/goal breakdowns). It even directs to call tool_help for parameters, providing excellent usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It adequately describes listing report types with guidance, but does not elaborate on side effects or auth needs. Output schema exists, reducing need for return details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and provide usage guidance with no wasted words.
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 simplicity (no parameters, output schema present) and surrounding siblings, the description fully covers what an agent needs to know to select and 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?
No parameters, so baseline is 4. Description adds value beyond schema by mentioning guidance and referring to tool_help for parameters, which is consistent with zero-param tool.
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?
Clearly states the tool lists supported Yandex.Direct report types with guidance, and distinguishes itself from sibling 'reports_custom' by recommending usage before that tool when unsure.
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?
Explicitly advises using this tool before 'reports_custom' if unsure which report type fits, providing clear context but no explicit exclusion of other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the tool returns full documentation including parameter reference, examples, and constraints, and lists all tools if name is omitted. It does not mention side effects or rate limits, but as a read-only documentation tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no wasted words. First sentence states purpose and content, second gives usage instructions. It is front-loaded and efficiently conveys all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple help tool with one optional parameter and no output schema, the description covers the main behaviors. It explains what the tool returns and how to trigger different modes. Minor omission: it does not describe the output format in detail, but 'parameter reference, examples and constraints' gives adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates: 'Pass the exact tool name (e.g. 'campaigns_add'); omit the name to list every available tool.' This provides clear semantics and behavior for the only parameter.
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: 'Get the full documentation for another tool'. It distinguishes from sibling tools by noting that other tools 'carry only a one-line summary', emphasizing that this tool provides more comprehensive documentation.
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?
Provides explicit guidance: 'Call this BEFORE using an unfamiliar tool' and how to use with or without the name parameter. It contrasts with alternatives by implying that other tools lack full documentation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![yandex-direct-mcp MCP server](https://glama.ai/mcp/servers/nikolaymokh-dev/yandex-direct-mcp/badges/card.svg)](https://glama.ai/mcp/servers/nikolaymokh-dev/yandex-direct-mcp)

Score Badge

Copy to your README.md:

[![yandex-direct-mcp MCP server](https://glama.ai/mcp/servers/nikolaymokh-dev/yandex-direct-mcp/badges/score.svg)](https://glama.ai/mcp/servers/nikolaymokh-dev/yandex-direct-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nikolaymokh-dev/yandex-direct-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server