list_tool_groups

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the output fields (group name, tool count, loading type) and adds useful context about the tool ecosystem, but it does not explicitly state that the operation is read-only, has no side effects, or mention any rate limits or permissions. The verb 'list' implies safety, but given the absence of annotations, a bit more transparency would be expected.

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 a single sentence that is front-loaded with the primary action, then lists the specific output attributes. Every phrase earns its place, including the clarification of 'on-demand' via search_tools + invoke_tool, which is necessary to understand the tool's scope. There is no redundancy or fluff.

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 and no annotations, the description must carry the burden of explaining what the tool returns. It does so by listing the three key pieces of information. It also adds valuable ecosystem context (native vs on-demand), which helps the agent understand tool relationships. The only minor gap is that it does not specify the exact response format (e.g., array of objects) or any ordering, but for a simple list tool this is adequate.

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?

The tool has zero parameters, and the schema coverage is 100% (vacuously). Per the rubric, this sets a baseline of 4. The description adds no parameter information because there are none to explain, which is appropriate. It correctly focuses on the output rather than input.

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 clearly states the tool lists every WebCake tool group with two specific details: number of tools and loading mode (native vs on-demand). It uses the specific verb 'list' and resource 'tool group', and distinguishes itself from sibling tools by focusing on groups and their categories, as opposed to individual tools or content operations.

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 clear context for when to use the tool: to get an overview of all tool groups and their accessibility. It implicitly differentiates from search_tools and invoke_tool by mentioning them as part of the on-demand path, but it does not explicitly state alternatives or exclusions. This is slightly below the 'explicit when-to-use' standard, but the context is still clear.

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