Moves your Slack read marker in a channel or DM to a specific timestamp, marking messages up to that point as read.
Move your read marker in a channel/DM to ts (conversations.mark; needs channels:write, groups:write, im:write or mpim:write for that kind of conversation).
| Name | Required | Description | Default |
|---|---|---|---|
| ts | Yes | ||
| workspace | Yes | ||
| channel_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.2.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish mutation, idempotency, non-destructiveness, and open-world behavior. The description adds useful material context beyond annotations: the conversations.mark operation and the exact OAuth scopes needed for channels, groups, IMs, or MPIMs.
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?
One focused sentence with the action front-loaded and the permission scopes compactly parenthesized. Every part contributes useful information without padding.
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?
A simple, well-annotated write tool with an output schema, so return values need not be described. Still, the description leaves a notable gap around the required workspace parameter and does not clarify selection versus unread/read-channel siblings.
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 description coverage is 0%, so the description must carry parameter meaning. It partially clarifies ts as the read-marker target and channel/DM as the conversation, but it never explains the required workspace parameter or the expected ts format.
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?
States a specific verb and resource: moving a read marker in a channel/DM to a given ts, with the underlying conversations.mark API named. It is clear enough to distinguish from read/unread siblings, but it does not explicitly name an alternative to choose between.
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?
Implies when to use it by describing the read-marker move and listing required scopes per conversation type. However, it gives no explicit when-not guidance or comparison to related tools such as slack_unread.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.