uscreen_list_community_channelsUscreen: Channels of your community with ID, name and whether they are public or private. Returns every channel the signed-in admin can see, including private ones. Channel names are lowercase, with hyphens or underscores instead of spaces. The default general channel is always public. Needs the user's Cotlet API key with access to this app.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnly/openWorld/non-destructive, and the description adds real context beyond them: the full admin visibility scope (including private channels), the naming convention, the always-public default general channel, and the API key/access requirement.
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?
Five short sentences, none wasted. The redundant 'Uscreen:' vendor prefix is minor padding, but the scoping and naming details are front-loaded and useful.
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?
No output schema exists, so the description correctly carries the return explanation (field set, visibility, naming rules) plus the auth requirement. An agent has what it needs to call and interpret this tool.
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?
With zero parameters there are no semantics to document, so the baseline is 4. The description appropriately spends its words on the return shape instead of inventing parameter detail.
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 the resource (community channels) and the exact fields returned (ID, name, public/private), so an agent knows precisely what this returns. It lacks an explicit leading verb and does not differentiate from other uscreen list tools, but the resource 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?
Usage is only implied by the returned scope ('every channel the signed-in admin can see, including private ones'). There is no explicit when-to-use, when-not, or alternative named, though no sibling channel tool exists to distinguish from.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.