venue_listLists all venues, including sites, channels, and chats, with on/off status, streaming availability, and any remaining requirements for each.
Every venue: site, channel, chat on or off, whether it streams, and what it still needs from the person.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry the burden. It successfully discloses critical behavioral traits of the returned data, such as tracking whether chat is on/off, streaming status, and crucially, documenting outstanding operational needs from the user.
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, highly effective sentence. Every word is necessary to define the scope and complexity of the returned data, making it maximally efficient.
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 that this is a 0-parameter listing tool, describing exactly what attributes are contained within each 'venue' object (site, channel, stream status, needs) is sufficient to ensure the AI agent knows exactly what data to expect.
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 input parameters, which satisfies the baseline criteria for this dimension. The description does not need to add semantic meaning to non-existent parameters.
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 is very clear about what the tool provides—a comprehensive view of every venue. While it doesn't use a strict 'List X' format, it explicitly outlines the critical data points (site, channel, streaming status, and outstanding needs) included in the output.
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?
Because the tool takes no arguments, there is no need to differentiate between inputs. However, the description does not explicitly state when this tool should be used versus other potential list tools or how its output relates to a specific workflow, resulting in only implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.