Adopt Model Into Study

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

Annotations only flag it as non-read-only, non-destructive, non-idempotent and open-world; the description goes far beyond by detailing the dry-run preview contents, the exact report shape, the 201/409 outcomes, that nothing is written without confirm, that adoption never refits, and that the run sits outside the attempt budget.

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?

Front-loads the purpose, which is good, but the body is a dense run-on sentence with nested braces, semicolons and parenthetical issue codes that is hard to parse on a single read; every clause carries information, yet the structure could be split for scannability.

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?

An output schema exists, yet the description still supplies return details (201 {run, revision}, report fields, 409 conditions) plus the legacy/pre-snapshot edge case. It is near-complete for a mutation tool, with the unexplained 'reason' parameter the main remaining gap.

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%, so the description must compensate: confirm is thoroughly explained (default false, preview semantics) and study_id/model_hash are implied by the surrounding narrative, but the required 'reason' parameter is never mentioned at all, leaving one of four parameters undocumented.

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+resource ('Import an owned completed model into a study as an executable, editable recipe') and immediately distinguishes itself from sibling write tools like create_study_recipe/create_recipe_draft by describing what it actually produces.

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?

Clearly frames the two modes (preview without confirm vs. actual creation with confirm=true) and the 409 preconditions (model not complete, already attached). It names get_recipe_revision_authoring/create_recipe_draft as the follow-on editing path, but never explicitly says when to prefer this over create_study_recipe.

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