configure_ollama_council

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

With no annotations provided, the description carries the full disclosure burden and does so admirably. It states the side effect (writes to config file), precedence behavior (overrides ASK_FABLE_OLLAMA_* env defaults), persistence scope (across sessions), input normalization ('ollama:' prefix optional, bare names normalized to ':cloud'), and the return value (saved config and file path). This fully informs an agent of the persistent-mutation nature of the call.

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 every sentence earns its place: purpose, parameter details, normalization rule, optional parameter, user-confirmation workflow, and return value. It front-loads the primary purpose before diving into specifics, and the structure follows a logical flow from what it does to how to use it to what it returns.

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 config-persistence tool with no annotations and no output schema, the description covers everything an agent needs: preconditions (confirm with user, call list_ollama_models), side effects (config file write, env override), parameter semantics, normalization behavior, and return value (config file path). No critical operational detail is left implicit.

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. The description's parameter explanations largely restate the schema text (list of cloud model ids, normalization, default_model for ask_ollama). It does add a concrete example array and ties the parameters to downstream tool behavior, but it doesn't significantly extend semantic understanding beyond what the schema already provides.

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, actionable purpose: 'Save the user's chosen Ollama Cloud council so it sticks across sessions.' It names the exact resource (Ollama Cloud council), the mechanism (written to ask_fable's config file), and the effect (persists, overrides env defaults). It also clearly distinguishes itself from sibling configure_atlas_council and configure_openrouter_council by scoping to Ollama Cloud while referencing the dependent ask_ollama_council and ask_ollama tools.

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 provides explicit operational guidance: confirm with the user first and call list_ollama_models to ground the selection in available models. It also explains how the parameters map to downstream tools (ask_ollama_council, full tier, ask_ollama). It stops short of explicitly stating when not to use this tool versus the config alternatives, but the Ollama Cloud naming and list_ollama_models call make the intended context clear.

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