ask_atlas_council

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

With no annotations provided, the description carries the full behavioral disclosure burden and delivers: the adjudicator default ladder (local codex CLI → atlas:openai/gpt-5.6-sol → Fable), a fallback disclosure ('Falls back to Fable when the pick is unavailable or fails'), result-structure hints (`sources`, `synthesis`, `quorum`/`degraded`), authentication requirements, and the grok-to-local-CLI rerouting. It even flags the refusal scope, so an agent can predict failures before invoking.

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 dense but nearly every clause adds information — routing, defaults, auth, failover, scope. It front-loads the pivotal usage constraint ('reserve it for... not for routine questions'), though it packs a lot into run-on parentheticals that would be easier to parse as shorter sentences.

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 6-parameter, annotation-free tool with no output schema, the description covers the full decision-relevant surface: when to choose it, how invocation behaves (synthesis, sources, fallback), how to set models, what auth is needed, and what is refused. It also names the sibling for mixed-provider councils, giving an agent the complete routing picture. The only minor gap is the meaning of `quorum`/`degraded`, but checking them is already flagged.

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 baseline is 3. The description adds genuine value beyond the schema: a concrete example model-id list, the default composition ('3 featured catalog models, one per provider'), the optional 'atlas:' prefix, and the practical note that synthesizer can override with 'any council token'. These enrich the models and synthesizer semantics rather than merely repeating the schema.

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 names a specific verb-resource pair: 'Ask several Atlas Cloud models the same SOFTWARE/ENGINEERING question at once, then get back one answer the adjudicator synthesizes.' It immediately distinguishes itself from its closest sibling ('the Atlas-only counterpart to ask_council') and states the exact question scope, including what is refused.

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 explicit when-to-use guidance ('reserve it for a contentious or hard-to-reverse decision'), an explicit when-not-to ('not for routine questions (default to ask)'), a hard constraint ('at most one council call per problem'), and names the routing alternative for mixed-provider councils ('Use ask_council instead to mix Atlas models with Fable/MiniMax/GLM/DeepSeek'). This is textbook conditional routing guidance.

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