Skip to main content
Glama

MisarSEO MCP Server

by io.github.Misar-AI
OverviewDiscussionsAdmin

find_serp_competitors

Compares domains competing in search results for a supplied keyword set. Useful for market and search-intelligence reports; not radius-based local SEO. The inverse of get_keyword_gap, which asks what one competitor ranks for that we do not. CHARGES CREDITS ON THE PAID DATA PROVIDER, which is also the only one that honours resultTypes and includeSubdomains and that measures visibility, etv and rating. On the default free provider competitors are aggregated from one live SERP per keyword: NOTHING IS CHARGED, only ORGANIC results are counted whatever resultTypes says, includeSubdomains is ignored, and visibility/traffic-estimate/rating are left unmeasured. Sorting never treats an unmeasured field as zero: rows the provider did not measure sort last and are reported in unmeasuredForSort. If that count equals the row count, the list is NOT ranked by anything — say so instead of presenting the first row as the strongest competitor. Omit locationCode/languageCode to use the project's default market.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum competitors to return (1-100). Defaults to 50.
offsetNoRows to skip for pagination.
sortByNoSort order for returned competitors. Defaults to visibility. Only `keyword_count` and `avg_position` are measured on every provider — `visibility` and `traffic_estimate` are unmeasured on the free provider, and rows without the chosen field sort last rather than as zero. Prefer `keyword_count` when you need an order that always means something.
keywordsYesKeywords whose SERPs are compared (1-100).
projectIdYesRequired. The MisarSEO project ID to scope this call to. Get one from list_projects.
resultTypesNoSERP result types to include. Defaults to organic and local_pack.
languageCodeNoLanguage code (e.g. 'en', 'es', 'fr'). Omit it to use the project's default market language, which falls back to 'en'.
locationCodeNoDataForSEO location code. Omit it to use the project's default market, which falls back to 2840 (United States) for a project that has not set one. See dataforseo.com/help-center/locations. Some countries (e.g. Iceland, 2352) are served from Google Ads data: keyword volume/CPC/trends work, but keyword difficulty, search intent, and domain analytics are unavailable.
excludeDomainsNoDomains to exclude from results (e.g. the user's own site).
includeSubdomainsNoCount subdomains as part of the same competitor domain.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover only the generic safety profile (readOnlyHint=false, idempotentHint=false), so the description carries real weight here and delivers: credit charges on the paid provider, the free provider aggregating one live SERP per keyword, resultTypes/includeSubdomains being ignored on the free tier, and the critical 'unmeasured sorts last, not zero' behaviour with the unmeasuredForSort field. This is exactly the context annotations cannot provide.

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 text is dense and long, but front-loaded with the purpose before the caveats, and nearly every clause conveys a distinct operational fact. The credits/provider material is slightly repetitive in phrasing, which keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, no-output-schema tool with only generic annotations, the description supplies the missing pieces: cost model, provider-dependent semantics, sorting pitfall, and a warning not to present an unranked list as ranked. Nothing an agent needs before calling it is absent.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning the schema does not: which parameters only the paid provider honours (resultTypes, includeSubdomains) and that omitting locationCode/languageCode falls back to the project default market. It stops short of explaining excludeDomains or the limit/offset relationship, keeping it at a 4.

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 states a specific verb and resource ('compares domains competing in search results for a supplied keyword set') and explicitly distinguishes itself from the sibling get_keyword_gap, which it calls 'the inverse'. An agent can pick this tool over its neighbours without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names the intended use case (market and search-intelligence reports), an explicit exclusion ('not radius-based local SEO'), and the alternative tool plus the question that should route to it instead. This is about as complete as routing guidance gets.

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

All MisarSEO MCP Server toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources