ask_glm

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

No annotations are provided, so the description carries the full burden. It discloses single-turn behavior, the backend model and fallback behavior (GLM-5.2 via Z.ai when the key is set, otherwise Atlas-hosted GLM-5.3), not_configured reporting, and the refusal policy for offensive-security and non-software domains. This is strong behavioral disclosure beyond what a name or schema alone would convey.

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 core purpose is front-loaded and the description is well organized, but the backend/endpoint sentence is more implementation detail than an agent strictly needs for selection or invocation. Still, every sentence serves a real purpose given the configuration, refusal, and alternative-routing details it covers.

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?

Given there is no output schema, the description still provides the essential information needed to call the tool correctly: what to ask, how to provide context, what is refused, and which sibling tools to use instead. It leaves the exact return shape implicit and does not explicitly distinguish ask_glm from every model-specific sibling, but these are minor gaps.

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 adds value by instructing users to include a snippet or file path in context for questions about existing code and by clarifying that broad/conceptual engineering questions are acceptable. It does not add much on context_ref beyond what the schema already documents.

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 starts with a specific verb-resource-scope statement: 'Ask the GLM model — on its own, independent of Fable — to reason about the SOFTWARE/ENGINEERING work you're doing.' It enumerates concrete topics such as code structure, data/control flow, architecture, and design trade-offs. It also distinguishes itself from siblings by explicitly saying 'Use ask for Fable, ask_m3 for MiniMax, or ask_council.'

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 explicitly states when the tool is appropriate: software/engineering reasoning, broad conceptual questions, and existing-code questions with a snippet or file path in context. It names alternatives directly — ask for Fable, ask_m3 for MiniMax, ask_council for synthesized multi-model answers — and establishes exclusions such as offensive-security asks and non-software domain knowledge.

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