rc_get_chart

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It honestly characterizes the action as 'Query' and describes the output, but it does not disclose authentication needs, rate limits, default behavior when optional parameters are omitted, or handling of invalid chart/filter/segment combinations.

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?

The core purpose is front-loaded in the first sentence, and the second sentence adds the return shape. The long chart enumeration is justified because it defines the valid chart_name values in one place. No filler or redundancy.

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 6 parameters and no output schea, the description gives a useful high-level summary but stops short of tool-level completeness. It does not specify the exact response structure beyond 'dates and values', nor does it clarify parameter interdependencies, such as which charts require filters, segments, or a date range, or what the default date window is.

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?

The input schea covers 100% of parameters with explicit descriptions, so the baseline is 3. The description adds no extra meaning to filters, segment, resolution, or dates; the chart list merely repeats the existing enum. The useful reference to rc_get_chart_options is already in the schea, not the description.

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 'Query time-series chart data from RevenueCat' with a specific verb and resource, enumerates all 21 available charts, and mentions the return shape ('data points with dates and values'). This clearly distinguishes it from siblings like rc_get_overview, rc_compare_periods, and rc_get_chart_options.

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?

No guidance on when to prefer this tool over alternatives or when not to use it. The only cross-reference, 'use rc_get_chart_options to discover available segments', appears in the schema for segment, not in the description, and addresses parameter discovery rather than tool selection.

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