Connect AI agents to SEO and social media data via MCP to explore keywords, understand competitors and backlinks, monitor AI search visibility, and uncover growth opportunities across platforms such as X, Reddit, Zhihu, and Xiaohongshu.
Scored across 2 tools
The two tools are clearly separated by domain: SEO research versus social research. Misselection risk is low, but each tool bundles submit and get behavior under one name, and both are broad research entry points that require careful reading to use correctly.
Both tool names follow the same predictable snake_case pattern: research_<domain>_signals. There is no mixed convention or inconsistent verb style.
Only two tools are provided for two broad research domains, and each is heavily overloaded with submit/get semantics plus many operation variants. The count feels thin rather than excessive, but each tool does earn its place.
The server covers submission and retrieval of SEO and social research analyses, but lacks list, status, cancel, and delete operations. Agents cannot discover existing analyses or manage the full lifecycle, though the core research capabilities are broad.
Submit or retrieve one bounded SEO research analysis. On submit, provide the natural-language goal plus keyword, domain or target, market and language business scope and an explicit non-empty data_scopes list containing only the smallest evidence families required by the user's goal. Use target for backlink, ranked-keyword, or traffic research when the target is a domain, webpage, or subdomain. Those three target-only scopes are opt-in: do not infer them from a generic SEO audit, website analysis, competitor analysis, or growth-opportunity request; ask for clarification when ambiguous. For a domain-level AI-search score with benchmark and citation evidence, use geo_score alone, omit keyword, and use the fixed US/en scope. On get, provide only analysis_id. Read quality warnings from top-level limitations; the results view preserves the same warnings. For keyword_overview, search_volume and monthly_searches are approximate Google Ads estimates for the requested market/language. The monthly series contains up to the available past 12 months: do not fill missing months, recompute or re-round returned integers, or merge synonym/core-keyword volumes. CPC and bid values are USD. Inspect data.freshness per field family: search volume is stale after 60 days, search intent after 90 days, and backlinks after 30 days; SERP freshness is evaluated separately at 7 days. items[].captured_at is null for an aggregate record without one snapshot event; use each freshness object's observed_at and underlying updated timestamp instead. Use field_semantics_version and field_semantic_paths with the authenticated field-semantics endpoint for the versioned metric definitions. The service selects internal SEO capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | ||
| scope | No | ||
| action | Yes | ||
| dataset | No | ||
| refresh | No | ||
| request | No | ||
| page_size | No | ||
| analysis_id | No | ||
| analysis_ids | No | ||
| result_cursor | No | ||
| research_depth | No | standard |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden and does so: it discloses where quality warnings appear (top-level limitations, preserved in results view), per-family freshness thresholds (60/90/30 days, SERP 7 days), that captured_at is null for aggregate records, that monthly series hold at most 12 months and must not be filled or re-rounded, and that CPC/bid values are USD.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The most decision-relevant content (submit vs get, scope rules) is front-loaded and nearly every sentence carries operational detail. It is a dense wall of prose, however, and a few clauses such as "The results view preserves the same warnings" and "The service selects internal SEO capabilities" add little for the reader.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter, annotation-free tool with an output schema, the description covers the decision logic that matters — scope composition, opt-in gates, geo_score special case, freshness interpretation, and numeric handling — so an agent can call it correctly without guessing. Only the peripheral parameters remain unexplained, which the output schema and defaults largely absorb.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description meaningfully documents only action, scope members (goal, keyword, domain/target, market, language, data_scopes), and analysis_id. The remaining parameters — view, dataset, refresh, request, page_size, analysis_ids, result_cursor, research_depth — are left entirely undefined in both schema and prose, so the compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names both operations and the resource precisely: "Submit or retrieve one bounded SEO research analysis." The SEO resource plus the explicit submit/get duality makes it unmistakable against the sibling research_social_signals, and it immediately states the required inputs for each mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit routing rules: target-only scopes (backlink, ranked-keyword, traffic) are opt-in and must not be inferred from a generic SEO audit, website analysis, competitor analysis, or growth-opportunity request, with an instruction to ask for clarification when ambiguous. It also states a narrow special case (geo_score alone, omit keyword, fixed US/en) and that get requires only analysis_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit or retrieve one bounded social-research analysis. On submit, provide the user's natural-language request and only the explicitly requested public sources: X, Reddit, Xiaohongshu, Zhihu, or Threads. Optional structured search intent and source-specific constraints are mapped by the service; do not provide native platform operators. For X, search_scope may be auto, recent, or full_archive; use full_archive only with a bounded time range. For entity retrieval, use operation post_detail with X post_ids, user_account_post for a Xiaohongshu profile plus one bounded page, or user_posts for one bounded page of a Xiaohongshu user's posts. Zhihu detail, answer-list, hot-list, recommendation, preset-search, and Xiaohongshu suggestion resources use their named operation and business target fields, then read dataset social_resources. On get, provide only analysis_id. The service returns actual coverage without exposing internals.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | ||
| scope | No | ||
| action | Yes | ||
| search | No | ||
| target | No | ||
| dataset | No | ||
| refresh | No | ||
| request | No | ||
| operation | No | topic_search | |
| page_size | No | ||
| analysis_id | No | ||
| max_results | No | ||
| analysis_ids | No | ||
| result_budget | No | ||
| result_cursor | No | ||
| research_depth | No | standard | |
| result_page_size | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose useful behavior: bounded analysis, explicit source selection, full_archive requiring a bounded time range, and actual coverage being returned. However, it does not cover authentication, rate limits, idempotency, asynchronous submit behavior, or what happens when unsupported sources are requested.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded, starting with the core submit/get purpose before covering operation-specific details. It is appropriately sized for a 17-parameter tool, though its single-paragraph structure makes the many operation rules harder to scan than a structured list would.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return-value explanation is not required, and the description covers the main submit/get workflows and several operation mappings. For a complex 17-parameter tool with 0% schema description coverage and no annotations, it still omits enough parameter and behavioral detail that an agent may need to infer usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains core parameters such as action, request, scope platforms, search_scope, operation, target post_ids/share_url, dataset, and analysis_id, but leaves several important parameters unexplained, including view, refresh, max_results, analysis_ids, result_budget, result_cursor, research_depth, and page sizing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb pair and resource: submit or retrieve a bounded social-research analysis. It clearly separates the submit and get actions, but does not explicitly distinguish this tool from the sibling research_seo_signals tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete usage guidance for submit versus get, including source restrictions, avoiding native platform operators, search_scope behavior for X, and operation selection for entity retrieval. It lacks an explicit statement of when to choose this tool over the sibling research_seo_signals tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
research_seo_signalsresearch_social_signals
Add one secure layer between your agents and this server.