Integrates with n8n workflows to perform SEO analysis using the Haloscan API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Haloscan MCP Server Get keyword overview for 'digital marketing'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for interacting with the Haloscan SEO API. This server allows easy integration with Claude for Desktop, N8N, and other MCP-compatible clients.
Exposes Haloscan SEO API functionality through MCP tools
Provides prompts for common SEO tasks
Easy integration with workflow automation tools like N8N
Related MCP server: SEO Insights MCP Server
get_user_credit
Retrieves the remaining credit for the user identified by the provided API key.
get_keywords_overview
Retrieves an overview of a specific keyword, providing key performance indicators such as search volume, competition level, and trends over time.
Inputs:
keyword (string): Requested keyword.
requested_data (string[]): Any combination of [keyword_match, related_search, related_question, similar_category, similar_serp, top_sites, similar_highlight, categories, metrics, volume_history, serp ].
It is mandatory to specify at least one of the requested data. Here is what they mean:
keyword_match: Top 10 (wrt search volume) keywords that include the provided keyword in their search query (exact match).
related_search: Top 10 (wrt search volume) keywords that appear in SERP's "Related Searches" section for the provided keyword.
related_question: Top 10 (wrt search volume) keywords that appear in SERP's "People Also Ask" (or in "Related Searches if the keyword is obviously a question) section for the provided keyword.
similar_category: Top 10 (wrt search volume) keywords that have the same "Products & Services" category tree as the provided keyword. Careful, fetching this data significantly increases response time.
similar_serp: Top 10 (wrt SERP similarity) keywords that have a similar organic SERP as the provided keyword.
top_sites: Top 10 (wrt visibility) websites that rank for the provided keyword and similar ones.
similar_highlight: Top 10 (wrt search volume) keywords for which similar terms are highlighted in SERP result pages.
categories: List of Products & Services categories the provided keyword belongs to.
metrics: List of metrics for the provided keyword. Those metrics include:
Ads metrics: volume, competition, CPC. Your usual ads data.
SEO metrics: corrected search volume, keyword match count, allintitle, KGR, KVI (Keyword Visibility Index).
volume_history: Up to 2 years of search volume history for the provided keyword.
serp: Last organic SERP for the provided keyword.
get_keywords_match
Retrieves keywords/expressions including the provided keyword as a substring.
Input:
keyword (string): Requested keyword.
get_keywords_highlights
Retrieves keywords/expressions for which similar terms are highlighted in SERP result pages.
Input:
keyword (string): Requested keyword.
get_keywords_related
Retrieves keywords/expressions that appear in SERP's "Related Searches" section for the provided keyword.
Input:
keyword (string): Requested keyword.
get_keywords_questions
Retrieves keywords/expressions that appear in SERP's "People Also Ask" (or in "Related Searches if the keyword is obviously a question) section for the provided keyword.
Input:
keyword (string): Requested keyword.
get_keywords_find
Retrieves comprehensive data for a given keyword OR list of keywords, including SEO metrics & ads metrics. This endpoint is a wrapper to call get_keywords_match, get_keywords_related, get_keywords_questions, get_keywords_highlights together.
Inputs:
keyword (string): Requested keyword.
keywords (string[]): Requested keywords. Ignored if keyword is provided.
keywords_sources (string[]): Which strategies to use to find keywords from input (Any combination of [match, serp, related, highlights, questions]).
At least one is required. Here is what they mean:
match: Keywords/expressions that include the provided keyword in their search query (exact match).
serp: Keywords/expressions that have a similar organic SERP as the provided keyword.
related: Keywords/expressions that appear in SERP's "Related Searches" section for the provided keyword.
highlights: Keywords/expressions for which similar terms are highlighted in SERP result pages.
questions: Keywords/expressions that appear in SERP's "People Also Ask" (or in "Related Searches if the keyword is obviously a question) section for the provided keyword.
get_keywords_site_structure
Clustering endpoint. You can use it either in bulk (then provide a value for keywords) or in single request (then provide a value for keyword).
Input:
keyword (string): Requested keyword. Ignored if keywords is provided. If you only provide a value for keyword (without keywords), then an equivalent of get_keywords_find will run first, to fetch keywords to group.
keywords (string[]): Requested keywords.
mode (string): Clustering mode. Either manual or multi. In manual mode, keywords are grouped based on SERP similarity. In multi mode, hierarchical groups are made, based on graph link density.
get_keywords_serp_compare
Compares a given keyword/expression's SERP at 2 different dates.
Inputs:
keyword (string): Requested keyword/expression.
period (string): The comparison period for SERPs (1 month, 3 months, 6 months, 12 months, custom).
first_date (string): Date in YYYY-MM-DD format. Ignored if period is not custom. This date must be a valid date for the given keyword/expression. Valid search dates are returned in available_search_dates item in call response, or as a response for get_keywords_serp_available_dates.
second_date (string): Date in YYYY-MM-DD format. Ignored if period is not custom. This date must be a valid date for the given keyword/expression. Valid search dates are returned in available_search_dates item in call response, or as a response for get_keywords_serp_available_dates.
get_keywords_serp_availableDates
Retrieves the available dates for historical SERP data for a given keyword.
Input:
keyword (string): Requested keyword.
get_keywords_serp_pageEvolution
Retrieves the evolution of SERP rankings of a given URL for a specific keyword over time. All parameters are mandatory.
Inputs:
keyword (string): Requested keyword/expression.
first_date (string): Date in YYYY-MM-DD format.
second_date (string): Date in YYYY-MM-DD format.
url (string): URL to track rankings for.
get_keywords_bulk
Retrieves keyword data (SEO metrics, ads metrics, etc.) for multiple keywords at once in a bulk request.
Input:
keywords (string[]): Array containing the requested keywords.
get_keywords_scrap
Ask Haloscan to scrape the search engine results pages (SERP) for a given keyword/expression. The scrap will take around 24h to be completed.
Input:
keywords (string[]): Array containing the requested keywords.
get_domains_overview
Retrieves a comprehensive SEO performance summary for a specific domain.
Inputs:
input (string): Target url, domain or root domain.
mode (string): Any of (auto, root, domain, url). How to interpret the input. Usually, you want to use root to get data about the root domain.
requested_data (string[]): At least one of (metrics, positions_breakdown, traffic_value, categories, best_keywords, best_pages, gmb_backlinks, visibility_index_history, positions_breakdown_history, positions_and_pages_history). Which data to fetch among:
metrics: SEO metrics for the given domain (VI, position count, keyword count, traffic, page count, ranks, etc.).
positions_breakdown: Search engine ranking positions for the given domain.
traffic_value: Traffic value for the given domain (may take a while to compute for large domains).
categories: Categories for the given domain (may take a while to compute for large domains).
best_keywords: Top-performing keywords for the given domain (may take a while to compute for large domains).
best_pages: Top-performing pages for the given domain (may take a while to compute for large domains).
gmb_backlinks: GMB backlinks for the given domain.
visibility_index_history: Visibility index history for the given domain.
positions_breakdown_history: Search engine ranking positions breakdown history for the given domain.
positions_and_pages_history: Search engine ranking positions and pages history for the given domain.
get_domains_positions
Retrieves the search engine ranking positions of a specified domain.
Input:
input (string): Target url, domain or root domain.
mode (string): Any of (auto, root, domain, url). How to interpret the input. Usually, you want to use root to get data about the root domain.
get_domains_top_pages
Retrieves the top-performing pages of a specified domain based on aggregated organic search metrics such as traffic, number of ranking keywords.
Input:
input (string): Target url, domain or root domain.
mode (string): Any of (auto, root, domain, url). How to interpret the input. Usually, you want to use root to get data about the root domain.
get_domains_history_positions
Retrieves historical ranking positions for a specific domain, between 2 specified dates. Very useful if you want to find lost positions.
Inputs:
input (string): Target url or domain.
mode (string): Any of (auto, root, domain, url). How to interpret the input. Usually, you want to use root to get data about the root domain.
date_from (string): Date in YYYY-MM-DD format.
date_to (string): Date in YYYY-MM-DD format.
get_domains_history_pages
Retrieves page-wise historical SEO performance data for a specified domain between 2 specified dates.
Inputs:
input (string): Target url or domain.
mode (string): Any of (auto, root, domain, url). How to interpret the input. Usually, you want to use root to get data about the root domain.
date_from (string): Date in YYYY-MM-DD format.
date_to (string): Date in YYYY-MM-DD format.
get_page_best_keywords
Retrieves the top-performing keywords for a specific URL, showing which search queries drive the most traffic and visibility to that page.
Input:
input (string[]): Target urls.
mode (string): Any of (auto, root, domain, url). How to interpret the input. Usually, you want to use root to get data about the root domain.
strategy (string): Any of (both, only_active, only_lost). Whether to return all positioned keywords, only active ones or only lost ones.
get_domains_keywords
Retrieves current positions of a given domain for a list of given keywords.
Inputs:
input (string): Target url or domain.
mode (string): Any of (auto, root, domain, url). How to interpret the input. Usually, you want to use root to get data about the root domain.
keywords (string[]): Mandatory array containing the requested keywords.
get_domains_bulk
Retrieves SEO performance metrics for multiple domains in a single request.
Input:
inputs (string[]): Array containing the requested urls or domains.
mode (string): Any of (auto, root, domain, url). How to interpret the input. Usually, you want to use root to get data about the root domains.
get_domains_competitors
Retrieves a list of organic search competitors for a given domain based on overlapping keywords (may take a while to compute for large domains).
Input:
input (string): Target url or domain.
mode (string): Any of (auto, root, domain, url). How to interpret the input. Usually, you want to use root to get data about the root domain.
get_domains_competitors_keywords_diff
Compares the keyword differences between a given domain and its competitors, highlighting keywords that one domain ranks for but the other does not (may take a while to compute for large domains).
Inputs:
input (string): Target url or domain.
mode (string): Any of (auto, root, domain, url). How to interpret the input. Usually, you want to use root to get data about the root domain.
competitors (string[]): Mandatory list of (up to 20) competitors to compare the input to.
exclusive (boolean): Whether to include positions where only the search input is positioned, and none of the requested competitors is.
missing (boolean): Whether to include positions where the search input is not positioned, and at least one of the requested competitors is.
bested (boolean): Whether to include positions where the search input is positioned, and better positioned than at least one of the requested competitors.
besting (boolean): Whether to include positions where the search input is positioned, but at least one of the requested competitors is positioned better.
get_domains_competitors_best_pages
Retrieves the best-performing pages of (specified) competitors of a given domain (may take a while to compute for large domains).
Inputs:
input (string): Target url or domain.
mode (string): Any of (auto, root, domain, url). How to interpret the input. Usually, you want to use root to get data about the root domain.
competitors (string[]): Mandatory list of (up to 20) competitors to compare the input to.
get_domains_competitors_keywords_best_positions
Retrieves the best-ranking positions for a given list of domains on a given list of keywords.
Inputs:
competitors (string[]): List of competitor domains or root domains.
keywords (string[]): Mandatory list of keywords to look for.
get_domains_visibility_trends
Retrieves the visibility trend for a specific domain over time, showing how its search engine visibility has evolved.
Input:
input (string[]): Array containing the requested urls or domains.
mode (string): Any of (auto, root, domain, url). How to interpret the input. Usually, you want to use root to get data about the root domain.
type (string): Any of (first, highest, trends, index). Should data be scaled, and how. Use index to get the raw visibility index.
get_domains_expired
Returns a list of available domains. Domains are returned without their url unless you have already revealed them (in which case root_domain is filled), and a call to domains/expired/reveal is required to reveal domains you are interested in.
Input:
keyword (string): Optional keyword on which the expired domain should have been positioned.
Sign up for an Haloscan account.
Choose a plan.
Generate your API key from Configuration API page.
Use the API key for the Haloscan server in the Claude Desktop configuration file.
Add this server to your Claude Desktop configuration file claude_desktop_config.json:
{
"mcpServers": {
"haloscan": {
"command": "npx",
"args": [
"-y",
"@occirank/haloscan-server",
"start"
],
"env": {
"HALOSCAN_API_KEY": "YOUR API KEY"
}
}
}
}MIT
Obtenir des domaines en masse.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | Yes | ||
| mode | No | ||
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| total_traffic_min | No | ||
| total_traffic_max | No | ||
| unique_keywords_min | No | ||
| unique_keywords_max | No | ||
| total_top_3_min | No | ||
| total_top_3_max | No | ||
| total_top_10_min | No | ||
| total_top_10_max | No | ||
| total_top_50_min | No | ||
| total_top_50_max | No | ||
| total_top_100_min | No | ||
| total_top_100_max | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It fails to mention any side effects, authentication needs, rate limits, or pagination behavior, leaving the agent uninformed about the tool's execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly terse—a single phrase with no structure or elaboration. While conciseness is valued, this under-specification undermines its utility for a complex tool with 17 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 parameters, no output schema, no annotations), the description is severely incomplete. It fails to cover parameter constraints, return data shape, or operational context, making it inadequate for proper agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 18%, but the description adds no parameter-level meaning. It does not explain the purpose of the many input parameters, forcing reliance on their names alone, which is insufficient for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtenir des domaines en masse' indicates the tool retrieves domains in bulk, which is clear but vague. It does not distinguish from sibling tools like get_domains_overview or get_domains_keywords, making it ambiguous what specific domain data is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les concurrents des domaines.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| mode | No | ||
| lineCount | No | ||
| page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits like pagination, rate limits, required permissions, or output format. This is a severe gap for a tool with no other 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but insufficiently detailed. It fails to earn its place by providing minimal value; it is under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (4 parameters, no output schema, many siblings), the description is completely inadequate. It does not explain parameters, output, or how it fits among similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines four parameters (input, mode, lineCount, page) with 0% description coverage. The description offers no explanation of their semantics, leaving the agent without necessary information to use the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtenir les concurrents des domaines' clearly indicates the tool retrieves domain competitors, but it lacks specificity on what kind of competitors and how it differs from sibling tools like get_domains_competitors_best_pages or get_domains_competitors_keywords_diff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_domains_competitors_best_pages or get_domains_competitors_keywords_diff. The context for use is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les meilleures pages des concurrents des domaines.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| competitors | No | ||
| mode | No | ||
| lineCount | No | ||
| page | No | ||
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| total_traffic_min | No | ||
| total_traffic_max | No | ||
| total_traffic_keep_na | No | ||
| positions_min | No | ||
| positions_max | No | ||
| keywords_min | No | ||
| keywords_max | No | ||
| exclusive_keywords_min | No | ||
| exclusive_keywords_max | No | ||
| besting_keywords_min | No | ||
| besting_keywords_max | No | ||
| bested_keywords_min | No | ||
| bested_keywords_max | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits such as data freshness, pagination, rate limits, or destructive effects. The description simply restates the function without any such details. For a tool with 19 parameters and no output schema, this lack of transparency hinders safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise. However, conciseness sacrifices completeness and structure. It lacks any breakdown or organization that would aid understanding. It is not overly verbose, but the extreme brevity is detrimental to utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (19 parameters, no output schema, 30 sibling tools), the description is grossly incomplete. It does not explain what the output contains, how the 'best' metric is defined, or how filtering works. The tool likely returns a list of pages with metrics, but this is omitted, making the tool almost unusable without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 5% of parameters have descriptions in the schema (order_by). The description adds no additional parameter meaning. With 19 parameters including filters like total_traffic_min, positions_min, etc., the agent has no insight into how these affect results. The description should at least explain the role of key parameters or the expected input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it gets 'best pages of competitors of domains', which indicates the tool retrieves top-performing pages from competitor domains. However, the term 'best' is vague and does not define the criteria (e.g., traffic, keywords). With many sibling tools (e.g., get_domains_top_pages, get_domains_competitors_keywords_best_pos), it is unclear how this tool differs, reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or under what conditions it is appropriate. The description does not mention prerequisites, limitations, or scenarios where other tools would be preferred. This omission leaves the agent without context for proper selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les meilleures positions des mots-clés des concurrents des domaines.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| volume_min | No | ||
| volume_max | No | ||
| cpc_min | No | ||
| cpc_max | No | ||
| competition_min | No | ||
| competition_max | No | ||
| kgr_min | No | ||
| kgr_max | No | ||
| kvi_min | No | ||
| kvi_max | No | ||
| kvi_keep_na | No | ||
| allintitle_min | No | ||
| allintitle_max | No | ||
| competitors | Yes | ||
| keywords | Yes | ||
| best_competitor_traffic_min | No | ||
| best_competitor_traffic_max | No | ||
| best_competitor_traffic_keep_na | No | ||
| best_competitor_position_min | No | ||
| best_competitor_position_max | No | ||
| competitors_positions_min | No | ||
| competitors_positions_max | No | ||
| unique_competitors_count_min | No | ||
| unique_competitors_count_max | No | ||
| keyword_word_count_min | No | ||
| keyword_word_count_max | No | ||
| keyword_include | No | ||
| keyword_exclude | No | ||
| volume_keep_na | No | ||
| cpc_keep_na | No | ||
| competition_keep_na | No | ||
| kgr_keep_na | No | ||
| allintitle_keep_na | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as whether the tool is read-only, destructive, rate-limited, or requires authorization. For a complex tool with 37 parameters, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it lacks structure and is under-specified for the tool's complexity. While not verbose, it does not earn its place by providing necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 37 parameters, low schema coverage, no output schema, and missing annotations, the description is woefully incomplete. An AI agent cannot effectively determine inputs, outputs, or behavior from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at only 8%, the description does not compensate. It fails to explain the meaning or relationship of the 37 parameters, many of which have no descriptions in the schema, leaving the AI agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves 'best positions' of competitors' keywords, providing a specific verb and resource. However, it is vague about what 'best positions' means and does not differentiate from sibling tools like 'get_domains_competitors_keywords_diff' or 'get_domains_competitors_best_pages'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about prerequisites, use cases, or exclusions given the numerous sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir la différence de mots-clés entre les domaines et leurs concurrents.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| volume_min | No | ||
| volume_max | No | ||
| cpc_min | No | ||
| cpc_max | No | ||
| competition_min | No | ||
| competition_max | No | ||
| kgr_min | No | ||
| kgr_max | No | ||
| kvi_min | No | ||
| kvi_max | No | ||
| kvi_keep_na | No | ||
| allintitle_min | No | ||
| allintitle_max | No | ||
| input | Yes | ||
| competitors | No | ||
| exclusive | No | ||
| missing | No | ||
| besting | No | ||
| bested | No | ||
| acceptedTypes | No | ||
| page | No | ||
| best_competitor_traffic_min | No | ||
| best_competitor_traffic_max | No | ||
| best_competitor_traffic_keep_na | No | ||
| best_reference_traffic_min | No | ||
| best_reference_traffic_max | No | ||
| best_reference_traffic_keep_na | No | ||
| best_reference_position_min | No | ||
| best_reference_position_max | No | ||
| competitors_positions_min | No | ||
| competitors_positions_max | No | ||
| unique_competitors_count_min | No | ||
| unique_competitors_count_max | No | ||
| keyword_word_count_min | No | ||
| keyword_word_count_max | No | ||
| keyword_include | No | ||
| keyword_exclude | No | ||
| volume_keep_na | No | ||
| cpc_keep_na | No | ||
| competition_keep_na | No | ||
| kgr_keep_na | No | ||
| allintitle_keep_na | No | ||
| google_indexed_min | No | ||
| google_indexed_max | No | ||
| google_indexed_keep_na | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'get difference' with no mention of side effects, rate limits, authentication, or what the output represents. This is a critical gap for a tool with 49 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but under-specified. It is a single sentence that adds no value beyond the name, missing necessary details to be effectively used.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count, lack of annotations, and absent output schema, the description is severely incomplete. It fails to provide enough context for an agent to understand the tool's function or how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 6%, and the tool description adds no information about parameters. The description does not explain the many filter and sorting parameters, leaving the agent blind to their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets keyword differences between domains and competitors, which matches the name. However, it does not distinguish it from sibling tools like get_domains_competitors or get_domains_competitors_keywords_best_pos, and the description is essentially a translation of the name without additional specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions, leaving the agent without direction for proper invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les domaines expirés.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | ||
| lineCount | No | ||
| page | No | ||
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Field used for sorting results. Default sorts by descending volume. | |
| total_pages_min | No | ||
| total_pages_max | No | ||
| total_domains_min | No | ||
| total_domains_max | No | ||
| referring_domains_min | No | ||
| referring_domains_max | No | ||
| total_keywords_min | No | ||
| total_keywords_max | No | ||
| total_traffic_min | No | ||
| total_traffic_max | No | ||
| total_top_100_positions_min | No | ||
| total_top_100_positions_max | No | ||
| total_top_50_positions_min | No | ||
| total_top_50_positions_max | No | ||
| total_top_10_positions_min | No | ||
| total_top_10_positions_max | No | ||
| total_top_3_positions_min | No | ||
| total_top_3_positions_max | No | ||
| total_top_100_traffic_min | No | ||
| total_top_100_traffic_max | No | ||
| total_top_50_traffic_min | No | ||
| total_top_50_traffic_max | No | ||
| total_top_10_traffic_min | No | ||
| total_top_10_traffic_max | No | ||
| total_top_3_traffic_min | No | ||
| total_top_3_traffic_max | No | ||
| matching_keywords_min | No | ||
| matching_keywords_max | No | ||
| matching_pages_min | No | ||
| matching_pages_max | No | ||
| matching_traffic_min | No | ||
| matching_traffic_max | No | ||
| matching_most_recent_position_min | No | ||
| matching_most_recent_position_max | No | ||
| matching_top_100_positions_min | No | ||
| matching_top_100_positions_max | No | ||
| matching_top_50_positions_min | No | ||
| matching_top_50_positions_max | No | ||
| matching_top_10_positions_min | No | ||
| matching_top_10_positions_max | No | ||
| matching_top_3_positions_min | No | ||
| matching_top_3_positions_max | No | ||
| matching_top_100_traffic_min | No | ||
| matching_top_100_traffic_max | No | ||
| matching_top_50_traffic_min | No | ||
| matching_top_50_traffic_max | No | ||
| matching_top_10_traffic_min | No | ||
| matching_top_10_traffic_max | No | ||
| matching_top_3_traffic_min | No | ||
| matching_top_3_traffic_max | No | ||
| matching_count_min | No | ||
| matching_count_max | No | ||
| count_min | No | ||
| count_max | No | ||
| first_time_available_min | No | Date in YYYY-MM-DD format | |
| first_time_available_max | No | Date in YYYY-MM-DD format | |
| last_time_available_min | No | Date in YYYY-MM-DD format | |
| last_time_available_max | No | Date in YYYY-MM-DD format | |
| firstseen_min | No | Date in YYYY-MM-DD format | |
| first_seen_max | No | Date in YYYY-MM-DD format | |
| last_seen_min | No | Date in YYYY-MM-DD format | |
| last_seen_max | No | Date in YYYY-MM-DD format | |
| fb_comments_min | No | ||
| fb_comments_max | No | ||
| fb_shares_min | No | ||
| fb_shares_max | No | ||
| pinterest_pins_min | No | ||
| pinterest_pins_max | No | ||
| root_domain_include | No | Regular expression for root domains to be included | |
| root_domain_exclude | No | Regular expression for root domains to be excluded |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as pagination, rate limits, or side effects. The description is minimalist and adds no value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified for a complex tool. Conciseness without essential information is not effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 75 parameters, no output schema, and no annotations, yet the description provides no context about usage, output format, or parameter relationships. It is completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 16%, but the description adds no meaning to any of the 75 parameters. With such low coverage, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtenir les domaines expirés' is a direct French translation of the tool name 'get_domains_expired', making it a tautology. It does not distinguish the tool from siblings like get_domains_bulk or get_domains_competitors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks any context about scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Révéler les domaines expirés.
| Name | Required | Description | Default |
|---|---|---|---|
| root_domain_keys | Yes | Seed keyword |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the action without disclosing read-only nature, permissions, or side effects. The description adds no behavioral context beyond the title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) but lacks substantive information. It is under-specified, not achieving conciseness with completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description should explain input expectations and output. It fails to describe what 'reveal' means operationally, what the output looks like, or any edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the parameter description 'Seed keyword' is vague and does not clarify that 'root_domain_keys' expects an array of numbers. The description fails to explain the semantic meaning of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Révéler les domaines expirés') with verb and resource. However, it does not distinguish this tool from the sibling 'get_domains_expired' tool, missing differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_domains_expired. No context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les backlinks des domaines GMB.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | Requested URL or domain | |
| mode | No | Whether to look for a domain or a full url. Leave empty for auto detection (options: auto, root, domain, url) | |
| lineCount | No | Max number of returned results (default: 20) | |
| page | No | Page number (default: 1) | |
| order_by | No | Field used for sorting results. Options: default, rating_count, rating_value, is_claimed, total_photos, name, address, phone, longitude, latitude, categories, url, domain, root_domain | |
| order | No | Whether results are sorted in ascending or descending order (asc, desc) | |
| rating_count_min | No | ||
| rating_count_max | No | ||
| rating_count_keep_na | No | ||
| rating_value_min | No | ||
| rating_value_max | No | ||
| rating_value_keep_na | No | ||
| latitude_min | No | ||
| latitude_max | No | ||
| latitude_keep_na | No | ||
| longitude_min | No | ||
| longitude_max | No | ||
| longitude_keep_na | No | ||
| categories_include | No | Regular expression for keywords to be included | |
| categories_exclude | No | Regular expression for keywords to be excluded | |
| is_claimed | No | When FALSE, only return unclaimed companies. When TRUE, only return claimed companies. Leave empty if you don't want to filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is only one sentence. It does not disclose any behavioral traits such as input validation, rate limits, or the nature of the output. The description carries the full burden but fails to deliver.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence), but it is under-specified rather than concise. Lacks front-loaded essential information; the single sentence does not earn its place as it provides minimal value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 21 parameters, no output schema, and many sibling tools, the description is severely incomplete. It fails to explain input format, filtering capabilities, or even the basic meaning of GMB. The agent cannot effectively invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 43% (only 9 of 21 parameters have descriptions). The description adds no information about parameters, leaving many fields like rating_count_min, latitude_min, and filtering options unexplained. The description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves backlinks of GMB domains, which is clear but does not differentiate from sibling tools like get_domains_gmb_backlinks_categories or get_domains_gmb_backlinks_map. The acronym GMB is not explained, assuming domain knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, no conditions for use. The agent has no context to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les catégories des backlinks des domaines GMB.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| mode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only implies a read operation ('obtenir') but discloses no traits like auth needs, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence) but fails to include essential information about parameters or behavior. It is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two undocumented parameters, no output schema, and no annotations, the description is completely inadequate for an agent to reliably use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the parameters 'input' or 'mode'. An agent cannot determine what values to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves categories of backlinks for GMB domains. It uses a specific verb-resource combination and implicitly distinguishes from sibling tools like get_domains_gmb_backlinks (which gets backlinks, not categories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir la carte des backlinks des domaines GMB.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| mode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only says 'carte des backlinks' without specifying output format (e.g., URL, data map) or safety profile (read vs. destructive). Lack of detail leaves agent guessing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, efficient in length but lacks critical details. Some waste by not explaining parameters; conciseness is acceptable but not optimal given missing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and two undocumented parameters, the description is insufficient. Agent cannot determine expected output, parameter usage, or when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions. The description adds no meaning for 'input' or 'mode'. Agent has no clue what these parameters represent or how to format them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Obtenir la carte des backlinks des domaines GMB.' It directly indicates the tool's purpose and distinguishes it from siblings like get_domains_gmb_backlinks (likely list) and get_domains_gmb_backlinks_categories, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_domains_gmb_backlinks or get_domains_gmb_backlinks_categories. No context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir l’historique des positions des domaines.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| mode | No | ||
| date_from | Yes | ||
| date_to | Yes | ||
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| known_versions_min | No | ||
| known_versions_max | No | ||
| total_traffic_min | No | ||
| total_traffic_max | No | ||
| unique_keywords_min | No | ||
| unique_keywords_max | No | ||
| total_top_3_min | No | ||
| total_top_3_max | No | ||
| total_top_10_min | No | ||
| total_top_10_max | No | ||
| total_top_50_min | No | ||
| total_top_50_max | No | ||
| total_top_100_min | No | ||
| total_top_100_max | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., read-only, side effects, permissions). The agent gains no insight beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single vague sentence. While concise, it fails to provide necessary detail; it does not earn its place because it adds little value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex schema with 21 parameters and no output schema or annotations, the description is severely incomplete. It fails to explain filtering, output format, or usage context, leaving the agent with almost no useful information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (3 out of 21 parameters have descriptions). The tool description adds no parameter information, leaving the agent to infer meaning from parameter names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves the history of domain positions, which is a clear verb+resource. However, it is vague and does not distinguish from similar siblings like 'get_domains_history_positions' or 'get_domains_positions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines on when to use this tool versus alternatives. With many similar sibling tools, the description fails to provide any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir l’historique des positions des domaines.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| volume_min | No | ||
| volume_max | No | ||
| cpc_min | No | ||
| cpc_max | No | ||
| competition_min | No | ||
| competition_max | No | ||
| kgr_min | No | ||
| kgr_max | No | ||
| kvi_min | No | ||
| kvi_max | No | ||
| kvi_keep_na | No | ||
| allintitle_min | No | ||
| allintitle_max | No | ||
| input | Yes | ||
| date_from | Yes | ||
| date_to | Yes | ||
| word_count_min | No | ||
| word_count_max | No | ||
| best_position_min | No | ||
| best_position_max | No | ||
| worst_position_min | No | ||
| worst_position_max | No | ||
| first_time_seen_min | No | ||
| first_time_seen_max | No | ||
| last_time_seen_min | No | ||
| last_time_seen_max | No | ||
| most_recent_position_min | No | ||
| most_recent_position_max | No | ||
| subdomain_count_min | No | ||
| subdomain_count_max | No | ||
| page_count_min | No | ||
| page_count_max | No | ||
| still_there | No | ||
| keyword_include | No | ||
| keyword_exclude | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It only states the action without any details on side effects, authentication needs, rate limits, output format, or whether the operation is read-only. This is a complete lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but at the expense of essential information. It does not front-load critical details like required parameters, output format, or behavioral notes. The brevity reduces its utility significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 39 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain the tool's purpose, filtering capabilities, or return data. The agent cannot understand how to use the tool effectively based solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the 39 parameters. With only 8% schema description coverage (only 3 parameters have descriptions), the description fails to compensate by explaining key parameters like 'mode', 'still_there', or filter ranges. The agent is left to infer from parameter names alone, which are often ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the history of domain positions' indicates a specific verb and resource, but it lacks differentiation from sibling tools like get_domains_positions (likely current positions) and get_domains_history_pages (history of pages). It does not clarify what 'positions' means (e.g., search engine rankings), making the purpose somewhat vague among many similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_domains_positions or get_domains_overview. The agent receives no contextual cues about prerequisites, typical 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.
Obtenir les mots-clés des domaines.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| volume_min | No | ||
| volume_max | No | ||
| cpc_min | No | ||
| cpc_max | No | ||
| competition_min | No | ||
| competition_max | No | ||
| kgr_min | No | ||
| kgr_max | No | ||
| kvi_min | No | ||
| kvi_max | No | ||
| kvi_keep_na | No | ||
| allintitle_min | No | ||
| allintitle_max | No | ||
| input | Yes | ||
| keywords | Yes | ||
| position_min | No | ||
| position_max | No | ||
| traffic_min | No | ||
| traffic_max | No | ||
| title_word_count_min | No | ||
| title_word_count_max | No | ||
| serp_date_min | No | ||
| serp_date_max | No | ||
| keyword_include | No | ||
| keyword_exclude | No | ||
| title_include | No | ||
| title_exclude | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as rate limits, output format, or side effects. The minimal description fails to inform the agent about what the tool does beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but severely under-specified. It lacks any structure or critical details, making it insufficient for correct tool usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 31 parameters, no output schema, and no annotations, the description is completely inadequate. The agent has no information about how to invoke the tool correctly or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 10% schema description coverage, the description does not add meaning beyond the input schema. It provides no context for the 31 parameters, many of which are undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtenir les mots-clés des domaines' indicates the tool retrieves keywords for domains, but it is vague and does not differentiate from many sibling tools like get_keywords_find or get_keywords_related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks any context about prerequisites, filters, or comparison with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir un aperçu des domaines.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Seed keyword | |
| mode | No | ||
| requested_data | No | Specific data fields to request | |
| lang | No | Seed keyword |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states 'get an overview' with no mention of read-only behavior, side effects, or any behavioral traits. This is insufficient for an agent to understand the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but overly minimal. It front-loads the basic purpose but lacks structure and necessary details for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain what the overview consists of, how parameters affect output, or what a typical response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, but the tool description adds no explanation of parameters. The schema itself has some descriptions (e.g., 'Seed keyword' for input and lang), but the overall description does not help an agent understand how to use parameters like 'mode' or 'requested_data' in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtenir un aperçu des domaines' (Get an overview of domains) gives a general idea of retrieving domain overview data, but it is vague. It does not specify what data is included in the overview, making it hard to distinguish from sibling tools like get_domains_bulk or get_domains_competitors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les positions des domaines.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| volume_min | No | ||
| volume_max | No | ||
| cpc_min | No | ||
| cpc_max | No | ||
| competition_min | No | ||
| competition_max | No | ||
| kgr_min | No | ||
| kgr_max | No | ||
| kvi_min | No | ||
| kvi_max | No | ||
| kvi_keep_na | No | ||
| allintitle_min | No | ||
| allintitle_max | No | ||
| input | Yes | ||
| traffic_min | No | ||
| traffic_max | No | ||
| position_min | No | ||
| position_max | No | ||
| keyword_word_count_min | No | ||
| keyword_word_count_max | No | ||
| serp_date_min | No | ||
| serp_date_max | No | ||
| keyword_include | No | ||
| keyword_exclude | No | ||
| title_include | No | ||
| title_exclude | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as data freshness, mutation effects, rate limits, or other side effects. The agent has no insight into what the tool does besides the minimal description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure. It is too minimal for a tool with 30 parameters and many siblings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (30 params, no output schema, many siblings), the description is woefully incomplete. It does not describe return values, filtering behavior, or any contextual details needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 10%, and the description adds no information about the 30 parameters. The required 'input' parameter is not explained. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtenir les positions des domaines' gives a verb and resource, but it is vague and does not distinguish from sibling tools like get_domains_history_positions. The schema includes many keyword metrics (volume, cpc), suggesting the tool might not simply return positions. The purpose is unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its many siblings. There is no mention of use cases, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les pages principales des domaines.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| mode | No | ||
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| known_versions_min | No | ||
| known_versions_max | No | ||
| total_traffic_min | No | ||
| total_traffic_max | No | ||
| unique_keywords_min | No | ||
| unique_keywords_max | No | ||
| total_top_3_min | No | ||
| total_top_3_max | No | ||
| total_top_10_min | No | ||
| total_top_10_max | No | ||
| total_top_50_min | No | ||
| total_top_50_max | No | ||
| total_top_100_min | No | ||
| total_top_100_max | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits; it only implies a read operation without details on data source, freshness, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-specified; it borders on being too sparse for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 19 parameters, no output schema, and no annotations, the description provides virtually no context, making the tool very incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 16%, and the description adds no parameter information, failing to compensate for low coverage. Many parameters like known_versions_min remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'get the main pages of domains', which indicates the tool retrieves top pages but does not define 'main' (e.g., by traffic or ranking) and does not distinguish from siblings like get_domains_history_pages or get_domains_keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les tendances de visibilité des domaines.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| mode | No | ||
| type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral aspects such as data freshness, permissions, rate limits, or side effects. It merely states the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It does not front-load key details or break down information effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of three parameters with no schema descriptions and no output schema, the description is grossly incomplete. It fails to explain what the tool returns or how to use the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The three parameters (input, mode, type) are not explained in the description, leaving the agent to guess their meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'domain visibility trends'. It distinguishes from sibling tools like get_domains_overview or get_domains_keywords, though it does not specify the exact nature of 'trends'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool vs alternatives, no prerequisites, no context about typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir des mots-clés en masse.
| Name | Required | Description | Default |
|---|---|---|---|
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| volume_min | No | ||
| volume_max | No | ||
| cpc_min | No | ||
| cpc_max | No | ||
| competition_min | No | ||
| competition_max | No | ||
| kgr_min | No | ||
| kgr_max | No | ||
| kvi_min | No | ||
| kvi_max | No | ||
| kvi_keep_na | No | ||
| allintitle_min | No | ||
| allintitle_max | No | ||
| word_count_min | No | ||
| word_count_max | No | ||
| include | No | ||
| exclude | No | ||
| keywords | Yes | ||
| exact_match | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency duty. It only states 'get keywords in bulk' without explaining what data is returned (e.g., volume, competition), how filtering works, or any behavior like pagination. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence), but it is too sparse to be considered appropriately sized. It is not front-loaded with critical information and reads more as a placeholder than a well-structured summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 22 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the tool's core functionality, the meaning of filters, or the expected output, making it nearly useless for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 14% (3 of 22 parameters have descriptions). The description does not add any parameter-level meaning beyond the schema. It fails to explain the purpose of key parameters like volume_min, competition, or include/exclude, leaving the agent with insufficient context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtenir des mots-clés en masse' (Get keywords in bulk) clearly identifies the verb and resource, but it lacks specificity about what 'bulk' means compared to siblings like get_keywords_find or get_keywords_match. It does not indicate whether it accepts multiple keywords as input or returns aggregated data, making it only adequate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling keyword tools. No context about prerequisites, when it is appropriate, or when to avoid it. This is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trouver des mots-clés.
| Name | Required | Description | Default |
|---|---|---|---|
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| volume_min | No | ||
| volume_max | No | ||
| cpc_min | No | ||
| cpc_max | No | ||
| competition_min | No | ||
| competition_max | No | ||
| kgr_min | No | ||
| kgr_max | No | ||
| kvi_min | No | ||
| kvi_max | No | ||
| kvi_keep_na | No | ||
| allintitle_min | No | ||
| allintitle_max | No | ||
| word_count_min | No | ||
| word_count_max | No | ||
| include | No | ||
| exclude | No | ||
| keyword | No | Seed keyword | |
| keywords | No | ||
| keywords_sources | No | ||
| keep_seed | No | ||
| exact_match | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., read-only, destructive, rate limits) beyond the verb 'find', which is already obvious from the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description is severely underspecified, not concise. It lacks any front-loaded essential information and contains no meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 25 parameters, no output schema, and no annotations, the description is completely inadequate. It fails to explain what the tool returns, how to use filters, or any operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 16%, and the tool description adds no parameter explanations whatsoever. The 84% of undocumented parameters lack any context from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Trouver des mots-clés' is a tautology of the tool name (get_keywords_find), restating it in French. It fails to specify what kind of keyword finding operation this performs, especially given numerous sibling tools like get_keywords_related, get_keywords_similar, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance provided; there is no mention of when to use this tool versus alternatives, no prerequisites, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les points forts des mots-clés.
| Name | Required | Description | Default |
|---|---|---|---|
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| volume_min | No | ||
| volume_max | No | ||
| cpc_min | No | ||
| cpc_max | No | ||
| competition_min | No | ||
| competition_max | No | ||
| kgr_min | No | ||
| kgr_max | No | ||
| kvi_min | No | ||
| kvi_max | No | ||
| kvi_keep_na | No | ||
| allintitle_min | No | ||
| allintitle_max | No | ||
| word_count_min | No | ||
| word_count_max | No | ||
| include | No | ||
| exclude | No | ||
| keyword | Yes | Seed keyword | |
| exact_match | No | ||
| similarity_min | No | ||
| similarity_max | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as read/write nature, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks essential detail and structure to be helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 24 parameters, no output schema, and no annotations, the description is severely incomplete; it does not explain return values, filtering, or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 17% schema description coverage, the description adds no meaning to the 24 parameters; many parameters remain undocumented and the description does not clarify them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the highlights of keywords' is vague; it does not specify what constitutes 'highlights' or distinguish it from siblings like get_keywords_overview or get_keywords_bulk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives; the description lacks context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir la correspondance des mots-clés.
| Name | Required | Description | Default |
|---|---|---|---|
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| volume_min | No | ||
| volume_max | No | ||
| cpc_min | No | ||
| cpc_max | No | ||
| competition_min | No | ||
| competition_max | No | ||
| kgr_min | No | ||
| kgr_max | No | ||
| kvi_min | No | ||
| kvi_max | No | ||
| kvi_keep_na | No | ||
| allintitle_min | No | ||
| allintitle_max | No | ||
| word_count_min | No | ||
| word_count_max | No | ||
| include | No | ||
| exclude | No | ||
| keyword | Yes | Seed keyword | |
| exact_match | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not mention side effects, data requirements, rate limits, or any behavioral traits beyond the vague purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one phrase), which might seem concise, but it lacks substance. It fails to convey necessary details, making it under-specification rather than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 22 parameters and no output schema or annotations, the description is severely incomplete. An agent cannot understand the tool's purpose, parameters, or behavior from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 18%, meaning most parameters lack descriptions. The description does not add any information about what parameters like 'include', 'exclude', or range filters are used for, leaving agents underinformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtenir la correspondance des mots-clés.' is vague; it does not specify what 'match' means or what the tool actually returns. Given the large set of sibling tools (e.g., get_keywords_find, get_keywords_similar), there is no differentiation, making it hard for an agent to select correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over its siblings or alternatives. There is no context about prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir un aperçu des mots-clés.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Seed keyword | |
| requested_data | No | Specific data fields to request | |
| lang | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides no behavioral details (e.g., read-only, data returned, side effects). The single sentence 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but at the expense of informativeness. It is under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and sibling diversity, the description is completely inadequate. It fails to convey what the overview includes or when to use the tool, making it unhelpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, but the description adds no extra meaning to the parameters. It does not explain the purpose of 'keyword', 'requested_data', or 'lang' beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtenir un aperçu des mots-clés' (Get an overview of keywords) is almost a tautology of the tool name. It does not specify what kind of overview or distinguish it from sibling tools like get_keywords_bulk or get_keywords_find.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. The description lacks context for the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les questions liées aux mots-clés.
| Name | Required | Description | Default |
|---|---|---|---|
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| volume_min | No | ||
| volume_max | No | ||
| cpc_min | No | ||
| cpc_max | No | ||
| competition_min | No | ||
| competition_max | No | ||
| kgr_min | No | ||
| kgr_max | No | ||
| kvi_min | No | ||
| kvi_max | No | ||
| kvi_keep_na | No | ||
| allintitle_min | No | ||
| allintitle_max | No | ||
| word_count_min | No | ||
| word_count_max | No | ||
| include | No | ||
| exclude | No | ||
| keyword | Yes | Seed keyword | |
| exact_match | No | ||
| question_types | No | ||
| keep_only_paa | No | ||
| depth_min | No | ||
| depth_max | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a one-sentence description, the tool's behavioral traits are completely undisclosed. The agent does not know about pagination, rate limits, data freshness, or the nature of 'questions' returned. This is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely concise, the description is too minimal to be useful. It sacrifices essential information for brevity, resulting in a single vague sentence that does not earn its place given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 26 parameters, minimal schema coverage, no annotations, and no output schema, the description is grossly incomplete. An agent cannot infer required parameters beyond 'keyword', nor understand the filters, return format, or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no value beyond the schema for 26 parameters. With only 15% schema description coverage, the burden on the description is high, but it fails to clarify any parameter's meaning, purpose, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get questions related to keywords' clearly states the tool's function and distinguishes it from sibling tools that return keywords, domains, or other data. However, it lacks specificity about the source of questions (e.g., SERP People Also Ask, forums) which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_keywords_find or get_keywords_related. There is no mention of prerequisites or typical use cases, leaving the agent without context for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extraire les mots-clés.
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details such as whether the tool performs reading or mutation, its side effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified; it sacrifices clarity for brevity and does not earn its place as a complete explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple structure but many siblings, the description is severely incomplete, failing to convey the tool's unique function or output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not explain the purpose or expected format of the 'keywords' parameter beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Extraire les mots-clés' (extract keywords) indicates a basic verb+resource, but it lacks specificity about what is extracted (e.g., search volume, SERP data) and does not distinguish the tool from many siblings like get_keywords_overview or get_keywords_related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any conditions or prerequisites for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les dates disponibles des mots-clés dans les SERP.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Seed keyword |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Aucune annotation fournie, la description doit compenser. Elle ne mentionne pas le comportement (ex: format des dates, gestion des erreurs, limites de requêtes). Pour un outil sans annotations, c'est insuffisant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Phrase unique, sans information superflue. Efficace mais pourrait inclure davantage de détails sans nuire à la concision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Outil simple avec un seul paramètre et sans schéma de sortie. La description reste trop minimaliste : elle n'explique pas ce que l'agent peut attendre en retour ni comment interpréter les dates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
La couverture du schéma est de 100% (paramètre 'keyword' décrit comme 'Seed keyword'). La description n'ajoute pas de valeur sémantique au-delà du schéma. Baseline 3 justifié.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Le verbe 'Obtenir' et le nom 'dates disponibles des mots-clés dans les SERP' décrivent précisément l'action et la ressource. Cette description se distingue clairement des outils frères comme get_keywords_serp_compare qui compare des SERP.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Aucune indication sur quand utiliser cet outil par rapport aux alternatives (ex: get_keywords_serp_compare, get_keywords_overview). L'absence de contexte d'utilisation ou de contre-indications limite l'aide à l'agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comparer les mots-clés dans les SERP.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Seed keyword | |
| period | Yes | ||
| first_date | No | ||
| second_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states 'compare keywords'. It does not disclose whether the tool is read-only, any destructive actions, authentication needs, or output nature. The brief description leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it sacrifices essential information for brevity. It is too minimal to be useful for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and minimal parameter descriptions, the description is insufficient for complete understanding. It lacks return value info, usage context, and behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'keyword' has a description). The description adds no explanation for 'period', 'first_date', or 'second_date', failing to clarify their roles or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Comparer les mots-clés dans les SERP' clearly indicates comparing keywords in search engine results pages. It aligns with the tool name and distinguishes from siblings like get_keywords_serp_availableDates and get_keywords_serp_pageEvolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other SERP-related tools (e.g., get_keywords_serp_availableDates, get_keywords_serp_pageEvolution). The agent has no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir l'évolution des pages SERP des mots-clés.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Seed keyword | |
| first_date | Yes | ||
| second_date | Yes | ||
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It only says 'get evolution', but does not disclose if this is a read-only operation, any side effects, or authentication needs. The behavior is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence and concise. However, it sacrifices informativeness for brevity, missing key details that would make it more useful without being longer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 required parameters, no output schema, and no annotations, the description is incomplete. It does not explain the return format, date semantics, or how the URL is used, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'keyword' described). The description adds no meaning to 'first_date', 'second_date', or 'url', leaving their purpose ambiguous. This is a critical gap for a tool with 4 required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it retrieves SERP page evolution for keywords, which is clear. However, it does not distinguish from sibling tools like get_keywords_serp_compare or get_keywords_serp_availableDates, missing an opportunity for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description is minimal and provides no context about prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir la correspondance des mots-clés.
| Name | Required | Description | Default |
|---|---|---|---|
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| volume_min | No | ||
| volume_max | No | ||
| cpc_min | No | ||
| cpc_max | No | ||
| competition_min | No | ||
| competition_max | No | ||
| kgr_min | No | ||
| kgr_max | No | ||
| kvi_min | No | ||
| kvi_max | No | ||
| kvi_keep_na | No | ||
| allintitle_min | No | ||
| allintitle_max | No | ||
| word_count_min | No | ||
| word_count_max | No | ||
| include | No | ||
| exclude | No | ||
| keyword | Yes | Seed keyword | |
| similarity_min | No | ||
| similarity_max | No | ||
| score_min | No | ||
| score_max | No | ||
| p1_score_min | No | ||
| p1_score_max | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavioral traits. It provides none—no mention of read-only nature, side effects, limitations, or output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not concisely helpful—it is under-specified. A single vague phrase does not earn its place, as it fails to convey essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (27), no output schema, and no annotations, the description is utterly incomplete. It provides no context about return values, filtering logic, or how the tool operates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 15%, yet the description adds no value by explaining any of the 27 parameters or their interplay. The single phrase does not help interpret the many filter options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtenir la correspondance des mots-clés' (Get the correspondence of keywords) is vague and does not clarify what 'correspondence' means. It fails to distinguish this tool from siblings like get_keywords_related or get_keywords_match, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it describe prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir la structure du site des mots-clés.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | Seed keyword | |
| keywords | No | ||
| exact_match | No | ||
| neighbours_sources | No | ||
| multipartite_modes | No | ||
| neighbours_sample_max_size | No | ||
| mode | No | ||
| granularity | No | ||
| manual_common_10 | No | ||
| manual_common_100 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does not disclose whether the tool is read-only, requires authentication, has rate limits, or what the output structure is. The minimal description adds no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but insufficient. It lacks structure, front-loading critical information, and does not provide enough detail to be useful. The brevity sacrifices clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, many siblings), the description is severely incomplete. It does not explain return values, parameter usage, or the meaning of 'site structure,' leaving the agent with little actionable information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 10% (only 'keyword' has a description). The tool description does not explain any parameters beyond the schema, failing to compensate for the low coverage. Agents cannot infer parameter roles or combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets the site structure of keywords, indicating a verb and resource. However, it is vague and does not clarify what 'site structure' means (e.g., sitemap, URL hierarchy). It fails to distinguish this tool from similar siblings like get_keywords_overview or get_keywords_bulk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No examples, context, or conditions are mentioned, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les synonymes des mots-clés.
| Name | Required | Description | Default |
|---|---|---|---|
| lineCount | No | Max number of returned results. | |
| order_by | No | Field used for sorting results. Default sorts by descending volume. | |
| order | No | Whether the results are sorted in ascending or descending order. | |
| volume_min | No | ||
| volume_max | No | ||
| cpc_min | No | ||
| cpc_max | No | ||
| competition_min | No | ||
| competition_max | No | ||
| kgr_min | No | ||
| kgr_max | No | ||
| kvi_min | No | ||
| kvi_max | No | ||
| kvi_keep_na | No | ||
| allintitle_min | No | ||
| allintitle_max | No | ||
| word_count_min | No | ||
| word_count_max | No | ||
| include | No | ||
| exclude | No | ||
| keyword | Yes | Seed keyword | |
| exact_match | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose any behavioral traits beyond the basic purpose. With 22 parameters and no behavioral context, the description is severely lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified and lacks necessary detail. It does not earn its place, as it provides minimal utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 22 parameters, no output schema, and no annotations, the description is woefully incomplete. It fails to cover essential aspects like filtering, sorting, or result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 18%, and the description adds no meaning to any parameter. Critical parameters like volume_min, cpc_min, etc., remain unexplained. The description does not compensate for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get synonyms of keywords,' which identifies a verb and resource, but it is vague and does not distinguish from sibling tools like get_keywords_related or get_keywords_similar. With many similar keyword tools, the purpose is unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools suggest overlapping functionality, but the description offers no exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les meilleurs mots-clés de la page.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| lineCount | No | ||
| strategy | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It states 'get best keywords' but fails to disclose that this is a read operation, what 'best' means, or any side effects, rate limits, or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, achieving conciseness but lacking structure. It is not front-loaded with critical details beyond the purpose. Every word is necessary given the brevity, but the description is underspecified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain input format, lineCount, strategy, or return values, leaving major gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (input, lineCount, strategy) with 0% description coverage. The description does not mention or explain any parameter meaning, usage, or expected values, leaving the agent entirely in the dark.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the best keywords of a page. The verb 'obtenir' and resource 'meilleurs mots-clés de la page' are specific, and the tool name mirrors this. However, it does not differentiate from siblings like 'get_keywords_find' or 'get_domains_top_pages'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its many siblings, such as 'get_keywords_find' or 'get_domains_top_pages'. No context, exclusions, or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtenir les informations de crédit de l'utilisateur.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, side effects, or authentication requirements. The description fails to compensate for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that is front-loaded with the action. No extraneous content; every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides the minimal information needed. However, it lacks details about what the credit info contains (e.g., balance, usage) and the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so baseline is 4. Description adds no parameter-specific meaning but this is appropriate given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves user credit information. Distinct from sibling tools which focus on domains/keywords, so no ambiguity about purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, given the distinct subject (user credit vs. domains/keywords), usage context is implied. Still lacks formal 'when-to-use' or 'when-not-to-use' instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.0.13get_domains_bulkget_domains_competitorsget_domains_competitors_best_pagesget_domains_competitors_keywords_best_posget_domains_competitors_keywords_diffget_domains_expiredget_domains_expired_revealget_domains_gmb_backlinksget_domains_gmb_backlinks_categoriesget_domains_gmb_backlinks_mapget_domains_history_pagesget_domains_history_positionsget_domains_keywordsget_domains_overviewget_domains_positionsget_domains_top_pagesget_domains_visibility_trendsget_keywords_bulkget_keywords_findget_keywords_highlightsget_keywords_matchget_keywords_overviewget_keywords_questionsget_keywords_relatedget_keywords_scrapget_keywords_serp_availableDatesget_keywords_serp_compareget_keywords_serp_pageEvolutionget_keywords_similarget_keywords_site_structureget_keywords_synonymsget_page_best_keywordsget_user_creditMost tools have distinct purposes, but there is some overlap among keyword-related tools (e.g., get_keywords_match, get_keywords_similar) and between get_domains_history_pages and get_domains_history_positions, which could cause confusion.
All tool names follow a consistent get_entity_action pattern using snake_case, making it easy to infer the purpose from the name.
33 tools is on the high side, but the broad scope of SEO analysis (domains, keywords, competitors, SERPs) may justify the count. However, some tools seem redundant, so the count could be trimmed.
The tool set covers a wide range of SEO data retrieval needs (domains, keywords, competitors, SERP, backlinks). Minor gaps include lack of user management beyond credit info and potential redundancy between match and similar tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
SEO research, audits, backlinks, GSC, and content workflow tools for AI agents.
AI-powered SEO and marketing: keyword research, SERP analysis, and content optimization tools.
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
Semrush MCP Pack — SEO analytics via the Semrush Analytics API.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/occirank/Haloscan-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
