Skip to main content
Glama

Get the Residue Keywords of a Niche

get_niche_residue_keywords
Read-only

Retrieve a niche's residue keywords—terms excluded from both its Master Keyword List and Outliers—with search volume, relevancy, ASIN ranks, suggested bids, and pagination.

Instructions

Use this when the user asks about a niche's Residue: the niche's keywords that are in neither the Master Keyword List (get_niche_keywords) nor the Outliers (get_niche_outlier_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_residue_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
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is known. The description still adds meaningful behavioral context beyond annotations: the per-keyword payload fields, the `asinRanks` map with null ranks, the meaning of null `suggestedBid` (not yet fetched for the latest dive), and pagination termination via `hasNext`. This is strong disclosure for a read tool, though it stops short of describing ordering of returned keywords.

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 front-loaded with the trigger and definition, then the return payload, then pagination guidance, then the alternative routing. It is dense but nearly every clause earns its place; the long single sentence carrying the return shape is slightly harder to scan than a short bulleted breakdown would be.

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 must explain return values, and it does: search volume, relevancy, competitor ASIN organic ranks with null semantics, suggestedBid min/max/median in cents with null meaning, latestResearchDate, and pagination fields. Combined with the schema-covered parameters and the readOnly annotation, an agent has everything needed to call this correctly and page through results.

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 description coverage is 100%, so the baseline is 3. The description adds meaning for `pageSize` and `currentPage` by stating that a page holds at most 100 keywords and that the agent should keep requesting the next page while `hasNext` is true, which goes beyond the schema's static defaults. It does not elaborate on `nicheId` beyond what the schema already says.

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 Residue Keywords of a Niche') and defines Residue precisely as keywords in neither the Master Keyword List nor the Outliers, explicitly naming the sibling tools that cover those other sets. An agent can distinguish this from get_niche_keywords and get_niche_outlier_keywords 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?

Gives an explicit trigger ('Use this when the user asks about a niche's Residue'), names the two alternative tool families for the surrounding keyword sets, and provides a next-step routing rule ('To move a keyword into the Master Keyword List, use add_niche_keywords'). When-to-use, when-not-to-use, and alternatives are all covered.

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