io.github.katekruger/segment-mcp is an MCP server that read-first MCP server for Twilio Segment: routing, stale sources, delivery health, governance. Its tool list has not been published yet over stdio, requires no API key, and scores 59/100 on MCPpedia's security, maintenance and efficiency rubric.
Config is the same across clients - only the file and path differ.
{
"mcpServers": {
"io-github-katekruger-segment-mcp": {
"args": [
"segment-mcp"
],
"command": "uvx"
}
}
}Are you the author?
Add this badge to your README to show your security score and help users find safe servers.
Read-first MCP server for Twilio Segment: routing, stale sources, delivery health, governance.
Run this in your terminal to verify the server starts. Then let us know if it worked - your result helps other developers.
uvx 'segment-mcp' 2>&1 | head -1 && echo "✓ Server started successfully"
After testing, let us know if it worked:
Five weighted categories - click any category to see the underlying evidence.
No known CVEs.
Checked segment-mcp against OSV.dev.
Be the first to review
Have you used this server?
Share your experience - it helps other developers decide.
Sign in to write a review.
Others in communication / maps
Official TypeScript library for the Telnyx API
Open-source SMS gateway. Turn your Android phone into an SMS API: send and receive SMS from your apps over REST and webhooks. Self-hostable, with a free hosted plan.
Send email and newsletters with Mailtea over MCP, plus skills for email and website design.
X/Twitter automation MCP: scrape, post, schedule, analyze, engage. No API key required.
MCP Security Weekly
Get CVE alerts and security updates for io.github.katekruger/segment-mcp and similar servers.
Start a conversation
Ask a question, share a tip, or report an issue.
Sign in to join the discussion.
A read-first MCP server for Twilio Segment. Answers which destinations get which events, which sources are dead, and which are governed by nothing — the questions nobody can answer without clicking through forty screens.
SEGMENT_MCP_MODE defaults to read, and every tool this server ships
today is a read. Shipping with zero write tools is a feature, not a
limitation — see BUILD-PLAN.md §2. write and admin modes exist in
the tier model (src/segment_mcp/modes.py) for when gated writes land;
right now there is nothing for them to unlock.
POST /regulations and POST /regulations/sources/{id} — workspace-scoped,
irreversible deletion or suppression of user data across every source —
are unreachable in every mode, with no configuration path to enable
them. Three independent things enforce this: the mode-authorization
layer refuses it before even checking the current mode, the API client
refuses to send the request before it reaches the network, and no tool
this server registers references it in any form.
This isn't a gate waiting for the right permission level. It's a line, because these endpoints accept an array of subjects and one malformed or hallucinated call can permanently delete thousands of profiles with no undo. Full reasoning: docs/what-this-refuses-to-do.md.
Requires a Segment workspace on Team or Business tier and a Public API token (see Prerequisites below).
gh repo clone katekruger/segment-mcp
cd segment-mcp
uv sync
cp .env.example .env # fill in SEGMENT_API_TOKEN and SEGMENT_REGION
uv run segment-mcp
Point an MCP client (Claude Desktop, Claude Code, etc.) at it over stdio. The server refuses to start — loudly, with a clear message — if the token, region, or workspace tier isn't right; see Startup checks.
Each composes several Public API calls into one structured answer, not a raw endpoint dump:
| Tool | Question it answers |
|---|---|
audit_event_routing | Which destinations get which events? |
trace_event | Given an event name: where does it go, and is it governed by anything? |
find_stale_sources | Which sources have no recent data — dead instrumentation vs. simply new? |
check_delivery_health | Is this destination silently failing? |
find_ungoverned_sources | Which sources are governed by nothing, or allowing unplanned events through? |
SEGMENT_REGION=us # or eu
There is no default — you must set this explicitly. An EU workspace whose API calls are pointed at the US endpoint doesn't error; it just silently returns nothing, which is a far worse failure mode than a crash. This server's startup checks call the API once with your configured region and fail loudly if the token doesn't actually belong to it, naming the region that does.
All fatal — the server refuses to start rather than fail confusingly on the first tool call:
SEGMENT_REGION is set and one of us/eu.