Semrush Domain Metrics MCP Server

Get Semrush domain metrics

get_semrush_domain_metrics

Read-onlyIdempotent

Retrieve public Semrush metrics for domains, including Authority Score, traffic, backlinks, rankings, competitors, and keywords. Check domain performance when a public Semrush page exists.

Instructions

Look up domains on Semrush's public website pages. Returns one row per domain with Authority Score, visits, organic and paid traffic, backlinks, rank, competitors, and keywords. Reads run 20 seconds apart. Semrush has a public page for some domains only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_semrush_domain_metrics"
  }
}

Input Schema

Name	Required	Description
`domains`	No	Domains or URLs to look up, such as stripe.com. Semrush publishes a page for some domains only: in a test of 30, 15 had one.
`max_domains`	No	Text number from 1 to 1000. Default 100. Reads run 20 seconds apart, so 100 domains take about 33 minutes. Set the run timeout to fit.
`max_charge_usd`	No	Optional. The run stops before a charge that would pass this amount. Summary rows are always returned.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, open-world, non-destructive behavior, so the description earns credit for what it adds: the ~20-second read pacing (a hard throughput constraint) and the partial-coverage caveat that some domains simply have no page. It stops short of saying what a result looks like for a domain with no page (omitted row vs. empty row), which leaves a real gap.

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

Conciseness4/5

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

Four short sentences, front-loaded with purpose and return shape, then constraints. Efficient overall, though the rate-limit and coverage facts are repeated verbatim in the schema, which is mild redundancy rather than waste.

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 three-parameter, read-only tool with no output schema, the description supplies purpose, returned fields, pacing, and coverage limits, which is nearly everything an agent needs. The one missing piece is outcome semantics for domains without a public page, which matters because the coverage caveat is prominent.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters are already documented, including the 20-second pacing, the max_domains default and timeout advice, and the max_charge_usd cutoff. The description restates the rate limit and coverage caveat but adds no new parameter meaning. Baseline 3 applies.

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 gives a specific verb and resource ("Look up domains on Semrush's public website pages") and then enumerates the exact output fields: Authority Score, visits, organic/paid traffic, backlinks, rank, competitors, keywords. There are no siblings to disambiguate from, and the scope is unambiguous.

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?

Usage is implied rather than stated: the tool is for pulling Semrush metrics on a set of domains. The description adds a real eligibility constraint ("Semrush has a public page for some domains only"), but gives no explicit when-not-to-use guidance and no alternatives since none exist. It is adequate but not instructional.

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

Deploy Server

Other Tools

get_semrush_domain_metricsA