List the Signal Queue

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior: it enumerates the filterable states (scheduled, sent, failed), shows the pagination contract (limit/offset, has_more, next_offset), and explains response_format options. It also documents the exact return object shape, which is especially valuable given there is no output schema.

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 efficiently structured: one purpose sentence, a compact Args list, a Returns outline, and three realistic examples. No content is wasted or redundant. The most critical information (what it lists) appears first, and the parameter/return/examples sections are easy to scan. It earns every line it uses.

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 read-only list tool with 7 optional parameters and no output schema, the description is quite complete. It documents all parameters, provides a return shape, and gives example mappings to natural-language intents. The only gap is explicit guidance on when to use this tool versus sibling list/dashboard tools, but the examples and purpose statement make its domain reasonably clear. Missing just a bit of 'when not to use' or alternative tool references.

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 only 43%, but the description's explicit Args block compensates fully. It gives every parameter a name, type, optional/default indicator, and semantic meaning (e.g., 'from_date: YYYY-MM-DD, on or after'). It even clarifies response_format choices ('markdown' for human-readable, 'json' for machine-readable') and provides example parameter combinations. This goes well beyond the sparse schema entries for status, brand_id, and the dates.

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 verb and resource: 'List scheduled, sent and failed posts in the sigcheCore broadcast queue.' This clearly distinguishes it from sibling tools like baatjie_schedule_signal (which likely creates queue entries) and baatjie_query (general-purpose querying). The title aligns with the description, making it unambiguous.

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?

Usage is implied through three concrete examples ('What's queued today?', 'Anything failed?', 'locare's schedule') that map to parameter choices. However, the description does not explicitly state when to prefer this tool over siblings such as baatjie_dashboard or baatjie_query, nor does it mention when not to use it. This is adequate implied guidance but lacks explicit exclusions or alternative naming.

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