Skip to main content
Glama
privacyfence

PrivacyFence

Official
by privacyfence
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

slack_get_channel_history

Read-onlyIdempotent

Read recent messages from a Slack channel, newest first, with paging and an optional time cutoff. Use it to review conversation history, then page with the cursor for more.

Instructions

Fetch recent messages in a Slack channel. Returns {messages: [...], has_more: bool, next_cursor: str}, plus a note when has_more is true -- more messages exist than were returned (a Slack-imposed cap can make a page smaller than limit; see docs/slack-setup.md) -- call again with cursor=next_cursor to read the next page instead of assuming this is everything. Each message is {ts, channel_id, channel_name, user_id, user_name, text, thread_ts, reply_count, read_state}, newest first (read_state is 'unread', 'read' or 'unknown', from your own Slack read marker), one page of up to limit messages (default 50, capped at 1000); text and names may be redacted by the user's privacy settings. Use slack_get_thread_replies for a thread's replies, or slack_search_messages to find messages by text or person. Requires user approval. Pass minutes to read only the last N minutes of this conversation; it reads the conversation itself, so nothing is lost to search-index delay.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum messages to fetch, newest first. Default 50, capped at 1000.
cursorNoOpaque cursor from a previous result's next_cursor; empty starts at the newest messages.
reasonYesOne sentence: why are you calling this tool right now?
minutesNoOnly fetch messages from the last N minutes (1-10080, up to 7 days). 0 (the default) means no cutoff.
channel_idYesId of the channel or conversation, from the id field of slack_list_channels, slack_list_dms or slack_list_group_chats, or from slack_resolve_permalink. A name is not accepted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv6.8.0
    • addedInput schema / properties / minutes
      Added value: +{
+  "default": 0,
+  "description": "Only fetch messages from the last N minutes (1-10080, up to 7 days). 0 (the default) means no cutoff.",
+  "type": "integer"
+}
  2. Changed3 schema fields changed
    • addedInput schema / properties / channel_id / description
      Added value: +"Id of the channel or conversation, from the id field of slack_list_channels, slack_list_dms or slack_list_group_chats, or from slack_resolve_permalink. A name is not accepted."
    • addedInput schema / properties / cursor
      Added value: +{
+  "default": "",
+  "description": "Opaque cursor from a previous result's next_cursor; empty starts at the newest messages.",
+  "type": "string"
+}
    • addedInput schema / properties / limit / description
      Added value: +"Maximum messages to fetch, newest first. Default 50, capped at 1000."
  3. First observedv5.3.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the return shape, pagination behavior, Slack-imposed page-size caps, next_cursor usage, message fields, read-state provenance, privacy redaction, and that user approval is required. These are meaningful behavioral details not covered by readOnlyHint, idempotentHint, or destructiveHint. There is no contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and return behavior, and every major clause conveys operational information. However, it is a long single block with some repetition of schema details, so it is slightly less concise than ideal. It remains appropriately dense for a paginated fetch tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only paginated fetch tool, the description covers the return structure, pagination, redaction, approval needs, and alternatives. Annotations already establish the safety profile and the schema fully documents parameters, so no critical agent-facing context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds useful semantics for pagination and time filtering. It explains that has_more/next_cursor should be used for the next page and that minutes reads the conversation itself without search-index delay. It still repeats some schema-level details such as default 50 and cap 1000, so it is strong but not maximally additive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: "Fetch recent messages in a Slack channel." It also distinguishes this tool from siblings by directing thread replies to slack_get_thread_replies and text/person searches to slack_search_messages. An agent can identify the operation and its scope immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly names alternatives and when to use them: slack_get_thread_replies for a thread's replies and slack_search_messages to find messages by text or person. It also explains pagination behavior, the minutes parameter for recent-only reads, and the approval requirement. This gives clear when-to-use and when-to-use-alternatives guidance.

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

Deploy Server

Other Tools