list_atlas_models

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses read-only behavior, no auth needed, free/no tokens charged, native popup side effects, a structured fallback, and the no-network refresh=false behavior. This is strong behavioral disclosure for a tool with zero annotation support.

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 description is long and dense, but almost every clause earns its place because there is no output schema and no annotations to fall back on. It front-loads the core purpose and workflow before the return-format detail. Stylistically it is a bit overloaded with all-caps emphasis, which keeps it from a 5.

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 tool with no output schema and no annotations, this description is exceptionally complete: it covers return payload shape, cost/auth implications, task ranking, interactive behavior, fallback handling, and the next tool to call. Nothing critical for an agent to use it correctly 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 coverage is 100%, so the baseline is 3. The description adds extra practical meaning by explaining that `task` drives ranking, that native elicitation is tied to `interactive`, and that `refresh=false` means no network. It doesn't radically expand on the schema, but it does connect parameters to real usage scenarios.

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 specific verb+resource pair ('RECOMMEND AND PICK an Atlas Cloud text model') and clearly explains the ranking, picker, and catalog-listing behaviors. It differentiates from siblings by scoping to Atlas and explicitly pointing to ask_atlas for the follow-up accept action.

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 an explicit trigger: 'REACH FOR THIS the first time an Atlas model is wanted' and explains when a task should be passed. It also routes the follow-up to ask_atlas, but it does not explicitly mention exclusions for the sibling Ollama/OpenRouter model-list tools, so the when-not-to-use guidance is only implicit.

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