growth_route

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

With no annotations, the description carries the full burden and does disclose the key behaviors: no auth parameter is needed because the editor's logged-in account is used, and a project window must be open. It also enumerates the status vocabulary (done/in_progress/locked) and notes that the top tier pays out in rights rather than cash. Pagination and error behavior are unstated, which keeps it below a 5.

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?

Dense but mostly load-bearing: since no output schema exists, describing the return shape (level, reward, status, goal, current/target, rights) is necessary, and the worked example 「绑定「灵感」上线 0/3 个作品」 pins down progress semantics. The parenthetical level enumeration (新手特效师、潜力特效师……大师特效师) is decorative and could be trimmed.

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 read tool with no annotations and no output schema, the description covers the return structure thoroughly, names the account source, and disambiguates against tasks_list. It omits what happens when no window is open and any error or empty-state behavior, but nothing essential for a correct call is missing.

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 100% and both parameters (instance_id, project_path) are already documented as mutually exclusive and omittable when exactly one window is open. The description's line 任意一个工程窗口开着即可 corroborates that but adds no new syntax or selection detail. Baseline 3 is appropriate when the schema does the work.

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 clearly states the resource: the current account's effect-artist level plus every level's cash reward, status (done/in_progress/locked), goals with current/target progress, and the rights granted at the top tier. It is not verb-first (it opens with the feature name 「成长之路」), but an agent can still tell it apart from tasks_list, which the description explicitly names as the sibling for per-task growth content.

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 concrete precondition (any project window open is sufficient; the editor's logged-in account is used) and explicitly routes the agent to tasks_list with kind=growth for the task-center items that carry reference projects and tutorials. There is no explicit when-not case, but the split between this tool and tasks_list is stated plainly.

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