DataForSEO MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
The tool set has significant overlap and ambiguity, particularly within the backlinks and keywords categories. For example, backlinks_bulk_new_lost_backlinks and backlinks_bulk_new_lost_referring_domains have very similar purposes, and tools like backlinks_domain_intersection and backlinks_page_intersection are nearly identical in description. This makes it difficult for an agent to reliably choose the correct tool without deep domain knowledge.
Naming Consistency4/5
Tool names follow a consistent snake_case pattern with a clear prefix structure (e.g., backlinks_, keywords_data_, on_page_, serp_). However, there are minor deviations such as serp_locations and serp_youtube_locations not following the same verb_noun style as others, and some names are overly long and repetitive (e.g., backlinks_bulk_new_lost_referring_domains). Overall, the naming is predictable but could be more streamlined.
Tool Count2/5
With 36 tools, the count is excessive for a single server, leading to cognitive overload and potential confusion. The tools cover multiple domains (backlinks, keywords, on-page, SERP, YouTube), suggesting the server is overly broad. A more focused approach with fewer, more distinct tools would improve usability and coherence.
Completeness4/5
The server provides comprehensive coverage across SEO-related domains, including backlinks, keywords, on-page analysis, and SERP data. There are no obvious major gaps; for example, it includes both bulk and individual operations, time-series data, and utility tools. However, the sheer number of tools may obscure completeness, and some areas like keyword tracking could benefit from more streamlined integration.
Average 3/5 across 36 of 36 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only mentions the tool's basis on Lighthouse without describing key behaviors: what the tool outputs (e.g., performance scores, audit results), whether it performs network requests, any rate limits, authentication needs, or side effects. This leaves the agent guessing about the tool's operation and results.
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 a single sentence that is concise but under-specified—it doesn't front-load critical information about the tool's function. While it avoids waste, it lacks structure that could clarify purpose or usage, making it less helpful than a more informative yet still brief description would be.
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 complexity of a Lighthouse-based tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It fails to explain what the tool returns, how it behaves, or when to use it, leaving significant gaps for an AI agent to understand and invoke the tool correctly in context with its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters (e.g., 'url' for the page to parse, 'enable_javascript' for rendering). The description adds no additional meaning or context about parameters beyond what the schema provides, such as usage examples or constraints. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is 'based on Google's open-source Lighthouse project for measuring the quality of web pages and web apps,' which provides some context but is vague about the specific action. It doesn't clearly state what the tool actually does (e.g., run a Lighthouse audit, fetch metrics, generate reports) or distinguish it from sibling tools like 'on_page_content_parsing' or 'on_page_instant_pages.' This is closer to a tautology of the name 'on_page_lighthouse' without specifying the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or comparisons with sibling tools (e.g., 'on_page_content_parsing' or 'on_page_instant_pages'), leaving the agent with no information on selection criteria. This is a significant gap in usage instructions.
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 full burden but offers minimal behavioral insight. It implies a read operation ('provides data'), but doesn't disclose critical traits like whether it's live/real-time (suggested by 'live_advanced' in the name), rate limits, authentication needs, or what 'advanced' entails. The description adds little beyond the basic action.
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 a single, vague sentence that under-specifies rather than being concise. While it's brief, it fails to front-load useful information—every word should earn its place, but this adds minimal value. It's not verbose, but it's inefficient due to lack of substance.
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 tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what data is returned, how 'live_advanced' affects behavior, or differentiate from siblings. Given the complexity and lack of structured context, the description should do more to guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters (e.g., device, language_code, video_id). The description adds no parameter-specific meaning beyond implying 'video you specify' relates to 'video_id', which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'provides data on the video you specify' is vague and tautological—it essentially restates the tool name 'serp_youtube_video_info_live_advanced' without specifying what kind of data (e.g., metadata, analytics, SERP rankings) or how it differs from sibling tools like 'serp_youtube_organic_live_advanced' or 'serp_youtube_video_comments_live_advanced'. It lacks a clear verb-resource distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given multiple sibling tools in the SERP/YouTube category (e.g., 'serp_youtube_organic_live_advanced', 'serp_youtube_video_comments_live_advanced'), the description fails to indicate context, prerequisites, or exclusions, leaving the agent to guess based on names alone.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to do so. It does not indicate whether this is a read-only operation, if it requires authentication, has rate limits, or what kind of data is returned (e.g., raw subtitles, analysis, metadata). The vague phrase 'provides data' offers no insight into the tool's behavior or constraints.
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—a single sentence with no wasted words. It is front-loaded and to the point, though this brevity contributes to its lack of detail. Every word serves the core message, even if that message is insufficient.
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 complexity (7 parameters, no annotations, no output schema), the description is incomplete. It fails to explain what data is returned, how subtitles are processed, or any behavioral aspects. While the schema covers parameters, the overall context for using this tool—especially alongside siblings—is lacking, making it inadequate for informed agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the input schema itself. The description adds no additional meaning about parameters beyond what the schema provides (e.g., it doesn't explain how 'video_id' relates to YouTube URLs or clarify the purpose of 'subtitles_translate_language'). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'provides data on the video subtitles you specify' is tautological—it essentially restates the tool name 'serp_youtube_video_subtitles_live_advanced' without adding specificity. It lacks a clear verb (e.g., 'fetch', 'retrieve', 'analyze') and does not distinguish this tool from siblings like 'serp_youtube_video_comments_live_advanced' or 'serp_youtube_video_info_live_advanced', which also provide YouTube video data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 does not mention any prerequisites, context for usage, or comparisons to sibling tools (e.g., when to choose subtitles data over comments or general video info). This leaves the agent without direction for tool selection.
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 the full burden of behavioral disclosure. It mentions that filters are 'associated with a certain object,' hinting at structure, but fails to describe key traits like whether this is a read-only operation, what the output format might be, or any constraints (e.g., rate limits or authentication needs). For a tool with no annotations, this leaves significant gaps in understanding its 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 two sentences and avoids unnecessary fluff, but it's not optimally front-loaded—the first sentence is somewhat generic, and the second adds a useful but buried detail. It could be more efficient by combining or reordering information to highlight the tool's action upfront, though it's not overly 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?
Given the complexity of backlinks tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of filter options or documentation), how to interpret results, or how it integrates with sibling tools. For a tool in a rich API context, this leaves the agent with insufficient information to use it effectively.
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 1 parameter with 100% description coverage ('The name of the tool to get filters for'), so the schema already documents it well. The description doesn't add any meaning beyond this, such as examples or usage context for the parameter. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides 'information about filters that can be used with DataForSEO Backlinks API endpoints,' which clarifies the general domain but is vague about the specific action. It doesn't specify what the tool actually does (e.g., list, retrieve, or describe filters) or how it differs from sibling tools like 'backlinks_backlinks' or 'backlinks_summary,' making it tautological in that it restates the name's implication without adding clarity.
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 includes a note about filters being 'associated with a certain object in the result array,' which implies some context for usage, but it doesn't explicitly state when to use this tool versus alternatives (e.g., other backlinks tools or API endpoints). No guidance on prerequisites, exclusions, or specific scenarios is provided, leaving the agent with minimal direction.
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 of behavioral disclosure. It mentions the tool provides a 'detailed overview' but fails to specify output format, pagination behavior, rate limits, authentication needs, or potential side effects. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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, clear sentence that efficiently states the tool's function without unnecessary details. It's front-loaded and avoids redundancy, though it could be slightly more informative to improve utility without sacrificing brevity.
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 complexity of 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral traits, output structure, or usage context, making it inadequate for an agent to fully understand how to invoke and interpret results from this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description adds no additional meaning or context about parameters beyond what the schema provides, such as explaining the 'target' field's relationship to referring networks. Thus, it meets the baseline for high schema coverage without compensating with extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides 'a detailed overview of referring domains pointing to the target you specify,' which clarifies it retrieves referring domain data for a target. However, it's vague about what 'referring domains' means in this context (e.g., networks vs. domains), and it doesn't distinguish this from sibling tools like 'backlinks_referring_domains,' leaving ambiguity in purpose.
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 offers no guidance on when to use this tool versus alternatives, such as 'backlinks_referring_domains' or other backlinks-related siblings. It lacks context on specific use cases, prerequisites, or exclusions, providing only a basic functional statement without comparative or situational 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 carries the full burden of behavioral disclosure. It mentions 'provides data' which suggests a read-only operation, but fails to describe critical behaviors such as whether this is a live/real-time query, rate limits, authentication needs, data freshness, or what the output format looks like (especially important since there's no output schema). The description is too minimal to adequately inform the agent about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words, making it appropriately concise. However, it lacks front-loading of critical information (e.g., not specifying it's for YouTube video comments retrieval), which slightly reduces its effectiveness despite the brevity.
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 complexity (6 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what data is returned, how results are structured, or behavioral aspects like live data access. For a tool with 'advanced' in its name and multiple configuration parameters, the minimal description leaves significant gaps in understanding its full context and usage.
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% description coverage, providing clear details for all 6 parameters (e.g., 'depth' as parsing depth with max value, 'location_name' with format examples). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting, but doesn't compensate or enhance understanding further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'provides data on the video comments you specify', which indicates a data retrieval function but is vague about what specific data is provided (e.g., comment text, metrics, sentiment). It distinguishes from obvious siblings like 'serp_youtube_video_info_live_advanced' by focusing on comments rather than general video info, but lacks specificity about the verb (e.g., 'fetch', 'analyze') and scope (e.g., 'live', 'advanced' aspects).
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 offers no guidance on when to use this tool versus alternatives. There are no explicit mentions of when to use it, when not to use it, or references to sibling tools (e.g., 'serp_youtube_video_info_live_advanced' for general video data). Usage is implied only by the tool name and description, leaving the agent to infer context without clear direction.
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 for behavioral disclosure. While it mentions the tool 'will provide' data (implying a read operation), it doesn't address important behavioral aspects: whether this is a live query or cached data, rate limits, authentication requirements, pagination behavior (beyond what's in the schema), error conditions, or what 'detailed overview' specifically includes. For a data retrieval tool with complex filtering capabilities, this leaves significant gaps.
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, reasonably concise sentence that gets straight to the point. It front-loads the core purpose without unnecessary preamble. However, it could be slightly more structured by separating the 'what' from the 'why' - for example, explicitly stating this is for analyzing anchor text distribution in backlink profiles.
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 complexity (5 parameters with rich filtering capabilities), absence of annotations, and lack of output schema, the description is insufficiently complete. It doesn't explain what data fields are returned in the 'detailed overview', how the anchor data is structured, whether results include metrics like anchor frequency or distribution, or provide any examples of typical use cases. For a specialized SEO tool with many sibling alternatives, users need more context to understand what they're getting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema - it doesn't explain how 'target' relates to 'anchors', what 'detailed overview' means in terms of output fields, or provide examples of typical filter combinations for anchor analysis. The baseline of 3 is appropriate when the schema does the heavy lifting.
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's purpose: 'provide you with a detailed overview of anchors used when linking to the specified website with relevant backlink data for each of them'. It specifies the verb ('provide'), resource ('anchors'), and scope ('linking to the specified website'), making it clear this tool retrieves anchor text data for backlinks. However, it doesn't explicitly differentiate from sibling tools like 'backlinks_backlinks' or 'backlinks_summary', which likely provide different backlink data aspects.
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 offers no guidance on when to use this tool versus alternatives. With 24 sibling tools in the backlinks category, there's no mention of what distinguishes this anchor-focused tool from others like 'backlinks_backlinks' (likely general backlink data) or 'backlinks_summary' (likely aggregated metrics). The description assumes the user knows when anchor-specific data is needed without providing 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 the full burden of behavioral disclosure. It states the tool provides a list of backlinks but doesn't describe key behaviors: what 'relevant data' includes, pagination details (implied by limit/offset but not explained), rate limits, authentication needs, or error handling. For a data-fetching tool with no annotations, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently states the tool's purpose without unnecessary words. It's front-loaded with the core functionality and appropriately sized for its informational value, making it easy to parse quickly.
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 complexity (6 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'relevant data' entails, how results are structured, or any behavioral traits like rate limits. For a tool that likely returns detailed backlink information, more context is needed to understand its full scope and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond the schema—it doesn't explain parameter interactions, default behaviors, or examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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's purpose: 'provide you with a list of backlinks and relevant data for the specified domain, subdomain, or webpage.' It specifies the verb ('provide'), resource ('backlinks and relevant data'), and target ('domain, subdomain, or webpage'). However, it doesn't explicitly differentiate from sibling tools like 'backlinks_summary' or 'backlinks_referring_domains,' which likely serve 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. With many sibling tools (e.g., 'backlinks_summary,' 'backlinks_referring_domains'), there's no indication of how this tool differs in context or when it's preferred. It mentions the target but lacks any usage context, prerequisites, or exclusions.
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 the full burden. It mentions the tool provides 'number of referring domains' but doesn't disclose key behavioral traits: whether this is a read-only operation, if it requires authentication, rate limits, pagination, or what the output format looks like. The note about domain targeting adds some context but doesn't compensate for the lack of basic operational transparency.
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 appropriately sized with two sentences. The first sentence states the core purpose, and the second adds a clarifying note about domain targeting. There's no wasted text, and it's front-loaded with the main functionality.
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 complexity (bulk analysis tool with no annotations and no output schema), the description is incomplete. It doesn't explain what 'new/lost' means in the tool name, how results are structured, or any prerequisites. For a tool that likely returns data on referring domain changes over time, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters ('date_from' and 'targets') with detailed descriptions. The description adds minimal value beyond the schema: it mentions 'targets array' but doesn't explain parameter semantics further. Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose: 'provide you with the number of referring domains pointing to the domains, subdomains and pages specified in the targets array.' It specifies the verb ('provide'), resource ('number of referring domains'), and scope ('targets array'). However, it doesn't explicitly differentiate from sibling tools like 'backlinks_bulk_referring_domains' or 'backlinks_referring_domains', which appear to offer similar functionality.
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. With multiple sibling tools related to backlinks and referring domains (e.g., 'backlinks_bulk_referring_domains', 'backlinks_referring_domains'), there's no indication of what distinguishes this tool's 'new/lost' focus or bulk capabilities from others. The note about domain vs. subdomain results is operational, not usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions providing a 'detailed overview' but doesn't specify what that includes (e.g., pagination, rate limits, authentication needs, data freshness, or error handling). For a tool with 5 parameters and no output schema, this lack of detail is a significant gap, making it inadequate for informed use.
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, clear sentence that efficiently states the tool's purpose without unnecessary words. It's front-loaded and easy to parse, though it could be slightly more structured (e.g., by including key usage notes). Overall, it's concise and well-formed, earning a high score.
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 complexity (5 parameters, no annotations, no output schema, and many sibling tools), the description is incomplete. It lacks behavioral details, usage guidelines, and output information, which are crucial for an agent to use the tool effectively. The high schema coverage helps, but the description doesn't fill the gaps in context, making it insufficient for a tool of this nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the input schema already documents all parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain how 'target' relates to 'filters' or typical use cases). With high schema coverage, the baseline is 3, as the description doesn't compensate or add value beyond the structured data.
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's purpose: 'provide you with a detailed overview of domain pages with backlink data for each page.' It specifies the resource (domain pages) and the data (backlink data), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'backlinks_domain_pages_summary' or 'backlinks_backlinks,' which might offer similar data, so it doesn't reach a 5.
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. With many sibling tools (e.g., 'backlinks_domain_pages_summary,' 'backlinks_backlinks'), there's no indication of context, prerequisites, or exclusions. This leaves the agent guessing about the appropriate use case, resulting in a low score.
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 the full burden of behavioral disclosure. It mentions providing a 'detailed overview' but doesn't specify what that includes (e.g., domain metrics, link counts, timestamps), whether results are paginated (implied by limit/offset but not stated), or any rate limits/authentication requirements. For a data retrieval tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose. There's no wasted verbiage, and it's appropriately front-loaded with the core functionality. However, it could be slightly more structured by explicitly mentioning key capabilities like filtering or pagination.
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 tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the 'detailed overview' includes (output format), how results are structured, or any behavioral constraints. Given the complexity implied by the filtering/sorting parameters and lack of structured metadata, the description should provide more context about the tool's operation and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description doesn't add any meaningful parameter semantics beyond what's in the schema—it mentions 'target you specify' which is covered by the schema's target parameter description. Baseline 3 is appropriate when the schema does all the parameter documentation work.
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's purpose: 'provide you with a detailed overview of referring domains pointing to the target you specify.' It includes a specific verb ('provide') and resource ('referring domains'), but doesn't explicitly differentiate from sibling tools like 'backlinks_referring_networks' or 'backlinks_summary' which might offer similar data.
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 provided on when to use this tool versus alternatives. With many sibling tools in the 'backlinks_' category (e.g., 'backlinks_backlinks', 'backlinks_summary'), the description lacks any context about what makes this tool unique or when it should be preferred over others for analyzing referring domains.
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 the full burden of behavioral disclosure. It mentions the tool 'will provide you with an overview' but lacks details on output format (e.g., structured data, summary metrics), pagination, rate limits, authentication needs, or error handling. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does ('provide an overview of backlinks data') and the target ('domain, subdomain, or webpage'), with zero waste or redundancy.
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 complexity of backlinks analysis and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'overview' entails (e.g., summary statistics, aggregated data), potential limitations, or how it differs from detailed sibling tools. For a tool in a crowded namespace with no structured output guidance, more context is needed.
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% description coverage, thoroughly documenting all three parameters. The description adds no parameter-specific information beyond what's in the schema, such as examples or usage tips. According to the rules, with high schema coverage (>80%), the baseline is 3 even without param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'provide you with an overview of backlinks data available for a given domain, subdomain, or webpage.' It specifies the verb ('provide') and resource ('backlinks data'), and distinguishes it from siblings by focusing on an 'overview' rather than detailed data like 'backlinks_backlinks' or 'backlinks_anchors.' However, it doesn't explicitly differentiate from all siblings (e.g., 'backlinks_domain_pages_summary'), so it's not a perfect 5.
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 offers no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., 'backlinks_backlinks' for detailed backlinks, 'backlinks_summary' for overview), it fails to specify scenarios where an overview is preferable, prerequisites, or exclusions. This leaves the agent without context for tool selection.
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 the full burden of behavioral disclosure. It states what the tool does but lacks critical behavioral details: it doesn't mention rate limits, authentication requirements, whether it's a read-only or mutating operation, error handling, or response format. For a tool with 6 parameters and no output schema, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly states the tool's purpose without unnecessary words. It's appropriately sized for a tool with a specific function, though it could be slightly more structured by front-loading key information more explicitly.
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 complexity (6 parameters, no output schema, no annotations), the description is incomplete. It doesn't cover behavioral aspects like rate limits or auth needs, doesn't explain the return format, and offers no usage guidelines. For a data-fetching tool with multiple parameters, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain how 'keywords' relate to 'demographic breakdown' or provide usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose: 'provide you with the demographic breakdown (by age and gender) of keyword popularity per each specified term based on DataForSEO Trends data.' It specifies the verb ('provide'), resource ('demographic breakdown'), and data source ('DataForSEO Trends'), but doesn't explicitly differentiate from sibling tools like 'keywords_data_dataforseo_trends_explore' or 'keywords_data_dataforseo_trends_subregion_interests'.
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 doesn't mention sibling tools or contexts where demographic data is preferred over other keyword trend analyses, leaving the agent to infer usage based on the tool name alone.
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 of behavioral disclosure. While it mentions what data is provided (keyword popularity from specific sources), it doesn't describe rate limits, authentication requirements, error conditions, response format, or whether this is a read-only operation. For a data retrieval tool with no annotation coverage, this leaves significant behavioral gaps.
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 efficiently structured in two sentences that directly state the tool's core functionality and data sources. There's no unnecessary verbiage or repetition. However, it could be slightly more front-loaded by immediately mentioning the keyword focus rather than starting with 'This endpoint will provide you with...'
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 tool with 6 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the output looks like, how results are structured, or any limitations beyond what's implied. The agent must rely entirely on the input schema for operational details, leaving gaps in understanding the tool's full behavior and results.
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 description adds no parameter-specific information beyond what's already in the schema (which has 100% coverage). It doesn't explain relationships between parameters like 'time_range' and 'date_from/date_to', or provide examples of keyword usage. With complete schema documentation, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
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's purpose: 'provide you with the keyword popularity data from DataForSEO Trends' and specifies the data sources (Google Search, Google News, Google Shopping). It distinguishes itself from sibling tools like 'keywords_data_google_trends_explore' by mentioning DataForSEO specifically, but doesn't explicitly contrast with other keyword-related siblings like 'keywords_data_dataforseo_trends_demography'.
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 doesn't mention any prerequisites, constraints, or compare it to sibling tools like 'keywords_data_google_trends_explore' or 'keywords_data_dataforseo_trends_demography'. The agent must infer usage from the tool name and description alone.
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 of behavioral disclosure. It mentions the data source ('DataForSEO Trends') but lacks critical details: it doesn't specify if this is a read-only operation, potential rate limits, authentication requirements, or what the output format looks like (e.g., JSON structure, error handling). For a data query tool with multiple parameters, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose and avoids redundancy, making it easy to parse quickly.
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 complexity (6 parameters, no annotations, no output schema), the description is inadequate. It doesn't cover behavioral aspects like data freshness, limitations (e.g., maximum keywords per query implied by schema but not highlighted), or example use cases. For a data retrieval tool with rich parameters, more context is needed to guide effective usage.
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 description adds no parameter-specific information beyond what's already in the input schema, which has 100% coverage. It doesn't explain how parameters interact (e.g., that 'time_range' is ignored if date parameters are set) or provide examples of keyword usage. Since the schema is fully documented, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'provide you with location-specific keyword popularity data from DataForSEO Trends.' It specifies the verb ('provide'), resource ('keyword popularity data'), and scope ('location-specific'), though it doesn't explicitly differentiate from sibling tools like 'keywords_data_dataforseo_trends_demography' or 'keywords_data_dataforseo_trends_explore'.
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 offers no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or provide context for choosing this specific keyword data endpoint over others in the server, such as 'keywords_data_google_ads_search_volume' or 'keywords_data_google_trends_explore'.
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 full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about rate limits, authentication needs, error handling, or what the output looks like (since there's no output schema). For a data retrieval tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a straightforward data retrieval tool and front-loads the core purpose immediately.
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 complexity (data retrieval from an external API), lack of annotations, and absence of an output schema, the description is insufficiently complete. It doesn't explain what search volume data includes (metrics, format), how results are returned, or any limitations. For a tool interacting with Google Ads API, more context about response structure and constraints would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema (keywords array, optional language_code and location_name). This meets the baseline of 3 when schema coverage is high, but doesn't provide additional semantic 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?
The description clearly states the action ('Get search volume data') and resource ('for keywords from Google Ads'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'keywords_data_dataforseo_trends_explore' or 'keywords_data_google_trends_explore' that might also handle keyword data, so it doesn't fully distinguish from alternatives.
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 doesn't mention prerequisites, context, or exclusions, leaving the agent with no usage instructions beyond the basic purpose. This is a significant gap given multiple sibling tools in the keywords_data category.
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 of behavioral disclosure. It mentions the tool provides 'keyword popularity data' but doesn't describe what the output looks like (e.g., time-series data, graphs, lists), any rate limits, authentication requirements, or potential side effects. The description lacks critical behavioral context needed for an AI agent to use it effectively.
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—just two sentences that directly state the tool's purpose and scope. Every word earns its place, with no redundant information or fluff. It's front-loaded with the core functionality, making it easy for an agent to quickly understand what the tool does.
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 complexity (9 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain the output format, which is critical for a data-fetching tool, nor does it cover behavioral aspects like error handling or data freshness. The description is too brief to provide the necessary context for an AI agent to use the tool confidently.
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 description adds no parameter-specific information beyond what's already in the schema, which has 100% coverage. It mentions 'keyword trends for Google Search, Google News, Google Images, Google Shopping, and YouTube,' which loosely relates to the 'type' parameter but doesn't provide additional semantics. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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's purpose: 'provide you with the keyword popularity data from the ‘Explore’ feature of Google Trends.' It specifies the verb ('provide') and resource ('keyword popularity data'), and mentions the supported platforms (Google Search, News, Images, Shopping, YouTube). However, it doesn't explicitly differentiate from its sibling 'keywords_data_dataforseo_trends_explore' or other keyword-related tools, which prevents a perfect score.
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 mentions the 'Explore' feature but doesn't explain how it differs from other keyword tools in the list (e.g., 'keywords_data_google_ads_search_volume' or 'keywords_data_dataforseo_trends_explore'). There are no explicit when-to-use or when-not-to-use instructions, leaving the agent to infer usage 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 the full burden of behavioral disclosure. It states the tool returns structured content, but doesn't cover critical aspects like rate limits, authentication needs, error handling, or performance implications (e.g., timeouts for JavaScript-heavy pages). The mention of 'parsing' implies a read-only operation, but this isn't explicitly confirmed, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality. It avoids unnecessary words and directly states what the tool does. However, it could be slightly more structured by separating the action from the output details for clarity.
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 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format (e.g., structure of parsed content), error cases, or dependencies like network access. For a parsing tool with multiple configuration options, this leaves significant gaps for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain how 'custom_js' interacts with 'enable_javascript'). This meets the baseline for high schema coverage, but no extra value is provided.
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's purpose: parsing page content and returning structured data including links, anchors, headings, and text. It specifies the verb ('parsing') and resource ('content on any page'), making the function understandable. However, it doesn't explicitly differentiate from sibling tools like 'on_page_instant_pages' or 'on_page_lighthouse', which might have overlapping or related functionality.
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 mentions parsing 'any page' but doesn't specify contexts, prerequisites, or exclusions. Given the sibling tools include other on_page tools, this lack of differentiation leaves the agent without clear usage instructions.
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 of behavioral disclosure. It mentions that the tool returns 'page-specific data' about SEO optimization, but fails to describe critical behaviors: what the output format looks like, whether it's a read-only operation, potential rate limits, authentication needs, or error handling. The description is too high-level to guide an agent effectively.
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, clear sentence that efficiently states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core function. However, it could be slightly more structured by explicitly separating purpose from 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 complexity of a 5-parameter tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return format, error conditions, or how parameters interact with the SEO analysis. For a tool that likely returns structured data about page optimization, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema—it doesn't explain how parameters like 'custom_js' or 'enable_javascript' affect the SEO analysis. This meets the baseline of 3 when schema coverage is complete.
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's purpose: 'get page-specific data with detailed information on how well a particular page is optimized for organic search'. It specifies the verb ('get') and resource ('page-specific data'), and distinguishes it from sibling tools like 'on_page_content_parsing' or 'on_page_lighthouse' by focusing on SEO optimization assessment. However, it doesn't explicitly differentiate from all siblings, so it's not a perfect 5.
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 doesn't mention sibling tools like 'on_page_content_parsing' or 'on_page_lighthouse' that might serve similar purposes, nor does it specify prerequisites or exclusions. The only implied usage is for analyzing page SEO, but this is too vague for effective tool selection.
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 carries full burden but only states what the tool does without behavioral details. It doesn't disclose if this is a read-only operation, potential rate limits, authentication needs, or what happens with invalid inputs. This leaves significant gaps in understanding the tool's behavior beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It avoids redundancy but could be slightly more structured by hinting at key parameters like depth or device, though not required given schema coverage.
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 tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error handling, or behavioral constraints, leaving the agent with incomplete context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description adds no additional parameter semantics beyond implying keyword and search engine usage, which is already covered. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 verb 'Get' and resource 'organic search results', specifying the action and target. It mentions 'keyword' and 'search engine' to define scope, but doesn't differentiate from sibling tools like 'serp_youtube_organic_live_advanced' which targets YouTube specifically versus general search engines.
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 is provided. The description lacks context on prerequisites, such as when to choose this over other SERP or keyword tools, and doesn't mention any exclusions or complementary 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool provides 'top 20 blocks' but doesn't explain what constitutes a 'block' (e.g., video results, playlists, channels), whether results are live/real-time, pagination behavior, rate limits, or authentication needs. For a tool with no annotations and complex functionality, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It wastes no words and is appropriately sized for the tool's complexity, making it easy for an agent to parse quickly.
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 complexity (6 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the output format (what 'blocks' include), behavioral traits like rate limits or data freshness, or how it differs from siblings. Without annotations or output schema, the description should provide more context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description doesn't add any parameter semantics beyond what's in the schema (e.g., it doesn't clarify 'blocks' or provide examples). With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
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's purpose: 'provides top 20 blocks of youtube search engine results for a keyword.' It specifies the verb ('provides'), resource ('youtube search engine results'), and scope ('top 20 blocks'). However, it doesn't explicitly differentiate from sibling tools like 'serp_organic_live_advanced' or 'serp_youtube_video_info_live_advanced', which would be needed for a score of 5.
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 doesn't mention sibling tools or contexts where this specific YouTube SERP tool is preferred over general SERP tools or other YouTube-related tools. The absence of usage guidelines leaves the agent without direction for tool selection.
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 full burden for behavioral disclosure. It explains the output metric (spam score scale) but lacks critical details: it doesn't mention rate limits, authentication requirements, whether this is a read-only operation, response format, pagination, or error handling. For a bulk processing tool with up to 1000 targets, these omissions are significant.
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 efficiently structured in two sentences: the first states the core functionality, the second explains the proprietary metric. There's no redundant information, though it could be slightly more front-loaded with key behavioral details. Every sentence contributes meaning without waste.
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 bulk processing tool with no annotations and no output schema, the description is incomplete. It explains what spam scores are but doesn't cover response format, error cases, performance characteristics, or integration context. Given the complexity of processing up to 1000 targets and the lack of structured output documentation, more behavioral and operational details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing comprehensive details about the 'targets' parameter (format, examples, limits). The description adds minimal value beyond the schema, only mentioning 'targets array' without additional context about target selection strategies or spam score interpretation. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('provide you with spam scores'), the resource ('domains, subdomains, and pages'), and the proprietary metric ('Spam Score on a scale from 0 to 100'). It distinguishes itself from sibling tools like 'backlinks_bulk_ranks' or 'backlinks_bulk_backlinks' by focusing exclusively on spam scoring rather than ranking or link analysis.
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. While it mentions the 'targets array' for input, it doesn't specify use cases (e.g., SEO audit, competitor analysis) or differentiate from other bulk tools like 'backlinks_bulk_pages_summary' or 'backlinks_bulk_referring_domains'. There's no mention of prerequisites, limitations, or typical scenarios for application.
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 of behavioral disclosure. It mentions the tool provides 'detailed summary data' and handles both domains and single pages, but it lacks critical behavioral details such as rate limits, authentication requirements, pagination behavior (beyond the 'limit' and 'offset' parameters in the schema), error handling, or data freshness. For a tool with 5 parameters and no output schema, this leaves significant gaps in understanding how it operates.
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 and front-loaded, consisting of two sentences that directly state the tool's purpose and scope. There's no unnecessary repetition or fluff, and it efficiently communicates the core functionality. However, it could be slightly improved by integrating key behavioral hints, but as-is, it's well-structured and to the point.
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 complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'detailed summary data' includes, how results are structured, or any behavioral traits like performance or limitations. For a data retrieval tool with multiple filtering and sorting options, users need more context to use it effectively, making this description inadequate for the tool's sophistication.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the input schema itself. The description adds minimal value beyond the schema, only implying the 'target' parameter's role without detailing the semantics of 'filters', 'limit', 'offset', or 'order_by'. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
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's purpose: 'provide you with detailed summary data on all backlinks and related metrics for each page of the target domain or subdomain you specify.' It specifies the verb ('provide'), resource ('backlinks and related metrics'), and scope ('each page of the target domain or subdomain'). However, it doesn't explicitly differentiate from sibling tools like 'backlinks_summary' or 'backlinks_domain_pages', which appear similar, keeping it from a perfect score.
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 by specifying it works for domains/subdomains or single pages, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'backlinks_summary' or 'backlinks_domain_pages' from the sibling list. There's no mention of prerequisites, exclusions, or comparative contexts, leaving usage somewhat inferred rather than clearly defined.
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 mentions the tool provides a 'list of domains' and hints at a 'Link Gap' use case, but doesn't disclose critical behavioral traits: whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior (beyond offset/limit parameters), or what format the returned data takes. The description adds minimal behavioral context beyond the basic purpose.
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 appropriately concise with two sentences. The first sentence states the core purpose, and the second provides a specific use case. Both sentences earn their place by adding value. However, the structure could be slightly improved by front-loading more operational details about the tool's behavior.
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 complexity (5 parameters, no output schema, no annotations, and many similar sibling tools), the description is insufficiently complete. It doesn't explain what the output looks like, how results are structured, or how this tool differs from other backlinks tools. For a tool with this level of complexity and no structured output documentation, the description should provide more complete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already thoroughly documents all 5 parameters. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain how 'targets' relates to the output, or provide additional context about filter usage. With complete schema coverage, the baseline is 3 even without parameter info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'provide you with the list of domains pointing to the specified websites.' This is a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its many sibling tools (like backlinks_domain_intersection or backlinks_referring_domains), which likely have overlapping functionality in the backlinks domain.
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 some usage context: 'especially useful for creating a Link Gap feature that shows what domains link to your competitors but do not link out to your website.' This implies a competitive analysis use case but doesn't explicitly state when to use this tool versus alternatives among the many backlinks siblings, nor does it mention any prerequisites or exclusions.
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 the full burden of behavioral disclosure. It states the tool provides a list, implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or response format. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy for an agent to parse quickly.
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 no annotations, no output schema, and 0 parameters, the description is minimal. It states what the tool does but lacks context on behavior, usage, or output details. For a tool in a server with many siblings, this incomplete description may hinder effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description doesn't add param details, which is appropriate, earning a baseline score of 4 as it doesn't need to compensate for any schema gaps.
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's purpose: 'provide you list of Google Trends Categories.' It specifies the verb ('provide') and resource ('list of Google Trends Categories'), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'keywords_data_google_trends_explore,' which might also relate to Google Trends data, so it misses full sibling distinction.
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 offers no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, such as how it differs from other keywords_data tools on the server. This lack of usage instructions leaves the agent without direction for tool selection.
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 the full burden of behavioral disclosure. It states the tool 'gets' a list, implying a read-only operation, but doesn't clarify if it's a search, filter, or lookup, nor does it mention rate limits, authentication needs, or output format. For a tool with no annotations, this minimal description lacks critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose and relationship to a sibling tool. It's front-loaded with key information and has no wasted words, though minor spelling errors ('availible') slightly detract from polish.
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 no annotations, no output schema, and 4 parameters, the description is incomplete. It doesn't explain what 'availible locations' means in practice, how results are returned, or any limitations. For a utility tool with moderate complexity, this leaves significant gaps in understanding its full context and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema, such as how parameters interact or examples of usage. This meets the baseline of 3, as the schema does the heavy lifting, but the description doesn't enhance understanding.
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's purpose as a 'utility tool for serp_organic_live_advanced to get list of availible locations.' It specifies the verb ('get') and resource ('list of availible locations'), and identifies its relationship to a specific sibling tool. However, it doesn't fully distinguish from other location-related tools like 'serp_youtube_locations' in the sibling list, keeping it from a perfect score.
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 context by mentioning 'for serp_organic_live_advanced,' suggesting it's a helper tool for that sibling. However, it doesn't explicitly state when to use this tool versus alternatives like 'serp_youtube_locations' or standalone location searches, nor does it provide any exclusions or prerequisites. This leaves some ambiguity in usage scenarios.
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 full burden but offers minimal behavioral disclosure. It doesn't describe what the tool returns (list format, structure), whether it's cached/real-time data, rate limits, authentication needs, or error conditions. The description only states it's a 'utility tool' without explaining operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose and target tools without any wasted words. It's appropriately sized and front-loaded with the core functionality, making it easy for an agent to parse quickly.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what the returned location data looks like (format, structure, fields), how results are filtered/limited, or any behavioral aspects. For a utility tool that presumably returns structured location data, more context about the output is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters with their types, descriptions, and requirements. The description adds no parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as getting 'list of available locations' for specific YouTube SERP tools, which is clear but somewhat vague. It specifies the resource (locations) and target tools, but doesn't articulate the exact verb or differentiate from the sibling 'serp_locations' tool that appears to serve a similar function for non-YouTube SERP 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?
The description explicitly lists four specific sibling tools for which this location data is intended, providing clear context for when to use it. However, it doesn't mention when NOT to use it (e.g., for non-YouTube SERP tools) or explicitly name alternatives like 'serp_locations' for other SERP 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 provided, the description carries the full burden of behavioral disclosure. It mentions the tool 'will provide you with a list' but lacks details on rate limits, authentication needs, error handling, pagination (beyond offset/limit parameters), or data freshness. For a tool with 8 parameters and no output schema, this is insufficient to inform the agent about operational behavior.
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, well-structured sentence that efficiently conveys the core functionality. It avoids redundancy and is front-loaded with key information. However, it could be slightly more concise by integrating output details more seamlessly, but it remains highly efficient 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 (8 parameters, no annotations, no output schema), the description is minimally adequate. It clarifies the purpose but lacks usage guidelines, behavioral context, and output details (e.g., format of 'list of competitors'). While the schema covers inputs well, the description does not compensate for missing annotations or output schema, leaving gaps in overall understanding.
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 description adds no parameter-specific semantics beyond what the input schema provides. Since schema description coverage is 100%, the schema fully documents all 8 parameters (e.g., target, filters, limit). The description's mention of 'backlink intersections' and 'rank' relates to outputs, not inputs, so it does not enhance parameter understanding. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'provide you with a list of competitors that share some part of the backlink profile with a target website, along with a number of backlink intersections and the rank of every competing website.' It specifies the verb ('provide'), resource ('list of competitors'), and key outputs ('backlink intersections,' 'rank'), distinguishing it from sibling tools like backlinks_backlinks or backlinks_summary which focus on different backlink aspects.
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 does not mention sibling tools like backlinks_domain_intersection or backlinks_page_intersection, which might offer similar intersection analysis, nor does it specify prerequisites, exclusions, or contextual cues for selection. This leaves the agent without direction on tool choice.
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 of behavioral disclosure. It mentions the tool's purpose and a use case but lacks critical behavioral details: it doesn't specify whether this is a read-only operation, what authentication is required, rate limits, pagination behavior (beyond what's in the schema), or what the output format looks like. For a tool with 5 parameters and no output schema, this is a significant gap.
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 appropriately sized with two sentences. The first sentence states the core purpose, and the second provides valuable context about the Link Gap use case. Both sentences earn their place by adding meaningful information beyond the tool name. It could be slightly more structured but is efficient overall.
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 complexity (5 parameters, no annotations, no output schema), the description is incomplete. It explains the purpose and a use case but doesn't address critical behavioral aspects like authentication needs, rate limits, error conditions, or what the return data looks like. For a backlink analysis tool with filtering and sorting capabilities, more context about the operation's nature and output is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. It mentions 'specified websites' which aligns with the 'targets' parameter but doesn't provide additional semantic context. Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose: 'provide you with the list of domains pointing to the specified websites.' It specifies the verb ('provide') and resource ('domains pointing to websites'), and distinguishes it from siblings by mentioning its specific use case for 'Link Gap' analysis. However, it doesn't explicitly differentiate from similar-sounding siblings like 'backlinks_referring_domains' or 'backlinks_competitors'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'especially useful for creating a Link Gap feature that shows what domains link to your competitors but do not link out to your website.' This gives a specific scenario (competitive analysis) and implies usage for intersection analysis. However, it doesn't explicitly state when not to use it or name alternatives among the many sibling tools.
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 provided, the description carries the full burden of behavioral disclosure. It adds useful context about what the tool returns ('number of backlinks', 'all live backlinks', 'total number of referring links with all attributes') and clarifies domain-level results. However, it lacks details on rate limits, authentication needs, error handling, or response format, which are critical for a tool with no output schema.
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 appropriately sized with two sentences that front-load the core functionality and follow with a clarifying note. Each sentence adds value: the first defines the tool's purpose and scope, and the second explains domain-level behavior. There is no wasted text, though it could be slightly more structured for readability.
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 moderate complexity (bulk backlink counting), no annotations, and no output schema, the description is incomplete. It covers the basic purpose and some behavioral context but lacks details on output structure, pagination, error cases, or performance considerations. This leaves gaps for an agent to invoke the tool effectively without additional context.
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% description coverage, thoroughly documenting the 'targets' parameter with examples and constraints. The description adds minimal semantic value beyond the schema, only reiterating that targets include 'domains, subdomains, and pages' and clarifying domain vs. subdomain results. This meets the baseline score of 3 for high schema coverage.
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's purpose: 'provide you with the number of backlinks pointing to domains, subdomains, and pages specified in the targets array.' It specifies the verb ('provide'), resource ('number of backlinks'), and scope ('domains, subdomains, and pages'), but does not explicitly differentiate it from sibling tools like 'backlinks_backlinks' or 'backlinks_summary', which likely have overlapping functionality.
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 context by specifying that it returns 'all live backlinks... found during the latest check' and clarifies domain vs. subdomain handling. However, it does not explicitly state when to use this tool versus alternatives like 'backlinks_backlinks' or 'backlinks_bulk_referring_domains', nor does it provide exclusions or prerequisites, leaving the agent to infer based on the 'bulk' nature and target array.
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 provided, the description carries the full burden of behavioral disclosure. It describes the grouping behavior and handling of missing data ('if there is no data for a certain day/week/month/year, we will return 0'), which is valuable. However, it doesn't mention rate limits, authentication requirements, whether this is a read-only operation, or what the output format looks like (though there's no output schema). The description adds some behavioral context but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that efficiently convey the core functionality and usage context. The first sentence states the purpose and key parameters, while the second highlights the primary use case. There's no redundant information, and it's appropriately sized for a tool with well-documented parameters in the schema.
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 complexity (time-series analysis with grouping), no annotations, and no output schema, the description is moderately complete. It explains the grouping behavior and missing data handling, which is crucial. However, it doesn't cover authentication, rate limits, error conditions, or the structure of returned data (e.g., what metrics are included in the 'overview'). For a tool with no annotations or output schema, more behavioral and output details would be needed for higher completeness.
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 description mentions grouping by time range (day, week, month, year) and the purpose of building time-series graphs, which adds context beyond the input schema. However, with 100% schema description coverage, the schema already thoroughly documents all 4 parameters (date_from, date_to, group_range, target) with examples, constraints, and defaults. The description provides marginal additional meaning, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'provide you with an overview of backlink data for the target domain available during a period between the two indicated dates' and mentions grouping by time range. It specifies the resource (backlink data for a domain) and action (overview/time-series summary). However, it doesn't explicitly differentiate from sibling tools like 'backlinks_summary' or 'backlinks_timeseries_new_lost_summary', which would require a 5.
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 context by stating 'Data from this endpoint will be especially helpful for building time-series graphs of daily, weekly, monthly, and yearly link-building progress.' This suggests when to use it (for time-series visualization), but it doesn't provide explicit guidance on when to choose this tool over alternatives like 'backlinks_summary' or 'backlinks_timeseries_new_lost_summary', nor does it mention any prerequisites or exclusions.
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 results are based on 'latest check' and include all backlink types (e.g., nofollow), which adds useful context. However, it does not mention rate limits, authentication needs, or response format, leaving gaps in behavioral understanding for an AI agent.
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 appropriately sized with two paragraphs: the first states the core purpose and scope, and the second clarifies target handling. It is front-loaded with key information, though the second paragraph could be more concise. Overall, it avoids unnecessary details and earns its place.
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 no annotations and no output schema, the description provides adequate purpose and target clarification but lacks details on return values, error handling, or operational constraints. It compensates somewhat with context on backlink types and target scope, but is incomplete for a tool with complex data retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds minimal value beyond the schema, mentioning 'targets array' and 'date_from' implicitly but not providing additional semantics. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'provide you with the number of referring domains pointing to domains, subdomains, and pages specified in the targets array.' It specifies the verb ('provide'), resource ('number of referring domains'), and scope ('based on all live referring domains'), distinguishing it from siblings like 'backlinks_bulk_new_lost_referring_domains' by focusing on backlinks count rather than domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking new and lost backlinks over time, as indicated by the date_from parameter context, but does not explicitly state when to use this tool versus alternatives like 'backlinks_bulk_backlinks' or 'backlinks_summary'. It provides some context on target types (domains, subdomains, pages) but lacks explicit guidance on use cases or exclusions.
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 the full burden. It discloses key behavioral traits: the tool provides real-time data, rank scores based on referring domains, and a scoring range (0-1000). However, it does not mention rate limits, authentication needs, or potential errors (e.g., invalid targets). The description adds value but leaves gaps in operational context.
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 appropriately sized and front-loaded, starting with the core purpose. It uses three sentences efficiently: the first states the function, the second explains the scoring basis, and the third adds context with the range and comparison. There is minimal waste, though the comparison to PageRank could be considered slightly extraneous.
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 no annotations, no output schema, and a simple input schema with 100% coverage, the description is moderately complete. It covers the purpose, scoring logic, and data characteristics, but lacks details on output format, error handling, or performance considerations. For a tool with 2 parameters and no structured behavioral hints, it should do more to guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters ('targets' and 'rank_scale'). The description does not add any parameter-specific details beyond what the schema provides, such as explaining the 'targets' array further or clarifying the 'rank_scale' impact. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'provide you with rank scores of the domains, subdomains, and pages specified in the targets array.' It specifies the verb ('provide'), resource ('rank scores'), and scope ('domains, subdomains, and pages'), distinguishing it from sibling tools like 'backlinks_bulk_backlinks' or 'backlinks_bulk_spam_score' which focus on different backlink metrics.
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 by mentioning the scoring system and real-time data, but does not explicitly state when to use this tool versus alternatives like 'backlinks_summary' or 'backlinks_bulk_referring_domains'. It provides context about the rank values and comparison to Google's PageRank, but lacks clear guidance on specific use cases or exclusions.
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 provided, the description carries the full burden of behavioral disclosure. It adds useful context: it specifies that results are based on 'all live referring domains' from the 'latest check' and includes all backlink types (e.g., nofollow). However, it does not cover critical aspects like rate limits, authentication needs, error handling, or response format, leaving gaps for a tool with potential performance implications.
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 appropriately sized and front-loaded, with the core purpose stated in the first sentence. The second sentence clarifies scope and data recency, and the third explains domain vs. subdomain handling. Each sentence adds value, though the structure could be slightly more streamlined (e.g., merging the second and third points).
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 (bulk analysis with up to 1000 targets), no annotations, and no output schema, the description is moderately complete. It covers the purpose, data source, and target handling, but lacks details on output format (e.g., JSON structure), pagination, error cases, or performance considerations, which are important for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'targets' parameter fully documented in the schema (including examples, formatting rules, and limits). The description adds minimal value beyond the schema, only reiterating that targets include 'domains, subdomains, and pages.' This meets the baseline score of 3, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'provide you with the number of referring domains pointing to domains, subdomains, and pages specified in the targets array.' It specifies the verb ('provide'), resource ('number of referring domains'), and scope ('domains, subdomains, and pages'), distinguishing it from siblings like 'backlinks_backlinks' or 'backlinks_summary' by focusing on bulk referring domain counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for bulk referring domain analysis but does not explicitly state when to use this tool versus alternatives like 'backlinks_referring_domains' (likely for single targets) or 'backlinks_bulk_new_lost_referring_domains' (for tracking changes). It provides some context about target types and domain vs. subdomain handling, but lacks clear guidance on tool selection among siblings.
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 the full burden. It discloses key behavioral traits: results are grouped by time range (day/week/month/year), data is provided for a period between two dates, and it mentions handling of missing data ('if there is no data for a certain day/week/month/year, we will return 0'). However, it lacks details on rate limits, authentication needs, or potential data freshness, which are important for a data-fetching tool.
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 appropriately sized and front-loaded, with the first sentence stating the core purpose. It uses three sentences total, each adding value: defining the tool's function, explaining the time grouping, and suggesting usage for graphs. There is no redundant information, though it could be slightly more concise by integrating the grouping detail into the first sentence.
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 complexity (time-series data with grouping) and no annotations or output schema, the description is moderately complete. It covers the tool's purpose, usage context, and some behavioral aspects like data grouping and handling of missing data. However, it lacks details on output format, error handling, or performance considerations, which would be helpful for an agent to use it effectively without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, only implying the purpose of date ranges and grouping without providing additional syntax or format details. The baseline score of 3 is appropriate as the schema does the heavy lifting, but the description does not compensate with extra insights.
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: 'provide you with the number of new and lost backlinks and referring domains for the domain specified in the target field.' It specifies the exact metrics (new/lost backlinks and referring domains), the target (domain), and distinguishes it from sibling tools like 'backlinks_summary' or 'backlinks_timeseries_summary' by focusing on time-series data for new/lost metrics specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Data from this endpoint will be especially helpful for building time-series graphs of new and lost backlinks and referring domains.' It implies usage for visualization and trend analysis over time. However, it does not explicitly state when not to use it or name alternatives among siblings, such as 'backlinks_timeseries_summary' for other metrics.
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 provided, the description carries the full burden of behavioral disclosure. It describes key behavioral traits: bulk processing capability (up to 1000 targets), domain limit constraint (no more than 100 different domains), and handling of single vs. multiple targets. However, it does not cover critical aspects like rate limits, authentication requirements, error handling, or response format, leaving gaps for a tool with no annotation coverage.
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 efficiently structured in two sentences: the first states the core purpose and scope, and the second clarifies handling of single targets. Every sentence adds essential information without redundancy, making it front-loaded and appropriately sized for the tool's complexity.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose, scope, and some constraints but lacks details on behavioral aspects like response format, error conditions, or performance characteristics. Without annotations or output schema, the description should do more to compensate, but it meets a minimum viable level for a read-only summary tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds value by explaining the tool's purpose and constraints (e.g., bulk of up to 1000 targets, domain limits), which contextualizes the parameters but does not provide additional semantic details beyond the schema. Since there are only 2 parameters and schema coverage is complete, a baseline of 3 is appropriate, with an extra point for the added contextual 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?
The description clearly states the tool's purpose: 'provide you with a comprehensive overview of backlinks and related data for a bulk of up to 1000 pages, domains, or subdomains.' It specifies the verb ('provide'), resource ('backlinks and related data'), and scope ('bulk of up to 1000'), distinguishing it from sibling tools like 'backlinks_summary' (likely single target) and 'backlinks_bulk_backlinks' (likely detailed list rather than summary).
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 context by mentioning bulk processing (up to 1000 targets) and handling single pages, but does not explicitly state when to use this tool versus alternatives like 'backlinks_summary' or 'backlinks_bulk_backlinks'. It provides some operational constraints (e.g., URL format, domain limits) but lacks explicit guidance on tool selection among siblings.
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:

[![oyt-dataforseo-mcp-worker MCP server](https://glama.ai/mcp/servers/cortex8/oyt-dataforseo-mcp-worker/badges/card.svg)](https://glama.ai/mcp/servers/cortex8/oyt-dataforseo-mcp-worker)

Score Badge

Copy to your README.md:

[![oyt-dataforseo-mcp-worker MCP server](https://glama.ai/mcp/servers/cortex8/oyt-dataforseo-mcp-worker/badges/score.svg)](https://glama.ai/mcp/servers/cortex8/oyt-dataforseo-mcp-worker)

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/cortex8/oyt-dataforseo-mcp-worker'

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