Skip to main content
Glama

Add Keywords to a Niche's Master Keyword List

add_niche_keywords
Destructive

Use this to add keywords to a niche's Master Keyword List (MKL): the user's own search terms, or keywords from the niche's Outliers or Residue lists.

Instructions

Use this to add keywords to a niche's Master Keyword List (MKL): the user's own search terms, or keywords from the niche's Outliers or Residue lists. Free while the niche is fresh (dived in the last 24 hours, or a dive is running): the first call adds the keywords at once and they are readable with get_niche_keywords. On a stale niche, any keyword new to the niche makes the add re-dive the whole niche with its current competitors, which spends one Dive token per competitor. The first call then saves and spends nothing and returns confirmation_required with tokenCost; after the user approves, call again with confirm: true and maxTokensUsed set to that tokenCost. Keywords moved in from Outliers or Residue never cost anything. Returns originBreakdown (alreadyInMkl, takenFromOutliers, takenFromResidue, addedManually) and tokensUsed. When refresh is present a re-dive is running: poll get_dive_status with refresh.diveId; the addedManually keywords show in the MKL once it succeeds. A confirmed call is not safe to retry: if it errors or times out, poll get_dive_status or re-read get_niche_keywords instead of re-calling. Limited to 2 calls per minute per niche, so batch keywords into one call. Undo with remove_niche_keywords. A keyword hidden by the niche's keyword exclusions stays hidden after an add: check list_keyword_exclusions and remove the exclusion with remove_keyword_exclusions first.

Input Schema

NameRequiredDescriptionDefault
confirmNoLeave unset on the first call. Set to true only after the user approved the Dive token cost from a `confirmation_required` response — it lets the add re-dive a stale niche.
nicheIdYesThe niche whose Master Keyword List to add to. Get one from `list_niches`.
keywordsYesThe keywords to add, 1–100 per call, at most 255 characters each. They are lower-cased and trimmed, and must be unique after that. Put every keyword in one call: this tool allows only 2 calls per minute per niche.
maxTokensUsedNoWith `confirm: true`: the `tokenCost` the user approved. The call then fails with nothing saved or charged rather than spend more. Ignored without `confirm`, where the tool never spends anything.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.17.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only say destructiveHint=true/readOnlyHint=false; the description goes far beyond by disclosing token spend rules (free while fresh, one Dive token per competitor when stale), the confirmation_required flow, the 2-calls-per-minute rate limit, non-retryability of confirmed calls, and the hidden-exclusion gotcha. This is an unusually rich behavioral contract.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The content is dense and useful but structured as one very long paragraph mixing purpose, cost model, confirmation flow, return values, rate limits, undo, and exclusions. Front-loading is decent (purpose first) but an agent must parse a wall of text to extract call sequencing.

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?

Given a mutation tool with real side-effect costs, no output schema, and a non-trivial multi-step flow, the description covers everything needed: token cost, confirmation handshake, return shape (originBreakdown, tokensUsed), polling via get_dive_status, and recovery on failure. Nothing essential is missing.

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 adds some behavioral meaning to confirm and maxTokensUsed (approval-driven re-dive) but largely restates what the schema already documents for all four parameters.

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 opens with a precise verb+resource+scope: 'add keywords to a niche's Master Keyword List (MKL)', and immediately names the three sources (user's own terms, Outliers, Residue). This distinguishes it clearly from siblings like remove_niche_keywords and add_keyword_exclusions.

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?

Explicit routing: use this for adding to MKL, undo with remove_niche_keywords; check list_keyword_exclusions and remove exclusions first if a keyword stays hidden. Also tells the agent when a re-dive will be triggered and how to handle the confirmation flow.

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