Skip to main content
Glama
Sign In
DataDive MCP

DataDive MCP

Official
by Data-Dive-Tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get the Outlier Keywords of a Niche

get_niche_outlier_keywords
Read-only

Retrieve high-volume niche keywords that few competitors rank for but fall outside the Master Keyword List, with search volume, competitor ranks, and suggested bids.

Instructions

Use this when the user asks about a niche's Outliers: high search volume keywords that only a few of the niche's competitors rank for, so they fall outside the Master Keyword List (get_niche_keywords). For each keyword, returns search volume, relevancy, competitor ASIN organic ranks (asinRanks: { ASIN -> rank | null }) and the exact-match suggestedBid (min / max / median in cents; null when not yet fetched for the latest dive), plus latestResearchDate and pagination metadata (currentPage, pageSize, total, lastPage, hasNext, hasPrev). A page holds at most 100 keywords; keep requesting the next page while hasNext is true. To move a keyword into the Master Keyword List, use add_niche_keywords.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "nicheId": "<nicheId>"
    },
    "name": "get_niche_outlier_keywords"
  }
}

Input Schema

NameRequiredDescriptionDefault
nicheIdYesThe unique identifier of the Niche (from `list_niches`).
pageSizeNoKeywords per page (max 100). Defaults to 20.
currentPageNoPage number, 1-indexed. Defaults to 1.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.21.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, but the description goes well beyond that: it enumerates returned fields, explains that `suggestedBid` is exact-match with min/max/median in cents and null when not yet fetched for the latest dive, and discloses the 100-keyword page cap with a hasNext-driven paging loop. These are operational details an agent could not infer from the annotation.

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?

Front-loaded with the trigger condition and the definition of an Outlier before any return-shape detail, and each sentence carries information (scope, return fields, paging rule, sibling routing). The return-field inventory is dense and slightly list-like, but nothing is redundant with the schema.

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?

There is no output schema, so the description carries the burden of describing returns and does so thoroughly: field list, asinRanks map shape with null ranks, bid units and null semantics, plus `latestResearchDate` and full pagination metadata. For a read-only, three-parameter listing tool, an agent has everything needed to call and iterate it correctly.

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 `nicheId`, `pageSize`, and `currentPage` are already documented, including the 100 max and 1-indexed default. The description adds only the pagination loop behavior ('keep requesting the next page while `hasNext` is true'), which is useful but does not enrich individual 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?

States a specific verb and resource ('Get the Outlier Keywords of a Niche') and defines the resource precisely: high search volume keywords that only a few of the niche's competitors rank for. It explicitly contrasts this set with the Master Keyword List returned by `get_niche_keywords`, so an agent can distinguish the two without opening either 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?

Opens with an explicit trigger ('Use this when the user asks about a niche's Outliers') and names the sibling that covers the complementary case (`get_niche_keywords` for the Master Keyword List). It also routes the follow-up action ('To move a keyword into the Master Keyword List, use `add_niche_keywords`'), giving both selection and next-step guidance.

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