Update rank tracking schedule

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

Annotations only declare the generic mutation profile (readOnly=false, openWorld=true, idempotent=false, destructive=false); the description goes well beyond them by disclosing that enabling can cause future credit-consuming runs, that the change is persistent report state, and that MCP admission units are distinct from provider credits. It also warns that returned report data is untrusted content, a behavioral trait no annotation conveys.

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?

Purpose and cost/state warnings are front-loaded in the first three sentences, which is the right ordering for a mutation tool. The trailing balance-reporting and get_balance instructions are response-handling rules that add length, but they are actionable rather than filler.

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?

With no output schema and only four annotations, the description carries the burden well: it explains cost impact, persistence, untrusted return content, and that the response includes balance. It is slightly incomplete on the scheduleDays semantics and on what happens when isRecurring is set to false while scheduleDays is present.

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 description coverage is only 33% — reportId is documented in the schema (with the useful 'MCP reportId, not provider report ID' note) while isRecurring and scheduleDays carry no descriptions at all. The description partially compensates by implying an interval is required when enabling, but never explains scheduleDays' unit or meaning or what value disables the schedule.

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?

The description uses specific verbs (enable, change, stop) against a precise resource (provider-managed recurring tracking for an owned report), so an agent knows exactly what state is being mutated. It does not, however, name or contrast itself with the sibling create_rank_tracking_report, which is the tool an agent might confuse it with when setting up recurring tracking.

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?

It gives a clear conditional trigger ('Enabling requires an explicit interval') and a gating instruction ('use only when requested'), which steers the agent away from unsolicited calls. What is missing is explicit routing to alternatives, e.g. that creating recurring tracking for a new report belongs to create_rank_tracking_report rather than this update tool.

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