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

Annotations provide minimal signal (all false beyond readOnly). The description carries the full burden and delivers richly: it discloses partial-update behavior, version creation for specific fields, continuation of the score series, the new tracker id in the response, version_created timing, list replacement semantics, and a cost-quoting hint (cost_per_survey_minor). This is comprehensive behavioral disclosure that goes well beyond what annotations convey.

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 sentences, no filler. The main point (partial update) is front-loaded, followed by the versioning nuance and list replacement. Every sentence earns its place, and the structure flows logically from core behavior to edge cases.

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?

Given the tool's complexity (13 params, versioning rules, cost calculations) and no output schema, the description explains the critical behavioral consequences (version creation, list replacement, cost quoting) that the schema alone doesn't convey. It doesn't explicitly state prerequisites like needing list_trackers first, but that appears in the schema's tracker_id description. The description is thorough for the behavior an agent must handle to call this safely; a small gap is not explicitly contrasting when to use update_tracker vs. create_tracker, but that's more a usage-guideline aspect.

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%, so the baseline is 3 per the rubric. The description itself does not add parameter-level semantics beyond what the schema already provides, but the schema descriptions are detailed (e.g., engines pricing, discovery behavior, next_survey_at constraints). The description focuses on overall behavior rather than individual params, which is appropriate when the schema is fully covered.

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 opens with a precise verb and resource: 'Update the configuration of a tracker,' and immediately clarifies the partial-update semantics ('only the fields you send change'). It clearly distinguishes this from sibling tools like create_tracker or pause_tracker by focusing on configuration mutation, and the versioning behavior adds specificity that separates it from simpler updates.

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 gives clear context: it's for updating an existing tracker, with partial-update semantics and special handling for version-triggering fields. However, it doesn't explicitly name alternatives (e.g., 'use create_tracker for a new tracker') or state when not to use this tool. The context is clear but lacks explicit exclusion routing, which is the only gap separating it from a 5.

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