Skip to main content
Glama

Wincher MCP by usefulapi

Add keywords to track

wincher_add_keywords
Destructive

WRITE: start tracking up to 50 new keywords on ONE website. EACH keyword uses one keyword slot of the plan's keyword quota (see wincher_get_account), and it is tracked and updated from then on; this tool cannot remove keywords again. Each keyword may name a preferred_url (the landing page expected to rank). Invalid or already-tracked keywords are ignored by Wincher (not created). 'groups' are keyword group NAMES to put every keyword in (may be empty; use names from wincher_list_groups, an unknown name may create a new group). POST /websites/{website_id}/keywords/bulk.

Input Schema

NameRequiredDescriptionDefault
groupsNoKeyword group names to assign to all of these keywords (default none).
keywordsYes1-50 keywords to add (each uses one keyword slot).
website_idYesWincher website id (from wincher_list_websites).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: each keyword permanently consumes one quota slot, the action cannot be reversed ('this tool cannot remove keywords again'), invalid or already-tracked keywords are silently ignored rather than erroring, and an unknown group name may silently create a new group. These side effects matter far more than the destructiveHint/idempotentHint flags already present.

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?

A single dense paragraph, front-loaded with the operation class and limits, followed by quota, irreversibility, and edge-case semantics in descending order of importance. It is long but nearly every clause carries information; the trailing 'POST /websites/{website_id}/keywords/bulk' is the only borderline filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, the description covers quota cost, irreversibility, duplicate handling, and group side effects. The remaining gap is what the call reports back (e.g., which keywords were actually created vs ignored), which matters precisely because invalid entries are silently dropped.

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?

With 100% schema coverage the baseline is 3, but the description adds real meaning: preferred_url is glossed as 'the landing page expected to rank', groups are clarified as NAMES (may be empty) whose unknown values create new groups, and the 50-keyword/one-slot economics is spelled out.

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?

Opens with a specific verb+resource+scope: 'WRITE: start tracking up to 50 new keywords on ONE website.' That distinguishes it immediately from read siblings like wincher_list_keywords and wincher_get_keyword, and the 'WRITE' marker signals the operation class up front.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the context for use (begin tracking, consumes quota, cannot be undone) and routes to wincher_get_account for quota and wincher_list_groups for valid group names. It stops short of an explicit 'do not use this to re-track or update existing keywords' exclusion, so it is clear context without full when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.