Inspiration
Slack is where nonprofits, community groups, and mixed-language teams do their real work — but dense, jargon-heavy threads quietly exclude people. Non-native English speakers miss nuance. People with cognitive disabilities or reading difficulties struggle with long, unstructured updates. New volunteers can't parse months of acronyms and shorthand. We kept coming back to the same idea: teams built to reduce inequity shouldn't have an access barrier baked into their own communication tool. AccessBridge is our answer — an agent that makes any thread accessible, instantly, without anyone else in the conversation having to change how they write.
What it does
AccessBridge turns any Slack thread into an accessible version on demand:
- Plain-language rewrite — condenses jargon-heavy threads into clear language (~6th-grade reading level) while preserving every decision, deadline, and owner
- Translation — translates a thread into any requested language, preserving meaning over literal wording
- TTS/screen-reader formatting — reformats text into short, punctuation-clean sentences that read naturally aloud
You invoke it two ways: mention @AccessBridge in a thread with a plain-English request ("simplify this," "translate to Spanish"), or run /accessbridge <request> <thread link> from anywhere in the workspace. The original thread stays untouched — the accessible version posts alongside it.
How we built it
AccessBridge has three layers:
app.py— a Slack Bolt app (Socket Mode) that listens for@mentionsand the/accessbridgeslash command, and fetches the relevant thread text via the Slack Web API.agent.py— a Claude orchestrator using the Anthropic tool-use API. It reads the user's request and the thread text, and decides which tool(s) to call — including chaining more than one (e.g. "simplify and translate to French").mcp_server.py— a real MCP (Model Context Protocol) server exposing three tools:simplify_text,translate_text, andformat_for_tts. Each tool runs its own task-specific Claude prompt.agent.pyconnects to this server as a proper MCP client over stdio, callinglist_tools()andcall_tool()dynamically rather than hardcoding any single prompt.
This separation means the reasoning (what to do) and the execution (how to do it) are cleanly decoupled — the MCP server's tools are reusable outside of Slack entirely.
Challenges we ran into
- Deciding how to split responsibility between the orchestrator and the MCP tools so the architecture would be a genuine multi-step agent rather than one big prompt wearing an MCP costume
- Parsing Slack's thread permalink format reliably for the slash-command flow (converting the
p1234567890123timestamp format back into1234567890.123456) - Keeping the tool-call loop bounded so a confused request can't spiral into an infinite back-and-forth with the model
Accomplishments that we're proud of
- A working end-to-end pipeline from Slack event to MCP tool call to posted response
- Genuine multi-tool chaining — a single request like "simplify and translate to French" triggers two tool calls in sequence, decided by Claude at runtime, not hardcoded
- A design that any nonprofit or community Slack workspace could install today at zero cost to teammates who don't need it
What we learned
Building a real MCP server (not just calling an LLM directly) forced us to think about tools as reusable capabilities rather than one-off prompts — which turned out to make the whole system easier to reason about and test independently of Slack.
What's next for AccessBridge
- Real audio (TTS) file generation attached directly to the Slack response, not just TTS-formatted text
- Proactive detection: auto-offering to simplify/translate when a thread crosses a length or complexity threshold
- Per-user language and reading-level preferences, so the agent responds in DMs according to what each person needs without asking every time
Log in or sign up for Devpost to join the conversation.