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

readOnlyHint=true already establishes the safe-read profile, and the description adds useful detail about the payload shape (members, each with app_url, plus app_url and latest runs). However it discloses nothing about missing studies, name-vs-id mismatch behavior, or result size limits, so it adds only moderate value beyond the annotation.

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?

Two tight sentences with the return payload front-loaded after the verb, no filler. The phrasing 'the project a quote's `study` named' is slightly contorted but still compact and information-dense.

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, the description appropriately summarizes the return shape (study, members, app_url), and both optional params are covered by the schema. Missing only edge-case behavior (unknown name/id, mutual-exclusion precedence), which is a minor gap for a simple read tool.

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 params are optional, so the schema already documents them. The description adds that `name` must be the exact name given to mcg_quote/mcg_stage and frames the two as alternatives, which is mild extra meaning but not a full explanation of precedence when both are supplied.

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 verb (Fetch) and resource (study), and enumerates what it returns: member simulations and their latest runs. It also ties the resource back to mcg_quote/mcg_stage ('the project a quote's `study` named'), which helps an agent recognize the domain object, though it does not explicitly distinguish itself from siblings like mcg_get_run or mcg_list_runs.

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?

Gives parameter-level advice ('Pass study_id or the exact name') but no when-to-use/when-not guidance relative to alternatives such as mcg_get_run or mcg_list_runs. Usage is implied by the link to the study named in mcg_quote/mcg_stage rather than stated as a selection rule.

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