redreplier

Preview Keyword Billing

preview_keyword_billing

Read-only

Check the pricing plan and monthly cost for any target number of active keywords before making changes. Use this what-if calculator to avoid unexpected charges when adding or enabling keywords.

Instructions

Preview the plan and price needed for a chosen total of active keywords, without changing anything. desiredKeywordCount is the absolute number of keywords you want live across the account, not the number being added: count the ACTIVE keywords from list_websites and add the new ones. Returns the same shape as preview_activate_pending (currentPlanName, targetPlanName, targetMonthlyPrice, immediateCharge, isUpgrade, isDowngrade, requiresImmediatePayment). Use this for what-if pricing before add_keywords or enable_keyword; use preview_activate_pending instead for the exact cost of activating the keywords already PENDING, which it counts for you.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`desiredKeywordCount`	Yes	Total ACTIVE keywords wanted across the account after the change (absolute count, not an increment)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	No	Billing preview for that keyword count, same shape as preview_activate_pending: target plan, monthly price, prorated immediateCharge, isUpgrade, isDowngrade.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.1Sep 7, 2026

changedInput schema / properties / desiredKeywordCount / description

Previous value: -"Total number of active keywords you want"New value: +"Total ACTIVE keywords wanted across the account after the change (absolute count, not an increment)"

changedOutput schema / properties / result / description

Previous value: -"The plan and price required for the desired number of active keywords."New value: +"Billing preview for that keyword count, same shape as preview_activate_pending: target plan, monthly price, prorated immediateCharge, isUpgrade, isDowngrade."

First observedv0.1.0Sep 7, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'without changing anything.' It adds value by specifying the exact return shape (same as preview_activate_pending) and clarifying the parameter semantics. This goes beyond the annotation baseline but doesn't introduce new behavioral caveats, so a 4 is appropriate.

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

Conciseness5/5

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

Every sentence serves a purpose: the first states the core function, the second clarifies the parameter, the third lists the return fields, and the last gives usage guidance. Information is front-loaded, and there is no redundancy or fluff.

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?

For a tool with a single parameter, a clear schema, an output schema, and annotations covering safety, the description fully equips the agent: it explains the parameter's meaning, the return shape, and when to use it vs. the alternative. Nothing needed for correct invocation is missing.

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 a clear description of desiredKeywordCount (absolute count, not increment). The tool description adds an operational hint: 'count the ACTIVE keywords from list_websites and add the new ones.' This provides practical guidance beyond the schema, but since schema coverage is 100%, the baseline is 3; the extra example lifts it to 4.

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 tool's purpose: preview the plan and price for a chosen total of active keywords without modifying anything. It uses a specific verb (preview) and resource (keyword billing) and explicitly distinguishes itself from the sibling preview_activate_pending, making it easy to identify the right tool.

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?

It explicitly states when to use this tool ('for what-if pricing before add_keywords or enable_keyword') and when to use an alternative ('use preview_activate_pending instead for the exact cost of activating the keywords already PENDING'). This direct routing to a sibling tool eliminates ambiguity.

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