redreplier

Add Keywords

add_keywords

Add keywords to a monitored website, automatically activating up to the plan's free headroom and marking the rest as pending for later activation.

Instructions

Add keywords to a monitored website. Values are trimmed, lowercased, and de-duplicated; ones already ACTIVE on that site are skipped, and re-adding a DISABLED one resets it to PENDING (prefer enable_keyword). Each new keyword starts PENDING, then as many as fit the plan's free headroom flip to ACTIVE at once, with no charge. The rest stay PENDING and match nothing until activate_pending_keywords, which may charge an upgrade; run preview_activate_pending first. Adding is unlimited. Use edit_keyword to reword an existing keyword. Returns the whole website with its updated keyword list, not only the new keywords.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`keywords`	Yes	Keywords to add (e.g. ["my product", "competitor name"]); trimmed, lowercased, and de-duplicated, max 255 characters each
`websiteId`	Yes	Monitored website ID (UUID)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	No	The whole website with its full keyword list (id, value, status), including the new keywords as ACTIVE or PENDING.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.1Sep 7, 2026

changedInput schema / properties / keywords / description

Previous value: -"Keywords to add (e.g. [\"my product\", \"competitor name\"])"New value: +"Keywords to add (e.g. [\"my product\", \"competitor name\"]); trimmed, lowercased, and de-duplicated, max 255 characters each"

changedOutput schema / properties / result / description

Previous value: -"The added keywords with their IDs and resulting statuses (ACTIVE or PENDING)."New value: +"The whole website with its full keyword list (id, value, status), including the new keywords as ACTIVE or PENDING."

First observedv0.1.0Sep 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description thoroughly discloses side effects: trimming/lowercasing/dedup, skipping existing active keywords, resetting disabled ones to pending, activation limited by headroom, no charge for initial activation, and the return of the full updated website. It also notes that later activation may incur charges. This goes well beyond the annotations (readOnlyHint false, destructiveHint false) and gives a complete behavioral model.

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 informative but remains focused, covering all key points in a single paragraph. It uses semicolons effectively and includes necessary digressions about alternative tools and charge implications. It is slightly longer than strictly necessary but avoids redundancy and stays well-organized.

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?

The description fully addresses the tool's complexity, including state transitions, activation headroom, billing implications, and the output format. It also references related tools (enable_keyword, preview_activate_pending) to place the operation in the broader workflow. No important aspect is missing for an agent to use the tool correctly.

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?

The schema already provides full coverage of parameters (keywords array with constraints, websiteId UUID). The description adds behavioral semantics beyond the schema, such as how existing keywords are handled (skip active, reset disabled) and the activation logic, enriching the understanding of parameter effects. Though it doesn't introduce new parameter details, the added behavior context justifies above-baseline scoring.

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 ('Add keywords to a monitored website') and specifies the resource. It also distinguishes from edit_keyword and mentions the preferred alternative enable_keyword for re-adding disabled keywords, making the tool's unique purpose unambiguous.

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?

The description gives explicit guidance on when to use this tool versus alternatives: it points out that re-adding disabled keywords should prefer enable_keyword, and advises running preview_activate_pending before activation. It also clarifies that adding is unlimited and explains the activation flow, providing sufficient context for tool selection.

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