add_tracked_keywords
Add up to 1000 keywords to a tracked app row (one country). A free account can track five keywords. Rank data is filled in after the keywords are saved.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| terms | Yes | ||
| trackedAppId | Yes |
Add up to 1000 keywords to a tracked app row (one country). A free account can track five keywords. Rank data is filled in after the keywords are saved.
| Name | Required | Description | Default |
|---|---|---|---|
| terms | Yes | ||
| trackedAppId | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add real behavioral context: a hard cap of 1000 keywords, a free-account cap of five, and the fact that rank data is populated asynchronously after saving. It omits auth/permission requirements and duplicate-keyword handling, so it falls short of complete disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, no filler, with the resource and scope front-loaded and the async behavior noted last where it is least critical for invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the important operational facts: volume limits, the free-tier quota, and delayed rank data. The missing prerequisite that the tracked app row must exist is the main gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and both parameters are required, so the description must compensate. It explains the 'up to 1000' bound on terms and clarifies that trackedAppId refers to a single-country row, but it doesn't explain term format, uniqueness, or validation beyond what the schema's maxLength already encodes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Add') and resource ('keywords to a tracked app row'), plus scope constraints (one country, up to 1000). It is distinguishable from sibling add_tracked_app, though it never explicitly contrasts itself with the app-creation tool it depends on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies context via 'tracked app row (one country)' and free-account quota, but it never says when to use this versus add_tracked_app or get_tracked_keywords, nor states the prerequisite that the tracked app row must already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.