ahrefs-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources (keyword data, domain data, backlinks, SERP). Some overlap exists among keyword-related tools like keyword-metrics, keyword-suggestions, and related-keywords, but their descriptions clarify the differences. Overall, an agent can usually pick the right tool without confusion.
Naming Consistency5/5
All tool names follow a consistent lowercase-hyphenated noun-phrase pattern (e.g., keyword-volume-history, site-metrics-by-country). No mixed conventions or verb-style changes. Names are predictable and align well with their purposes, despite 'keyword-metrics' being slightly misleading about its actual function.
Tool Count4/5
16 tools is slightly above the typical 3-15 range but reasonable for a comprehensive SEO toolkit covering keyword research, domain metrics, backlinks, and SERP data. It is well-scoped for the server's purpose and does not feel bloated or redundant.
Completeness4/5
The tool set covers the core Ahrefs workflows: keyword research (volume, metrics, suggestions, related), domain organic search profiles (competitors, top pages, site metrics), backlink analysis (stats, referring domains), and SERP overviews. Minor gaps exist (e.g., no rank-tracker history or site audit data) but they are beyond the apparent scope and agents can work around them using available tools.
Average 3.5/5 across 16 of 16 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the output is by country but does not disclose limitations (e.g., only organic traffic), data freshness, or how country geography is determined. The 'real geography' phrase is vague and lacks concrete behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences and is concise, but the second sentence ('Shows the site's real geography') adds little concrete information and is somewhat redundant with the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two parameters and no output schema, the description conveys the core function. However, the lack of parameter documentation and any note about response format leaves gaps, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (target is described, limit is not). The description does not mention either parameter, failing to compensate for the undocumented 'limit' parameter or add any meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides organic traffic of a domain split by country, which distinguishes it from site-metrics (overall metrics) and keyword-volume-by-country (keyword-level data). The verb is implied rather than explicit, but the resource and scope are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings such as site-metrics or keyword-volume-by-country. The only context is implied by the tool name and description, with no exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It names the output metrics but does not disclose whether the operation is read-only, how errors are handled, or any rate limits or authentication requirements. For a simple lookup, the absence of side effects is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. However, it lacks a leading verb, which would make it slightly more serviceable. Still, it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup tool, the description covers the core output but omits the return format and edge-case behavior (e.g., invalid domain). With no output schema, the description should have detailed the response structure, but given the tool's simplicity, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'target', is fully described in the schema (domain or URL to analyze). The description adds no additional parameter semantics beyond the schema, but with 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's output: Domain Rating (0–100) and Ahrefs Rank for a domain. It distinguishes from sibling tools that focus on keywords, backlinks, or site metrics, though it lacks an explicit verb like 'gets' or 'returns'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions. It does not reference sibling tools or mention use cases such as domain authority checks or competitor analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool shows trend and seasonality, implying a time series, but does not disclose output format, date range, data update frequency, or any limitations. It is under-specified for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words that is front-loaded with the core purpose. It is clear, direct, and contains no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or behavioral guidance, the description is incomplete for practical use. It does not explain what the returned data looks like (e.g., a list of month/value pairs), how far back the history goes, or how the trend is presented. Given the presence of 15 sibling tools, more contextual detail is needed to differentiate and understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with only 'country' documented. The description adds semantic value to the 'keyword' parameter by stating it relates to 'search volume history for a keyword,' but it does not clarify the optional 'country' parameter behavior. The description partially compensates for the undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'Monthly search volume history for a keyword' and explicitly mentions 'Shows trend and seasonality.' This goes beyond a simple restatement of the title, using specific verbs and resource scope that distinguishes it from siblings like keyword-volume-by-country or keyword-metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It fails to mention that this is for historical/trend analysis as opposed to current metrics (keyword-metrics) or country-specific breakdowns (keyword-volume-by-country). No exclusions or prerequisite scenarios are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the temporal scope (live vs. all-time), which is useful, but does not mention data update frequency, limitations, or whether results are aggregated or raw. This is a minimal but non-trivial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key purpose. It contains no unnecessary words or repetition, making it optimally scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core outputs (backlinks, referring domains) and adds the live/all-time distinction. However, without an output schema or annotations, it leaves the agent uncertain about the exact response shape, so it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single 'target' parameter with an example. The description adds no additional parameter context, so the baseline score of 3 applies given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's output (backlink footprint with live and all-time backlinks and referring domains). It is specific about the data delivered, but does not explicitly differentiate from sibling tools like 'referring-domains'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description only defines the tool's function without context about complementary or competing tools, leaving usage decisions entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description bears the full burden of disclosing behavior. It explains that results are keyword ideas with various metrics, but does not disclose any operational aspects such as result ordering, default limit handling, pagination, rate limits, or whether the operation is read-only. The schema mentions server-side filtering, but that is in the schema, not the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence effectively captures the tool's function and output fields, the second adds helpful provenance. No wasted words or redundant restatements of the name/title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and many sibling tools, the description should provide enough context to choose this tool correctly. It does describe the core output, but misses usage guidance, parameter behavior, and how it relates to similar keyword tools. This makes it minimally complete but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 75% of parameters with descriptions (keyword, country, min_volume). The description adds no new parameter semantics beyond implying 'keyword' is the seed term. Since schema coverage is high, the baseline of 3 is appropriate; no extra credit is earned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns keyword ideas matching a seed term, and enumerates the specific metrics included (volume, difficulty, CPC, etc.). It also distinguishes itself by referencing 'Ahrefs Keywords Explorer matching-terms', which differentiates it from sibling tools like keyword-suggestions or related-keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or scenarios where another sibling tool would be preferable. While the name and description hint at the matching-terms use case, the agent receives no direction relative to the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It reveals that results include shared keywords and traffic, but omits details about response structure, pagination, rate limits, or whether any filters are applied. This is a significant gap for a tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise and front-loaded, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide more context about the response format and data interpretation. It mentions 'shared keywords and traffic' but leaves the output structure ambiguous. The tool is simple but the description is incomplete for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'target' and 'country' with descriptions; 'limit' lacks a description. The tool description adds no parameter-specific information, failing to compensate for the missing 'limit' explanation. With 67% schema coverage, the description should add value but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's function: identifying competitor domains in organic search, including shared keywords and traffic. This distinguishes it from sibling tools like 'organic-keywords', which focus on keywords rather than domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (finding competitors) but provides no explicit guidance on when to use this tool versus alternatives like 'related-keywords' or 'organic-keywords'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It does list the returned fields (volume, difficulty, CPC, best position, traffic), which is useful. However, it does not mention pagination, rate limits, whether the result is a list or single object, or any prerequisites. This partial disclosure warrants a middle score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and followed by a brief, impactful value statement. Every word earns its place; there is no fluff or redundancy. This is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema. The description lists the key return metrics but omits details about list structure, pagination, or country-specific behavior. It is adequate for simple understanding but leaves questions for an agent needing to parse results or handle large datasets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (target and country are described, limit is not). The description adds no extra meaning for parameters; it merely restates that the target is a domain, which the schema already says. With only moderate coverage and no compensatory detail in the description, the semantics are under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns 'Keywords a domain ranks for' with specific metrics (volume, difficulty, CPC, best position, traffic). This clearly distinguishes it from sibling tools like keyword-suggestions or related-keywords, which imply idea generation rather than actual ranking data. However, it lacks an explicit verb like 'get' or 'list', so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'The clonable demand behind a competitor' implies a competitor-analysis use case, giving the agent a hint about when to use it. But it does not explicitly mention alternatives or provide when/not-to-use guidance. Usage is implied rather than clearly stated, so a score of 3 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the type of data returned (top pages, keywords, traffic value) but omits any details about request behavior, such as rate limits, pagination, data freshness, or how the 'limit' parameter affects results. As a read-only analytics tool, the absence of explicit safety cues is acceptable, but there is no extra behavioral context beyond the raw description of output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing exactly two sentences that convey the core purpose and a practical use case. It is front-loaded with the essential information and contains no fluff or redundant details, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema and no annotations, the description is somewhat complete but leaves gaps. It clearly states what the tool returns, but it does not describe the exact structure or fields of the response, nor does it mention behavior around limits or country filtering (though the schema covers the latter). Given the lack of output schema, more detail on the return format would be valuable, making this only minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (target and country have descriptions, limit does not). The description does not elaborate on any parameter specifics, relying instead on the schema. It adds domain/organic traffic context but does not clarify the meaning or usage of 'limit' or 'country' beyond what the schema already provides. This is adequate but not compensatory for the missing limit description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: listing the top pages by organic traffic for a domain, with associated keyword and traffic value data. This distinguishes it from sibling tools like organic-keywords or backlinks-stats, though it lacks an explicit verb like 'Get' or 'List' that would make the action more direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence, 'What to study or beat first,' implies a use case for competitive analysis or prioritization, but it does not provide explicit guidance on when to use this tool versus the many sibling tools. It offers a general context without naming alternatives or exclusion criteria, making the guidance only somewhat useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It honestly describes the output fields (domain rating, URL rating, traffic, page type, result type) but does not reveal behaviors like pagination, number of results limit (top_positions), response format, or potential external network calls. It is a read-only operation implied by the description, but lacks richer context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently lists the core purpose and key output fields without unnecessary words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with 3 parameters and no output schema, so the description gives a reasonable overview of the return fields. However, it lacks details on top_positions behavior, country effects, or the structure of the returned data, which is important in absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only country has description). The description adds some meaning by referring to 'keyword' and 'top search results', but it does not explicitly explain the top_positions parameter or how the output is affected by it. It does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Top search results for a keyword' with specific metrics (domain rating, URL rating, traffic, page type, result type). This is a specific verb+resource+scope that distinguishes it from sibling tools like keyword-volume-history or organic-keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (for seeing SERP results with metrics) but provides no explicit when-to-use guidance or mentions alternatives. It does not say when not to use this tool versus siblings like organic-keywords or domain-rating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the nature of the output (real autocomplete suggestions with metrics) but omits details about rate limits, data freshness, or any limitations. It adds some context beyond the schema but not deep behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core value proposition (autocomplete-style suggestions with volume/CPC/intents) and then an illustrative explanation. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description partially covers return values by mentioning volume, CPC, and intents. However, it lacks explicit guidance on the limit parameter and how this tool differs from related-keywords. For a relatively simple tool, it is adequate but leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, covering keyword and country, leaving limit without a description. The description reinforces 'seed keyword' but adds no new parameter-level meaning beyond what the schema already provides. The limit parameter is still inferable from its constraints, but the description does not compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides autocomplete-style search suggestions with volume, CPC, and intents, going beyond the tool name. It distinguishes from likely siblings like related-keywords by emphasizing 'real autocomplete-style' and 'what people actually start typing into Google'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering real user queries around a seed keyword, but it does not explicitly state when to use this over alternatives like related-keywords or keyword-volume-by-country. No direct when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains that results are derived from top-ranking pages and are semantically related rather than literal. However, it does not disclose any aspects like whether results are sorted, whether they include search volume, or any rate limits. It adds some context but leaves significant behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core definition and delivery method. Every word adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with three parameters and no output schema, the description explains the core function and source of the data. It could benefit from mentioning what the output looks like (e.g., a list of related keywords), but it adequately conveys the tool's purpose and basic behavior. The absence of annotations is offset by the straightforward nature of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers two of three parameters with descriptions (keyword and country), leaving 'limit' undocumented. The tool description does not add any parameter-level detail beyond what the schema provides. With 67% schema coverage, the description contributes little extra meaning, but the schema is mostly self-explanatory, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function as surfacing semantically related keywords based on top-ranking pages for a seed keyword. It includes a specific methodology ('top-ranking pages for the seed also rank for') and distinguishes from literal match tools like keyword-suggestions by adding 'beyond literal matches.' This makes the purpose explicit and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you need semantically related, adjacent on-topic terms), but it does not explicitly state when to use this tool versus alternatives like keyword-suggestions. There are no exclusions or explicit 'use when...' guidance, so it's clear but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It accurately conveys that the tool retrieves an organic profile (non-mutating read operation), but it provides no details about data freshness, response format, rate limits, or any other behavioral traits. The description does not contradict any annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Organic profile of a domain') and then provides a concise list of included metrics. It contains no redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two simple parameters and no output schema, the description adequately lists the return metrics (organic traffic, keywords, etc.). It is complete for its simplicity, though it could explicitly note that this represents current rather than historical data, especially given the existence of site-metrics-history.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with clear descriptions ('Domain or URL to analyze' and 'Optional two-letter country code'), so schema coverage is 100%. The description's mention of 'Optionally scoped to one country' slightly reinforces the country parameter, but adds no novel meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('domain') and the specific metrics returned ('organic traffic, ranking keywords, top-3 keywords, traffic value, and paid traffic'), which distinguishes it from siblings like organic-keywords or top-pages. The optional country scoping further differentiates it from site-metrics-by-country.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about what metrics are returned, so an agent can infer when to use it for an organic profile. However, it does not explicitly state when to use this over closely related siblings like site-metrics-history or site-metrics-by-country, and no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the analytical output (trend classification) and temporal scope (monthly history), but does not mention data availability, units, or limitations. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key purpose and trend insight. No redundant words or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters and no output schema, so the description should explain what the user receives. It mentions the high-level trend result but does not describe the actual returned data (e.g., monthly values, units). This is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (months lacks a description). The description does not explain the parameters or add meaning beyond the schema. It fails to compensate for the undocumented 'months' parameter, leaving ambiguity about its role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows monthly organic traffic history for a domain, and explicitly mentions the trend classification (growing, flat, or declining). This distinguishes it from siblings like site-metrics (current metrics) and keyword-volume-history (keyword-focused).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing historical organic traffic trends over months. It provides clear context but does not explicitly mention alternatives or when-not-to-use scenarios, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that results are split by country, but does not specify output format, data source, or any limitations. For a simple read-only tool, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence states the core function, the second adds valuable geographic context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter, but no output schema exists, so the return structure is unspecified. The description explains the basic functionality and purpose but does not describe the response format or any potential edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single 'keyword' parameter and 0% schema description coverage, the description names the keyword context by referencing 'a keyword,' but provides no format, examples, or additional parameter details. It offers minimal added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides search volume broken down by country, with the added insight of 'where the demand actually lives geographically.' This distinguishes it from siblings like keyword-volume-history (time-based) and keyword-metrics (general metrics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The geographic focus implies it's for country-level demand analysis, which differentiates it from sibling tools like keyword-suggestions or serp-overview. However, there is no explicit mention of alternatives or when-not-to-use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the sorting behavior ('ordered by domain rating') and the general output nature (a list of domains). However, it does not mention pagination, limits, rate limits, or the exact structure of the response, which are important for a tool with no output schema. It's adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose. There is no redundant information; every word contributes to the understanding. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two parameters and no output schema. The description covers the core purpose, sorting, and the kind of information returned (referring domains and authority). It lacks detail on response format or limitations, but for a straightforward listing tool, the description is sufficiently complete to guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; the 'target' parameter is described in the schema, while 'limit' is not. The tool description adds context that 'target' is the site being analyzed and that the output is a list of domains, but it does not explicitly explain the 'limit' parameter. The schema's default and max provide some inference, but the description doesn't fully compensate for the missing parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists domains linking to a target and orders them by domain rating. It uses specific language ('Domains linking to a target') and explains the value ('Shows who links to a site and how authoritative they are'), distinguishing it from sibling tools like backlinks-stats which focus on backlink details rather than domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: when you want to identify referring domains and assess their authority. It doesn't explicitly name alternatives or exclusions, but the purpose is self-evident enough to guide selection. The lack of explicit 'use this instead of X' prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. 'Never cached' is a key behavioral trait, indicating that the tool always returns fresh data. It also implicitly suggests the call is lightweight (hence useful before expensive operations). However, it doesn't explicitly state read-only status or response format, but for a simple usage check, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the purpose, and the second provides behavioral and usage context. No unnecessary words, front-loaded with the core purpose. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, this description is nearly complete. It explains the data (current usage vs. plan limit), the freshness guarantee (never cached), and a practical usage scenario. It lacks an explicit response structure, but the description implies 'usage and limit' sufficiently. Given the simplicity, this is a complete and helpful description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage). The description adds meaning by explaining what the returned data represents (usage vs. limit), which goes beyond the schema. Since there are no params to document, the baseline of 4 applies, and the description fully compensates for the lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Current API units usage against the plan limit.' This specifies the exact resource (API units usage) and the comparison (against plan limit), distinguishing it from all sibling tools that focus on keyword or site metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Check before running expensive batches.' This tells the agent when to invoke the tool. While it doesn't explicitly name an alternative to avoid, the guidance is actionable and context-specific. It could be improved by noting that for other usage-related queries, other tools might exist, but no such alternative is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![ahrefs-mcp MCP server](https://glama.ai/mcp/servers/newilu/ahrefs-mcp/badges/card.svg)](https://glama.ai/mcp/servers/newilu/ahrefs-mcp)

Score Badge

Copy to your README.md:

[![ahrefs-mcp MCP server](https://glama.ai/mcp/servers/newilu/ahrefs-mcp/badges/score.svg)](https://glama.ai/mcp/servers/newilu/ahrefs-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/newilu/ahrefs-mcp'

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