Skip to main content
Glama
CFP-102

cfp-seo-agent

domain_overview

Idempotent

Analyze a domain’s organic and paid search footprint, including keyword counts, estimated traffic, traffic value, and ranking distribution.

Instructions

Organic and paid search footprint of a domain: keyword count, estimated traffic, traffic value and ranking distribution (DataForSEO Labs Domain Rank Overview). Returns: JSON with target, organic, paid. SANDBOX (development): returns dummy data, no payment.

Input Schema

NameRequiredDescriptionDefault
domainYesDomain to analyze, e.g. example.com. A pasted URL is reduced to its domain; IP addresses and ports are rejected.
language_codeNoLanguage code such as en or de. Default: English if available for the country, else its first language. Unsupported country/language pairs are refused before payment.
location_codeNoDataForSEO location code. Country level: 2840 = United States (default), 2276 = Germany, 2040 = Austria, 2756 = Switzerland. Google SERP, Maps, News, Images and Local Market Check also accept city/region codes in Germany, Austria and Switzerland (free lookup: GET /api/v1/locations?q=...).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare openWorldHint=true and destructiveHint=false, but the description adds information annotations do not: that this is a paid DataForSEO Labs call, and that in SANDBOX/development it returns dummy data with no payment. That cost/sandbox disclosure is the key behavioral fact an agent needs before invoking. It stops short of stating rate limits or what a sandbox result looks like.

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?

Three compact sentences: what it measures, what it returns, and the sandbox caveat — each front-loaded and each earning its place with no 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?

With no output schema, the description does name the top-level return keys (target, organic, paid), and annotations plus the sandbox note cover the operational picture for a 3-param, one-required call. It leaves the shape of the organic/paid sub-objects and any cost magnitude unstated, a minor gap for a paid query tool.

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

Parameters3/5

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

Schema description coverage is 100%, with domain normalization, default language fallback and location codes already documented in the schema. The description contributes nothing about parameters, so baseline 3 applies.

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?

States a specific resource and scope (organic and paid search footprint of a domain) and enumerates the metrics returned: keyword count, estimated traffic, traffic value, ranking distribution. An agent can tell it is a broad domain-level summary rather than a keyword-level listing, though it never names or contrasts with near neighbors like traffic_estimate, ranked_keywords or competitors.

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 only implied by the phrase 'footprint of a domain' and the metric list; there is no explicit statement of when to choose this over traffic_estimate, competitors or ranked_keywords, nor any exclusion. The DataForSEO Labs attribution hints at a differentiator (aggregated rank data) but the agent must infer it.

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