Which integrations are available for this server?

Provides Etsy market intelligence, including deep search across shops, product listings, and market trends, as well as listing performance metrics and sales estimates.

xiaoflow mcp server

by xiaoflow-app

Overview Schema Related Servers Score Discussions

TypeScript

XiaoFlow MCP Server (`xiaoflow-mcp-server`)

xiaoflow-mcp MCP server

Official Model Context Protocol (MCP) server for XiaoFlow AI SEO and keyword intelligence tools.

Connect Large Language Models (LLMs) such as Claude Desktop, Cursor, Windsurf, and VS Code directly to XiaoFlow's search engine optimization, keyword discovery, and domain analytics.

Remote endpoint: https://mcp.xiaoflow.com/mcp

Transport: MCP Streamable HTTP with OAuth 2.1 / PKCE, plus stdio through the npm package

Safety: Read-only research tools, except asynchronous expansion task creation; no destructive tools

Official listings

Related MCP server: korean-keyword-mcp

✨ Features & Capabilities

🔍 Keyword Discovery: Generate high-intent search keywords and SEO ideas from keyword, URL, or domain seeds.
📊 Domain Analytics: Analyze domain-level search performance, organic traffic metrics, and keyword distributions.
📈 Search Trend Analysis: Compare keyword demand, competition, CPC, and historical trends.
🔒 Flexible Authentication: Supports API Key authentication via query parameters (?key=), Bearer tokens, environment variables, or Web OAuth login.

⚡ Quick Start

1. Run via `npx` (stdio)

Run the server directly using npx:

npx -y xiaoflow-mcp-server

Pass your XiaoFlow API key via environment variable:

XIAOFLOW_API_KEY="YOUR_API_KEY" npx -y xiaoflow-mcp-server

Use the canonical remote endpoint in clients that support remote MCP. The client discovers XiaoFlow OAuth automatically and opens the browser for login and consent:

https://mcp.xiaoflow.com/mcp

Legacy clients can still use https://mcp.xiaoflow.com/sse?key=YOUR_API_KEY.

💻 Client Integration Guides

Cursor Setup

Add XiaoFlow MCP to Cursor:

Name: xiaoflow
Type: http
URL: https://mcp.xiaoflow.com/mcp

Or click Add to Cursor directly on the XiaoFlow MCP Portal.

Claude Desktop Setup

Add the following entry to your claude_desktop_config.json:

{
  "mcpServers": {
    "xiaoflow": {
      "command": "npx",
      "args": ["-y", "xiaoflow-mcp-server"],
      "env": {
        "XIAOFLOW_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

Windsurf, VS Code, and other remote clients

Use native HTTP configuration where available:

{
  "mcpServers": {
    "xiaoflow": {
      "type": "http",
      "url": "https://mcp.xiaoflow.com/mcp"
    }
  }
}

For stdio-only clients, bridge to the OAuth-enabled remote endpoint:

{
  "mcpServers": {
    "xiaoflow": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.xiaoflow.com/mcp"]
    }
  }
}

🛠️ Available MCP Tools

MCP Tool	Description	Key Input Parameters
`get_keyword_metrics`	Exact metrics and monthly history for one keyword	`keyword`, `history_months` (1–48), `location`, `language`
`get_related_keywords`	Related keywords with metrics/history and unlimited pagination	`seed`, `history_months`, `page`, `page_size` (max 1,000)
`bulk_keyword_metrics`	Exact metrics/history for up to 1,000 keywords	`keywords`, `history_months`, `location`, `language`
`start_keyword_expansion`	Start round-based expansion from one or more seeds	`seeds`, `max_iterations`, include/exclude rules
`get_keyword_expansion_status`	Poll an expansion task and retrieve results	`task_id`, `include_results`
`analyze_url`	Analyze page or domain search visibility	`url`, `site`, `brand`, `location`, `language`
`get_domain_stats`	Overview search metrics & traffic trends for a domain	`domain`, `brand` (required: `0`=domain, `1`=brand)
`list_domain_keywords`	Retrieve paginated list of domain keywords	`domain`, `brand`, `page`, `page_size`
`get_keyword_details`	Retrieve keyword metrics for a 12, 24, or 48 month window	`slug`, `time_range`, `location`, `language`
`discover_keywords`	Backward-compatible related keyword discovery	`keyword`, `url`, `site`, `location`, `language`
`bulk_keyword_lookup`	Backward-compatible bulk metrics lookup	`keywords`, `location`, `language`

Legacy aliases remain available for backward compatibility.

Every tool publishes:

descriptions for every input parameter;
a named JSON output schema, including success and error fields;
MCP safety annotations (readOnlyHint, destructiveHint, idempotentHint, and openWorldHint);
a human-readable tool title for MCP clients and directories.

Example prompts

Get US English metrics and 24 months of history for "AI SEO tools".

Find every related keyword for "standing desk", 200 per page, and continue
until has_more is false. Return search volume, CPC, competition, intent, and history.

Compare these 1,000 keywords over 48 months and rank them by search volume growth.

Expand "home office" for four rounds, keep terms with at least 100 monthly
searches, and poll the task until it is complete.

🔑 Authentication

Obtain your API key from the XiaoFlow MCP Dashboard.

Supported authentication methods:

Web Login OAuth (recommended): connect to https://mcp.xiaoflow.com/mcp; compatible clients discover OAuth, PKCE, and dynamic client registration automatically.
Environment Variable: set XIAOFLOW_API_KEY when running via npx.
Authorization Header: send Authorization: Bearer YOUR_API_KEY.
Legacy Query Parameter: append ?key=YOUR_API_KEY to the legacy SSE URL.

🐳 Docker / Glama

The repository includes a production multi-stage Dockerfile for directory build verification and stdio deployment:

docker build -t xiaoflow-mcp .
docker run --rm -i \
  -e XIAOFLOW_API_KEY="YOUR_API_KEY" \
  xiaoflow-mcp

The image runs as the unprivileged Node user, excludes local secrets and build state, and writes MCP protocol messages only to stdout.

🔐 Security and data handling

OAuth login occurs only on www.xiaoflow.com; MCP clients never receive your password.
API keys and OAuth tokens are sent only to the configured XiaoFlow API endpoint.
The server does not scan or upload project files.
Tool calls query external XiaoFlow/Google Ads-backed data and may consume account credits.
No tool deletes or modifies keyword or domain data.

Report vulnerabilities privately through the repository owner or the XiaoFlow contact page. Do not include tokens or customer data in public issues.

✅ Quality and compatibility

MCP protocol: Streamable HTTP and stdio
Authentication: OAuth 2.1 with PKCE, Bearer API key
Tool schemas: parameter descriptions, structured output schemas, annotations
Optional discovery methods: resources and prompts return valid empty lists
Runtime: Node.js 18+ (node:20-alpine in Docker)
Continuous endpoint: https://mcp.xiaoflow.com/mcp

📄 License

MIT © XiaoFlow

Available Tools

11 tools

analyze_urlAnalyze URL or SiteA

Read-onlyIdempotent

Domain/site keyword discovery via /api/v1/websites (requires brand=0|1). Use site for full domain mapping; use url for a single page via /api/v1/keywords.

ParametersJSON Schema

Name	Required	Description
`url`	No	Single page URL (uses /api/v1/keywords).
`site`	No	Domain for /api/v1/websites discovery.
`brand`	No	0=domain keywords, 1=brand keywords (required with site).
`language`	No	Language ID or code.
`location`	No	Geo ID or ISO.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No	Domain metrics, trends, or keyword records.
`page`	No	Current one-based page.
`error`	No	Human-readable error when success is false.
`total`	No	Total matching domain keywords.
`domain`	No	Normalized domain name.
`success`	Yes	Whether the request completed successfully.
`has_more`	No	Whether another page is available.

TDQS

A3.6/5.0

Behavior3/5

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

Description adds API endpoints and the brand requirement, but behavioral traits like read-only, idempotent are already covered by annotations. No additional context about rate limits or auth.

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?

Single sentence, concise and front-loaded with purpose. Could benefit from bullet points for clarity, but no wasted words.

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 comprehensive annotations and output schema, description is reasonably complete. It explains the two modes and a key dependency. Minor gaps like output format are covered by output schema.

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 has 100% coverage, but description adds valuable constraints: 'brand' required with 'site', and 'site' vs 'url' are mutually exclusive. This goes beyond schema descriptions.

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?

Description specifies 'domain/site keyword discovery' with two modes (site and url), making the purpose clear. However, it does not explicitly distinguish from sibling tools like 'discover_keywords' which may overlap.

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?

Provides guidance on when to use 'site' vs 'url' and notes that 'brand' is required with 'site'. But no explicit when-not-to-use or comparison to sibling tools.

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

bulk_keyword_lookupBulk Keyword Lookup (Legacy)A

Read-onlyIdempotent

Bulk volume/CPC for up to 1,000 keywords.

ParametersJSON Schema

Name	Required	Description
`keywords`	Yes	List of keywords to analyze.
`language`	No	Google Ads language ID or language code, for example 1000 or en.
`location`	No	Google Ads geo target ID or ISO country code, for example 2840 or US.

Output Schema

ParametersJSON Schema

Name	Required	Description
`code`	No	Stable machine-readable error code.
`data`	No	Keyword results.
`page`	No	Current one-based page.
`error`	No	Human-readable error when success is false.
`total`	No	Total known matching results.
`success`	Yes	Whether the request completed successfully.
`has_more`	No	Whether another result page is available.
`next_page`	No	Next page number, or null when complete.

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the key behavioral detail of a maximum 1,000 keyword batch and that it returns volume/CPC. This goes beyond annotations, but doesn't mention other behaviors like rate limits or authentication.

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 extremely concise—a single phrase. It is front-loaded with the key information. Could be expanded slightly to include more context without losing conciseness, but overall it is efficient.

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 3 parameters, 1 required, and an output schema (exists but not shown), the description covers the essential behavioral constraints (batch limit) and core output (volume/CPC). Annotations handle safety. No major gaps for a simple lookup 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%, so the schema fully documents all three parameters. The description adds no additional parameter-level information beyond the tool's overall function. Baseline 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 specifies the tool returns 'volume/CPC' for up to 1,000 keywords, which is a clear verb+resource. However, it could be more explicit about what 'volume/CPC' means (e.g., search volume and cost per click). The title also indicates it's legacy, which adds context.

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 like 'bulk_keyword_metrics' or 'get_keyword_metrics'. There are 10 sibling tools, but the description does not help an agent select this one.

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

bulk_keyword_metricsGet Bulk Keyword MetricsA

Read-onlyIdempotent

Get exact-match base metrics and 1-48 months of history for up to 1,000 keywords.

ParametersJSON Schema

Name	Required	Description
`keywords`	Yes	Keywords to analyze; accepts up to 1,000 unique phrases.
`language`	No	Google Ads language ID or language code, for example 1000 or en.
`location`	No	Google Ads geo target ID or ISO country code, for example 2840 or US.
`history_months`	No	Number of monthly history points to return, from 1 through 48.

Output Schema

ParametersJSON Schema

Name	Required	Description
`code`	No	Stable machine-readable error code.
`data`	No	Keyword results.
`page`	No	Current one-based page.
`error`	No	Human-readable error when success is false.
`total`	No	Total known matching results.
`success`	Yes	Whether the request completed successfully.
`has_more`	No	Whether another result page is available.
`next_page`	No	Next page number, or null when complete.

TDQS

A4/5.0

Behavior4/5

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

Description adds context about exact-match metrics and history beyond annotations (readOnlyHint, idempotentHint). No contradictions. Could detail response format but output schema exists.

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?

Single sentence with no wasted words. Key constraints are front-loaded.

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 output schema present, the description covers purpose and constraints adequately. Could mention sibling differentiation but not critical for completeness.

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 the description adds no new parameter information beyond the schema. Baseline score 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 clearly states the action ('Get'), resource ('exact-match base metrics and history'), and constraints (up to 1,000 keywords, 1-48 months). It distinguishes from siblings by implying bulk processing and historical data.

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?

No explicit guidance on when to use vs alternatives like get_keyword_metrics or bulk_keyword_lookup. Usage is implied by the tool name and description but lacks direct differentiation.

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

discover_keywordsDiscover Keywords (Legacy)A

Read-onlyIdempotent

Legacy alias for related keyword discovery. Returns paginated keyword metrics and monthly history.

ParametersJSON Schema

Name	Required	Description
`url`	No	Page URL seed.
`site`	No	Root domain seed.
`keyword`	No	Primary keyword seed.
`language`	No	Language ID or code (e.g. 1000 or en).
`location`	No	Geo ID or ISO (e.g. 2840 or US).

Output Schema

ParametersJSON Schema

Name	Required	Description
`code`	No	Stable machine-readable error code.
`data`	No	Keyword results.
`page`	No	Current one-based page.
`error`	No	Human-readable error when success is false.
`total`	No	Total known matching results.
`success`	Yes	Whether the request completed successfully.
`has_more`	No	Whether another result page is available.
`next_page`	No	Next page number, or null when complete.

TDQS

A4/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds that it returns 'paginated keyword metrics and monthly history', consistent with annotations and adding value about pagination.

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?

Single concise sentence that states legacy alias, returns paginated keyword metrics and monthly history. No wasted words.

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 5 optional parameters, rich annotations, and output schema exists, the description is adequate. It explains core function and output behavior without needing to detail return values.

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 coverage is 100% with clear parameter descriptions. Description does not add meaning beyond schema, so baseline 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?

Clearly states it is a legacy tool for related keyword discovery, using specific verb 'discover' and resource 'keywords'. Distinguishes from siblings like get_related_keywords by explicitly being a legacy alias.

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?

Mentions 'Legacy' suggesting it might be for backward compatibility, but does not explicitly state when to use this versus siblings like get_related_keywords or start_keyword_expansion.

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

get_domain_statsGet Domain StatisticsA

Read-onlyIdempotent

Website overview metrics and traffic history. GET /api/v1/websites/:domain?brand=0|1

ParametersJSON Schema

Name	Required	Description
`brand`	Yes	0=domain overview, 1=brand overview.
`domain`	Yes	Domain (e.g. example.com).
`language`	No	Language ID or code.
`location`	No	Geo ID or ISO.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No	Domain metrics, trends, or keyword records.
`page`	No	Current one-based page.
`error`	No	Human-readable error when success is false.
`total`	No	Total matching domain keywords.
`domain`	No	Normalized domain name.
`success`	Yes	Whether the request completed successfully.
`has_more`	No	Whether another page is available.

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds that it is a GET request and returns metrics/traffic history, but does not disclose any additional behavioral traits (e.g., rate limiting, data freshness, 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.

Conciseness5/5

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

The description is extremely concise (one sentence plus endpoint) and front-loaded with the most important information. Every word adds value; there is no fluff.

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 the tool has 4 parameters, an output schema, and rich annotations, the description provides a high-level overview but lacks detail on the specific metrics returned or the role of optional parameters (language, location). It is adequate but not comprehensive.

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 the baseline is 3. The description mentions 'brand=0|1' and the URL pattern, which reinforces the schema, but does not add new semantic meaning beyond what is in the schema descriptions.

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 'Website overview metrics and traffic history' and includes the REST endpoint, which distinguishes it from sibling tools focused on keywords (e.g., get_keyword_metrics, discover_keywords). It specifies the action (get domain statistics) and the resource (domain).

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 retrieving domain overview and traffic data, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., if you need keyword data vs. site metrics). No when-not 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.

get_keyword_detailsGet Keyword DetailsA

Read-onlyIdempotent

Historical volume for a keyword slug.

ParametersJSON Schema

Name	Required	Description
`slug`	Yes	URL-safe keyword slug returned by a XiaoFlow keyword result.
`language`	No	Google Ads language ID or language code, for example 1000 or en.
`location`	No	Google Ads geo target ID or ISO country code, for example 2840 or US.
`time_range`	No	Historical window to return: 12m, 24m, or 48m.

Output Schema

ParametersJSON Schema

Name	Required	Description
`code`	No	Stable machine-readable error code.
`data`	No	Keyword results.
`page`	No	Current one-based page.
`error`	No	Human-readable error when success is false.
`total`	No	Total known matching results.
`success`	Yes	Whether the request completed successfully.
`has_more`	No	Whether another result page is available.
`next_page`	No	Next page number, or null when complete.

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, which tell the agent this is a safe, idempotent read operation. The description adds minimal behavioral context (returns historical volume) but does not contradict annotations.

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, front-loaded sentence with no wasted words. However, it is very brief and could include a bit more context without compromising 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?

Given the presence of an output schema (not shown) and full parameter descriptions, the description is minimally sufficient for a simple lookup tool. It does not cover usage context but is adequate for the tool's simplicity.

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 100% schema coverage, the input schema already describes all parameters. The description adds no additional parameter semantics beyond what is in 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 'Historical volume for a keyword slug.' specifies the verb (get/retrieve) and the resource (historical volume for a specific keyword slug). It clearly distinguishes from sibling tools like discover_keywords or get_related_keywords which have different purposes.

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 when historical volume for a specific keyword slug is needed, but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. The sibling list is given but not leveraged in the description.

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

get_keyword_expansion_statusGet Keyword Expansion StatusA

Read-onlyIdempotent

Poll a round-based expansion task and optionally return its results.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes	Numeric task identifier returned by start_keyword_expansion.
`include_results`	No	When true, include accumulated expansion results with task status.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Task or request failure description.
`status`	Yes	queued, running, completed, or failed.
`results`	No	Accumulated keyword results when requested.
`success`	Yes	Whether task status was retrieved.
`task_id`	Yes	Expansion task identifier.
`progress`	No	Completion percentage from 0 to 100.

TDQS

A4.1/5.0

Behavior4/5

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

The annotations already declare read-only, idempotent, and non-destructive behavior. The description adds 'round-based' and 'optionally return its results', which provides additional behavioral context beyond the annotations.

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, front-loaded sentence with no waste. It could be slightly expanded with usage guidance, but it is appropriately concise.

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 description covers the essential action and optional behavior. With annotations and an existing output schema, it is sufficiently complete for a polling 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 coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema for parameters; it merely restates the polling and optional result inclusion.

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 action ('Poll') and the resource ('a round-based expansion task'), which distinguishes it from sibling tools like start_keyword_expansion that initiate tasks.

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 that this tool is used after starting an expansion task, providing clear context for its usage. It does not explicitly state when not to use it or name alternatives, but the sibling list provides enough differentiation.

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

get_keyword_metricsGet Keyword MetricsA

Read-onlyIdempotent

Get exact-match base metrics and 1-48 months of monthly history for one keyword.

ParametersJSON Schema

Name	Required	Description
`keyword`	Yes	Exact keyword or seed phrase to research.
`language`	No	Google Ads language ID or language code, for example 1000 or en.
`location`	No	Google Ads geo target ID or ISO country code, for example 2840 or US.
`history_months`	No	Number of monthly history points to return, from 1 through 48.

Output Schema

ParametersJSON Schema

Name	Required	Description
`code`	No	Stable machine-readable error code.
`data`	No	Keyword results.
`page`	No	Current one-based page.
`error`	No	Human-readable error when success is false.
`total`	No	Total known matching results.
`success`	Yes	Whether the request completed successfully.
`has_more`	No	Whether another result page is available.
`next_page`	No	Next page number, or null when complete.

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds context about returning base metrics and history but does not contradict annotations.

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 conveys the tool's purpose with no superfluous words.

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 an existing output schema, the description adequately explains the input and purpose. It could mention the return structure but is sufficient given the output schema.

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 parameter details are already documented. The description adds minimal extra 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 the tool retrieves exact-match base metrics and monthly history for one keyword, distinguishing it from bulk or related 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 single-keyword use but does not explicitly state when to use this tool versus siblings like bulk_keyword_metrics or discover_keywords.

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

get_related_keywordsGet Related KeywordsA

Read-onlyIdempotent

Get all related keywords for a seed with metrics/history. Paginate until has_more=false; no total-result cap.

ParametersJSON Schema

Name	Required	Description
`page`	No	One-based result page number.
`seed`	Yes	Seed keyword used to discover related search terms.
`force`	No	When true, request a live refresh instead of relying only on cached data.
`language`	No	Google Ads language ID or language code, for example 1000 or en.
`location`	No	Google Ads geo target ID or ISO country code, for example 2840 or US.
`page_size`	No	Number of results per page; maximum 1,000.
`history_months`	No	Number of monthly history points to return, from 1 through 48.

Output Schema

ParametersJSON Schema

Name	Required	Description
`code`	No	Stable machine-readable error code.
`data`	No	Keyword results.
`page`	No	Current one-based page.
`error`	No	Human-readable error when success is false.
`total`	No	Total known matching results.
`success`	Yes	Whether the request completed successfully.
`has_more`	No	Whether another result page is available.
`next_page`	No	Next page number, or null when complete.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavior about pagination and the lack of a result cap, which goes beyond annotations.

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 concise sentences, front-loaded with the core purpose, and no unnecessary words. Every sentence adds value.

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 tool with 7 parameters, a full output schema, and rich annotations, the description is sufficient. It explains the pagination behavior, though it could briefly mention what 'metrics/history' entails.

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 the schema adequately describes all 7 parameters. The description adds no additional parameter 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?

Description clearly states 'Get all related keywords for a seed with metrics/history', using a specific verb and resource. It distinguishes from sibling tools like discover_keywords and get_keyword_metrics by emphasizing related keywords with metrics/history.

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?

Description provides pagination instructions ('Paginate until has_more=false; no total-result cap'), which helps the agent use the tool correctly. However, it does not explicitly compare with alternatives or state 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.

list_domain_keywordsList Domain KeywordsA

Read-onlyIdempotent

Paginated keyword list for a domain. GET /api/v1/websites/:domain/keywords?brand=0|1

ParametersJSON Schema

Name	Required	Description
`page`	No	One-based result page number.
`brand`	Yes	Set to 0 for domain data or 1 for brand-focused data.
`domain`	Yes	Normalized domain name without a path, for example example.com.
`language`	No	Google Ads language ID or language code, for example 1000 or en.
`location`	No	Google Ads geo target ID or ISO country code, for example 2840 or US.
`page_size`	No	Number of results per page; maximum 1,000.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No	Domain metrics, trends, or keyword records.
`page`	No	Current one-based page.
`error`	No	Human-readable error when success is false.
`total`	No	Total matching domain keywords.
`domain`	No	Normalized domain name.
`success`	Yes	Whether the request completed successfully.
`has_more`	No	Whether another page is available.

TDQS

A3.6/5.0

Behavior3/5

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

The description adds pagination and the GET method, which aligns with readOnlyHint. However, beyond this, it does not disclose additional behavioral traits such as result ordering or rate limits.

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 plus endpoint, front-loading the main purpose with no unnecessary words.

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 annotations, 100% schema coverage, and presence of output schema, the description is sufficiently complete for a paginated list tool, though it could briefly mention filtering options.

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 the description does not need to add parameter details. It only provides a hint about the brand parameter via the endpoint string, which is already in 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 it returns a paginated keyword list for a domain, and includes the endpoint. However, it does not explicitly differentiate from sibling tools like get_keyword_details or discover_keywords.

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 listing domain keywords, but provides no when-to-use or when-not-to-use guidance, nor mentions alternatives.

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

start_keyword_expansionStart Keyword ExpansionB

Start an asynchronous breadth-first/round-based keyword expansion.

ParametersJSON Schema

Name	Required	Description
`seeds`	Yes	One to 20 seed keywords used as expansion starting points.
`language_id`	No	Google Ads numeric language ID; 1000 represents English.
`location_id`	No	Google Ads numeric geo target ID; 2840 represents the United States.
`exclude_rules`	No	Optional text rules; matching results are removed.
`include_rules`	No	Optional text rules; results must match at least one supplied rule.
`max_iterations`	No	Maximum breadth-first expansion rounds, from 1 through 10.
`min_search_volume`	No	Exclude discovered keywords below this monthly search volume.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Human-readable error when task creation fails.
`status`	No	Initial task status.
`success`	Yes	Whether the task was accepted.
`task_id`	No	Task identifier used for polling.

TDQS

B3.1/5.0

Behavior3/5

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

The description adds 'asynchronous' and 'breadth-first/round-based' which clarify behavior beyond annotations. However, it does not disclose whether the process is cancellable, how long it takes, or that it returns an expansion ID. With annotations already covering read/write hints, this is a moderate addition.

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 sentence that is concise and front-loaded with the key characteristic 'asynchronous'. It is efficient but could include a bit more detail without losing conciseness.

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?

Given that this is an asynchronous tool with 7 parameters, the description is incomplete. It does not mention the return value (likely an expansion ID), how to check status, or any caveats about the asynchronous process. Although an output schema exists, the agent still needs to know what to expect. Score is low.

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 describes all 7 parameters with descriptive names and brief descriptions. The tool description does not add any additional context or examples for parameters like include_rules or exclude_rules. Score is baseline 3 as schema coverage is 100%.

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 that the tool starts an asynchronous breadth-first/round-based keyword expansion, which distinguishes it from synchronous sibling tools. However, it does not mention the return value or how to obtain results.

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 provided on when to use this tool versus siblings such as get_related_keywords or discover_keywords. The description lacks context for selection.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

11 tool updatesv0.1.0Jul 24, 2026
- First observedanalyze_url
- First observedbulk_keyword_lookup
- First observedbulk_keyword_metrics
- First observeddiscover_keywords
- First observedget_domain_stats
- First observedget_keyword_details
- First observedget_keyword_expansion_status
- First observedget_keyword_metrics
- First observedget_related_keywords
- First observedlist_domain_keywords
- First observedstart_keyword_expansion

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation4/5

Tools are mostly distinct, but discover_keywords is a legacy alias for related keyword discovery, overlapping with get_related_keywords. Also, bulk_keyword_metrics and get_keyword_metrics serve similar purposes at different scales, causing slight ambiguity.

Naming Consistency3/5

Naming follows snake_case with verb_noun mostly, but analyze_url deviates from the pattern of having 'keyword' in the name. Additionally, there is inconsistency between 'bulk' and 'get' prefixes for similar operations.

Tool Count5/5

11 tools is well-scoped for a keyword research server, covering discovery, metrics, bulk operations, expansion, and domain analysis without being overwhelming.

Completeness4/5

The tool set covers major keyword research workflows: discovery, metrics, bulk operations, expansion, and domain analysis. Minor gaps exist, such as keyword trend data or comparison tools, but core needs are addressed.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

SEO Trends MCP
ai.trendsmcp
Spot keyword demand rising or fading. Trend volume and growth signals. Free key at trendsmcp.ai
Marketing Search
237
UbersuggestOAuth
com.neilpatelapi
Ubersuggest SEO tools: keyword research, competitor analysis, backlinks, site audits and more.
Marketing Search
2
Google Trends MCP
ai.trendsmcp
Google Trends: Search, Images, News, Shopping over time, growth metrics. Free key at trendsmcp.ai
Search Web Scraping Marketing
2
EzBiz SEO & Marketing Analysis A
com.ezbizservices
AI-powered SEO and marketing: keyword research, SERP analysis, and content optimization tools.
Marketing Search Web Scraping
2

Related MCP Servers

DataForSEO MCP Server
Marketing Search
facundozupel
F
license
Not graded
quality
D
maintenance
Enables professional SEO/SEM research with geolocalized keyword discovery, competitor analysis, and SERP ranking insights using DataForSEO API.
Updated 7 months ago (2026-02-04 03:22 UTC)
-
korean-keyword-mcp
Marketing Research & Data
Whitening-Sinabro
A
license
Not graded
quality
D
maintenance
Enables Korean keyword niche analysis using Naver SearchAd API data for CPC, competition, and search volume, with tools for expansion, scoring, and trend discovery.
Updated 7 months ago (2026-02-21 12:43 UTC)
24
MIT
keyword-research
Br0ski777
A
license
Not graded
quality
B
maintenance
Enables SEO keyword research with Google Suggest, intent classification, long-tail discovery, and related queries, with pay-per-call via x402 micropayments.
Updated 4 days ago (2026-09-02 19:56 UTC)
MIT
mcp-seo-keywords
Marketing Search
pipeworx-io
A
license
Not graded
quality
C
maintenance
Provides search volume and keyword difficulty data via DataForSEO Labs, enabling AI agents to perform SEO keyword research through natural language queries.
Updated 11 days ago (2026-08-26 17:40 UTC)
14
MIT

Appeared in Searches

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/xiaoflow-app/xiaoflow-mcp'

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

XiaoFlow MCP Server (xiaoflow-mcp-server)

Official listings

✨ Features & Capabilities

⚡ Quick Start

1. Run via npx (stdio)

2. Connect via Streamable HTTP with web login (recommended)

💻 Client Integration Guides

Cursor Setup

Claude Desktop Setup

Windsurf, VS Code, and other remote clients

🛠️ Available MCP Tools

Example prompts

🔑 Authentication

🐳 Docker / Glama

🔐 Security and data handling

✅ Quality and compatibility

📄 License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

XiaoFlow MCP Server (`xiaoflow-mcp-server`)

1. Run via `npx` (stdio)