LAWMADI

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

Annotations already establish this is read-only and safe (readOnlyHint=true, destructiveHint=false). The description adds valuable behavioral context about the return payload—specifically that it includes names, specialties, and profiles, and indicates the approximate data volume (60+ items). It does not contradict the safety annotations.

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 first two sentences efficiently convey the tool's purpose. However, the description includes unnecessary boilerplate (### Responses, **200**: Successful Response, Content-Type, and an empty JSON output schema block) that wastes tokens and adds no value for an AI agent selecting tools.

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 this is a simple parameter-less retrieval tool, the description is complete. It compensates for the lack of a formal output schema by explicitly listing the returned fields (names, specialties, profiles) and data scale (60+). The annotations adequately cover behavioral safety hints, so the description does not need to repeat them.

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 input schema contains zero parameters. According to the rubric, 0 params = baseline 4. The description does not need to compensate for missing parameter documentation since there are no parameters to document.

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 'List[s] all 60+ specialist legal agents (leaders) with their names, specialties, and profiles.' This provides a specific verb (List), resource (legal agents/leaders), and scope (all 60+). It effectively distinguishes from siblings like chat_leader_api_chat_leader_post (which likely interacts with one leader) and ask_ask_post (which asks questions).

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 implies usage by stating it lists all leaders with their profiles, suggesting it should be used when the agent needs to discover available legal specialists. However, it lacks explicit guidance on when NOT to use it (e.g., 'do not use for real-time chat, use chat_leader instead') or workflow sequencing (e.g., 'use this first to find a leader, then use chat_leader').

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