Bug Description

When Hermes runs inside Slack and scoped Slack MCP tools are available, the gateway still injects a hardcoded platform note saying the agent has no Slack-specific API access and can only read messages sent directly to it.

This causes false refusals such as:

• “I can't directly read this Slack thread permalink”
• “I can only read messages sent directly to you”

even though Slack MCP tools are already present and working for:

• permalink lookup
• thread replies
• message search

This seems to be a prompt/runtime mismatch rather than a Slack MCP failure.

Related context:

• feat: make platform notes configurable instead of hardcoded limitations #2020
• fix(gateway): add platform notes to prevent hallucinated capabilities #1184
• PR fix(gateway): update inaccurate platform notes for Discord and Slack #2026
• Feature: Slack gateway should expose conversations.history as an agent tool #6345

Steps to Reproduce

1. Configure Hermes with a working Slack MCP server (personal Slack user token via MCP)
2. Restart Hermes so MCP tools are discovered
3. In a Slack DM with Hermes, send a request like:
      - Show me the conclusion of this slack thread
4. Observe that Hermes may reply with a refusal such as:
      - “I can't directly read this Slack thread permalink”
      - “I can only read messages sent directly to you”
5. In the same runtime, verify that Slack MCP tools can successfully:
      - resolve the permalink
      - fetch thread replies
      - search related messages

Expected Behavior

The Slack platform note injected by the gateway should reflect actual scoped tool availability.

• If no Slack tools are available, the current conservative wording is fine
• If dedicated Slack tools are available (for example Slack MCP tools), the prompt should acknowledge that Slack permalink/thread/history requests may be handled through those tools

Actual Behavior

The prompt still tells the model that it does NOT have Slack-specific API access and can only read messages sent directly to it.

Because of that, the model sometimes follows the hardcoded warning and refuses a Slack permalink/thread request, even though the runtime already has working Slack MCP tools.

Affected Component

Gateway (Telegram/Discord/Slack/WhatsApp)

Messaging Platform (if gateway-related)

Slack

Operating System

Arch Linux 2026.02.01

Python Version

3.11.14

Hermes Version

0.8.0

Relevant Logs / Traceback

No Python traceback.

This is a user-visible behavioral failure:
- Slack MCP tools are available and working
- but the injected Slack platform note still says the agent cannot access Slack-specific APIs
- the model sometimes obeys that stale note and refuses the request

Example refusal pattern:
- “I can't directly read this Slack thread permalink”
- “I can only read messages sent directly to you”

Root Cause Analysis (optional)

The likely root cause is in gateway/session.py inside build_session_context_prompt().

The Slack platform note is hardcoded:

• it always says Slack-specific APIs are unavailable
• it does not account for scoped Slack tools discovered at runtime (e.g. mcp_slack_*)

So the model receives contradictory signals:

• runtime reality: Slack MCP tools exist and work
• injected system note: Slack-specific access does not exist

That mismatch produces flaky behavior.

Proposed Fix (optional)

Make platform notes capability-aware instead of unconditional.

Suggested direction:

• keep the conservative note when no Slack tools are available
• emit a different note when scoped Slack tools are available
• explicitly say the agent may use dedicated tools for permalink/thread/history requests
• still forbid assuming raw token access or unmanaged API calls

In other words, align the injected prompt with actual scoped tool availability, without weakening the security model.

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR