Intelligence — summarize a busy channel
Intelligence: summarize a busy channel
Section titled “Intelligence: summarize a busy channel”The intelligence_summarize_channel tool turns “what did I miss in #support?”
into a structured summary — without the server holding any LLM API key.
It does this through MCP sampling: the tool calls back to the host client’s
LLM via the requestSampling capability, then parses the response.
Use case
Section titled “Use case”A support engineer says: “TL;DR what happened in #support over the last 50 messages, then post the summary to #ops.”
Two tool calls. The first asks the host’s own LLM (Claude, GPT, whatever) to do the heavy lifting; the second posts the result. discord-mcp ships zero API keys and never makes outbound LLM requests on your behalf.
Tool flow
Section titled “Tool flow”-
Read the channel (optional).
intelligence_summarize_channelfetches messages internally, so this step is only needed if you want to inspect the raw stream first or pass a custom subset. For the standard flow, skip straight to step 2.{"name": "messages_read","arguments": {"channel_id": "222233334444555566","limit": 50}} -
Summarize.
The tool returns a structured object with
summary,key_topics, andaction_items. Thestyleparameter controls tone:bullet(default),paragraph, orexecutive.{"name": "intelligence_summarize_channel","arguments": {"channel_id": "222233334444555566","limit": 50,"style": "bullet"}}{"summary": "- Three users hit the new SSO flow with expired refresh tokens.\n- @alice shipped a hotfix at 14:22 UTC; @bob verified.\n- Open: customer #88241 still cannot log in — escalated to on-call.","key_topics": ["sso", "refresh tokens", "hotfix deploy"],"action_items": ["follow up with customer #88241"],"message_count_used": 50,"sampling_used": true}{"summary": "[sampling unavailable — host LLM should summarize from raw_messages]","key_topics": [],"action_items": [],"message_count_used": 50,"sampling_used": false,"_meta": {"fallback": "host_llm_should_process","intent": "summarize","raw_messages": [{ "id": "888899990000111101", "author": "alice", "content": "shipping the SSO hotfix now" },{ "id": "888899990000111102", "author": "bob", "content": "lgtm, will verify on staging" }]}} -
Post the summary.
{"name": "messages_send","arguments": {"channel_id": "333344445555666677","content": "## Support recap\n\n- Three users hit the new SSO flow with expired refresh tokens.\n- @alice shipped a hotfix at 14:22 UTC; @bob verified.\n- Open: customer #88241 still cannot log in — escalated to on-call."}}When the tool returned the fallback envelope, the host LLM should instead read
_meta.raw_messages, generate the summary itself in the next turn, then callmessages_sendwith that content.
Why this design
Section titled “Why this design”- Zero API keys to manage. The server has no
OPENAI_API_KEYfield, no budget telemetry, no key rotation playbook. The agent’s existing model subscription does the work. - Privacy. Channel content never leaves the path the user already trusts (their MCP client → their LLM). discord-mcp doesn’t proxy text to a third-party inference provider.
- Graceful degradation. Clients without sampling still get a usable result via the fallback envelope — the agent just does the inference one turn later.
Style options
Section titled “Style options”style | Output shape |
|---|---|
bullet (default) | Markdown bullet list, scannable |
paragraph | Two-to-three sentence paragraph |
executive | Single-sentence headline + 3-bullet body, written for skim-readers |
See also
Section titled “See also”intelligence_summarize_channel— full schema and fallback envelope.messages_read— inspect raw messages before summarizing.messages_send— post the summary back.intelligence_classify_messages,intelligence_moderate_content— sibling sampling-based intelligence tools.- Architecture: MCP sampling — how the fallback envelope is constructed.