analytics_reallocationRecommends budget reallocations that equalize marginal ROAS at the same total spend. Use it to plan advisory campaign budget shifts without writing changes.
Advisory budget reallocation equalizing marginal ROAS at the same total; never writes (POST /v1/analytics/reallocation).
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description usefully reinforces the annotations by declaring the tool 'advisory' and 'never writes', which resolves the confusion of a POST endpoint that is actually read-only. Beyond that it says nothing about what the response contains, how the marginal-ROAS equalization is constrained, or what the minFactor/maxFactor bounds do to results.
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?
A single front-loaded sentence with the key qualifier ('advisory', 'same total') up front and the endpoint appended as reference. Dense with jargon like 'marginal ROAS' but nothing is wasted or redundant.
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 tool whose only input is a large nested object with zero documented fields and no output schema, a one-line description is far from sufficient to invoke it correctly. An agent cannot determine valid date ranges, budget units, or the meaning of the factor bounds from the provided text.
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 0% on a deeply nested body with from/to dates, clientId, platform, campaignId, crossCampaignId, currency, min/maxFactor and a totalDailyBudget micros object. The description supplies no parameter meaning whatsoever, leaving an agent to guess date semantics, currency format, and budget units.
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 resource and operation: advisory budget reallocation that equalizes marginal ROAS while holding total spend constant. That is distinguishable from the other analytics_* siblings (breakdown, pacing, forecast, synergy, saturation), though no sibling is named explicitly.
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?
There is no guidance on when to choose this over analytics_forecast or analytics_saturation, no stated prerequisites (e.g., that it needs a date range and a total budget), and no note on whether the caller should follow up by actually applying changes elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.