Retrieves the configured list of channels available for reading. Use it to verify which channels are set up, knowing access requires bot invitation.
読み取り対象として設定されているチャンネルの一覧を返す。Slack へは問い合わせない。ここに載っていても Bot が招待されていなければ読めない。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool does not query Slack (implying potential staleness or cached data) and that even listed channels may be unreadable if the bot isn't invited. These are meaningful behavioral traits beyond the basic purpose, adding transparency without 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?
Two concise sentences with no redundancy. The purpose is front-loaded in the first sentence, and the second adds a critical caveat. Every word earns its place.
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 zero-parameter tool with no output schema and no annotations, the description covers the core purpose, data source (not live Slack), and a key access limitation. It doesn't specify the return fields or format, but that is acceptable given the absence of an output schema. The description is complete enough for an agent to call it correctly.
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 schema coverage is 100% (no properties). Per the baseline rule for 0 params, a score of 4 applies. The description adds no parameter information, but none is needed.
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 states a specific verb and resource: 'Returns a list of channels that are set as read targets.' It also differentiates itself by noting it does not query Slack, distinguishing it from sibling tools that fetch live data. The purpose is 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?
The description implies usage context: this tool retrieves a locally configured list of channels rather than querying Slack live. It doesn't explicitly name alternatives or when-not-to-use, but the 'does not query Slack' hint provides clear contextual guidance that this is for configuration-based reads, not live Slack queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.