Ringback
This server enables an AI agent to send urgent, tiered push notifications and phone alerts to a user who is away from their screen.
alert_me: Send a push notification with a message, title, and severity level:info: Standard-priority push notification.warn: High-priority, non-repeating push notification (default).critical: The most intrusive alert — can trigger a ringing SIP/Linphone phone call (full-screen, pierces silent mode) and/or a repeating Pushover emergency alert requiring acknowledgment.
alert_test: Send a low-priority test notification to verify the alert pipeline is correctly configured and the phone is receiving pushes, without risking a loud or intrusive alert.alert_status: Check which alert channels (ntfy, Pushover, SIP call) are configured and active, along with credential and rate-limit settings, without exposing any secrets.
ringback
Your AI agent can call your phone — and actually talk to you.
ringback gives an LLM (Claude, or any MCP client) tools to reach you on your phone — from a one-way "fierce" alert all the way to a live, interruptible voice conversation — using only free, self-hosted pieces. No paid telephony. No extra API key for the conversation: the model already driving the MCP is the voice on the line.
Highlights
📞 Two-way voice calls — the agent rings your phone, you talk, it transcribes you and replies in speech. Barge-in: talk over it and it stops.
🔔 Tiered alerts — a loud push (ntfy / Pushover) or a real SIP ring + chat message, fired only when the LLM judges it urgent.
🆓 Free & self-hosted — pjsua2 + whisper.cpp + Piper neural TTS + a free Linphone SIP account. No Twilio, no per-minute fees.
🧠 No conversation API key — the calling model is the brain; these tools are just its ears and mouth.
It ships two MCP servers, ringback-alert and ringback-voice:
Platform: macOS, Linux, and Windows (via WSL2 or Docker). TTS is Piper by default (same voice everywhere), falling back to the OS-native voice (
sayon macOS). The engine is headless — it never opens a local mic/speaker (all audio is WAV ↔ SIP/RTP), so no sound card is required. Setup guides: macOS · Linux · Windows · Docker.
Server | Tools | What it does |
ringback-alert |
| Fire-and-forget notification: a loud push (ntfy / Pushover) and/or a SIP ring + chat message. |
ringback-voice |
| A real two-way phone conversation. Rings your phone; you talk, it transcribes you, the LLM replies in speech. Supports barge-in (talk over it and it stops). |
The criteria for when to contact you live in the tool descriptions — the calling LLM decides. These servers are just the mechanism.
What a call looks like
agent → call_start("Your nightly deploy failed — want me to walk you through it?")
📞 your phone rings; you pick up and hear the line
you → "yeah, which step broke?"
agent → "The database migration. I can roll it back and retry — want that?"
you → "yes, do it" ← you can also just talk over the agent to interrupt
agent → call_end()The LLM calls call_start once, then converse(...) for each turn. Plain alerts are even simpler: one alert_me(...) call.
Install as a Claude Code plugin (Docker — one command)
If you have Docker and a free Linphone account, this is the fastest path — no local build:
/plugin marketplace add mohitbadwal/ringback
/plugin install ringback@ringbackClaude Code prompts for your SIP details (and optional alert backends), stores secrets in your OS keychain, and registers both ringback-voice and ringback-alert plus the watchdog skill. The engine runs in the prebuilt image (pulled on first call). See plugin/README.md.
Prefer no Docker, or want the native build? Use the paste-prompt below or the manual steps.
Related MCP server: Chamade MCP Server
Let Claude Code install it for you
🤖 Easiest path: copy the prompt below and paste it into Claude Code — it'll clone, build, configure, and register everything, asking you only for what it needs (a free SIP account + your phone to answer a test call).
Set up the ringback MCP server for me — it lets you (the agent) call my phone when you
need a decision while I'm away. Repo: https://github.com/mohitbadwal/ringback
(runs on macOS, Linux, or Windows via WSL2/Docker).
Please:
1. Detect my OS and pick the path:
- macOS → ./setup.sh (Homebrew); read docs/SETUP_MACOS.md
- Linux or Windows-WSL2 → ./setup-linux.sh; read docs/SETUP_LINUX.md
- Windows without WSL2 → use Docker; read docs/SETUP_DOCKER.md
2. Clone https://github.com/mohitbadwal/ringback, cd in, and read the README + the doc above.
3. Run the setup for my OS (compiles pjsua2 from source — ~20–30 min — installs whisper +
Piper TTS, downloads models, and creates voice.env).
4. I need a free Linphone SIP account (the phone line): walk me through signing up at
https://subscribe.linphone.org and installing the Linphone app on my phone, then put my
SIP id/username/password into voice.env (and set VOICE_DISPLAY_NAME to a caller-ID name).
5. Register it (per OS):
- macOS: claude mcp add ringback-voice --scope user -- "$PWD/run_voice_mcp.sh"
- Linux/WSL2: claude mcp add ringback-voice --scope user -- python3 "$PWD/run_voice_mcp.py"
- Docker: see docs/SETUP_DOCKER.md (build image, convert creds to voice.docker.env, then register a `docker run -i` command)
6. macOS only: if a test call fails with error -32000 or a segfault, run ./fix_macos_twolevel.sh.
7. Tell me to start a fresh session, then call me to confirm two-way voice works.
Ask me whenever you need input (SIP credentials, my phone to answer the test call, etc.).Prefer to do it by hand? Quick start and the full walkthrough are below.
Quick start
git clone https://github.com/mohitbadwal/ringback && cd ringback
./setup.sh # installs EVERYTHING (toolchain, pjsua2, whisper model, deps) + creates voice.env
# edit voice.env → add your 3 SIP vars (free account: https://subscribe.linphone.org), then:
claude mcp add ringback-voice --scope user -- "$PWD/run_voice_mcp.sh"Full walkthrough + env-var reference: Set up ringback-voice below.
Honest caveats (read first)
Cross-platform. macOS (native), Linux (native), Windows (via WSL2 or Docker). The engine is headless — no sound card needed. Native Windows (MSVC) is intentionally not supported; WSL2/Docker is the Windows path.
Not ChatGPT-realtime. The voice loop is record → whisper STT → LLM → Piper/say TTS, so expect ~1–2 s per turn. It's a reliable walkie-talkie with barge-in, not a streaming realtime voice.
The voice feature depends on GPL software (pjproject/pjsua2). This repo is Apache-2.0, but redistributing a bundle that links pjsua2 carries GPL obligations — see
NOTICE. The ringback-alert server is unaffected.Your machine must be awake and online, and for a voice call a Claude session must be live (it's the brain) for the duration.
Barge-in assumes low acoustic echo (handset or headset). On speakerphone, the TTS can echo into the mic and false-trigger "interruption." There's no echo cancellation in this path.
iOS push reality: a self-hosted/free push can't truly pierce Focus/Silent on iPhone except via Pushover's Critical Alerts (paid) — see ringback-alert notes below.
Architecture
LLM (Claude) ──MCP tools──▶ ringback-voice server (Python)
│ call_start / converse / listen / speak
▼
pjsua2 (SIP+SRTP, built from source) ──▶ Linphone SIP server
│ Piper/say → ffmpeg → WAV (speak) │ APNs VoIP push
│ record → whisper.cpp (listen) ▼
└───────────────────────────────────▶ your iPhone ringsringback-alert is simpler: it shells out to ntfy/Pushover HTTP and/or baresip for a SIP ring + chat message.
Prerequisites
One of:
macOS (Apple Silicon or Intel) with Homebrew — run
./setup.shLinux (Debian/Ubuntu/Fedora) — run
./setup-linux.sh(see docs/SETUP_LINUX.md)Windows — WSL2 (run
./setup-linux.shinside it) or Docker Desktop (see docs/SETUP_WINDOWS.md)Any OS with Docker —
docker build -t ringback .(see docs/SETUP_DOCKER.md)
A free Linphone SIP account (
sip.linphone.org) and the Linphone iOS/Android app (for the ring/voice features)Python 3.10+ (the pjsua2 bindings are built against whichever
python3you point at)
Set up ringback-voice — 4 steps
1. Clone + install everything:
git clone https://github.com/mohitbadwal/ringback && cd ringback
./setup.shsetup.sh installs the toolchain, compiles pjsua2 from source (~20–30 min — no Homebrew formula exists for the bindings), relinks the pjproject dylibs to a two-level OpenSSL namespace (the macOS fix that makes SIP/SRTP work), downloads the whisper model, installs Piper + a voice, installs deps, and creates voice.env for you. Safe to re-run. (Override PYTHON_BIN / PJPROJECT_DIR / WHISPER_MODEL_NAME if your layout differs.)
On Linux? Use
./setup-linux.shinstead — it does the same build with apt/dnf and needs no OpenSSL relink. On Windows? Use WSL2 (docs/SETUP_WINDOWS.md) or Docker. Register the server with the cross-platform launcherpython3 run_voice_mcp.py(the.shis macOS-only).
Hit a snag on macOS?
docs/SETUP_MACOS.mdis a field-tested root-cause + troubleshooting guide (build target, the OpenSSL flat-namespace fix, whisper model, symptom→fix table).
2. Get a free SIP account (this is the phone that rings):
Sign up at https://subscribe.linphone.org (or tap Create account in the Linphone app). You get a username and password; your address is
sip:<username>@sip.linphone.org.Install the Linphone app on your iPhone, sign in, and confirm it shows Connected.
3. Fill in voice.env (already created by setup.sh — just edit it). Only three vars are required:
export VOICE_SIP_ID="sip:yourname@sip.linphone.org"
export VOICE_SIP_USER="yourname"
export VOICE_SIP_PASS="your-password"Full variable reference:
Variable | Required | Default | What it is |
| ✅ | — | Your SIP address, e.g. |
| ✅ | — | SIP username (the part before |
| ✅ | — | Your SIP password |
| — | = | Address to call (normally yourself) |
| — |
| SIP registrar/proxy |
| — |
| STT model: |
| — |
| TTS engine: |
| — |
| Piper voice ( |
| — | — | Custom TTS command template with |
| — |
| Force pjsua2 null audio device ( |
| — | — | Override watchdog idle/presence: |
| — |
| pjsua2 build dir (auto-detected) |
| — |
| Python that has pjsua2 (auto-detected) |
| — |
| OpenSSL libs (macOS; auto-detected) |
4. Register + test:
# macOS:
claude mcp add ringback-voice --scope user -- "$PWD/run_voice_mcp.sh"
# Linux / Windows-WSL2 (cross-platform launcher):
claude mcp add ringback-voice --scope user -- python3 "$PWD/run_voice_mcp.py"
# Any OS via Docker (convert creds to voice.docker.env first — see docs/SETUP_DOCKER.md):
claude mcp add ringback-voice --scope user -- docker run -i --rm --network host --env-file voice.docker.env ringbackThen in a fresh Claude session say: "Use ringback-voice to call me and say hello." Your phone should ring.
Claude Desktop instead of Code? Add this to
~/Library/Application Support/Claude/claude_desktop_config.json(absolute path required; restart the app):{ "mcpServers": { "ringback-voice": { "command": "/absolute/path/to/ringback/run_voice_mcp.sh" } } }
Set up ringback-alert (optional)
ringback-alert reads its config from the MCP client's env block (no file to source). Register it with the channels you want:
# Claude Code
claude mcp add ringback-alert --scope user \
--env ALERT_CHANNEL=ntfy \
--env NTFY_URL=https://ntfy.sh/your-long-random-topic \
-- /opt/homebrew/bin/uv --directory "$PWD" run server.pySee alert.env.example for all variables (ntfy / Pushover / SIP ring). Use a long random ntfy topic — anyone who knows it can read/publish.
Using ringback-voice (the conversation)
The LLM drives a simple loop:
reply = call_start("Hi, it's your assistant — your deploy failed. Want details?")
# rings the phone, speaks the line, returns the user's first words
reply = converse("It failed on the database migration step. Want me to retry it?")
# speaks AND listens in one interruptible turn
... repeat converse() each turn ...
call_end() # when the user says "bye" / hangs upconverse(text)speaks while listening. If you talk over it, it stops immediately and tells the LLM how far it got and what you said (barge-in).get_conversation()returns the full transcript so far — both sides, plus where it got interrupted.TTS reads text literally, so the tool descriptions instruct the model to speak plain-language summaries, never raw logs/codes — those go via
alert_meas text instead.
Whisper model accuracy/speed trade-off (set WHISPER_MODEL): base.en (fast/rough) → small.en (balanced, default) → medium.en (most accurate/slow).
Using ringback-alert (notifications)
alert_me(message, severity, title) with severity = info | warn | critical. Channels via ALERT_CHANNEL (comma list of ntfy, pushover, call):
ntfy — free push; loud but does not pierce iOS Focus/Silent unless whitelisted per-Focus.
Pushover — $5 one-time; true iOS Critical Alerts (pierces Focus/Silent, repeats until acknowledged) at
critical.call — free SIP ring + Linphone chat message via baresip; rings full-screen, only at
criticalby default.
A built-in rate-limit guard (default 5/60s, per-process) stops a misfiring caller from spamming you.
Bundled skill: watchdog
skills/watchdog/ is a ready-to-use Claude skill built on these servers. It watches a condition you give it (a CI run, a deploy, a pod, a file) and escalates only when you're actually away from the laptop — chat status → chat warning → ringback-alert push → ringback-voice call — judged by input-idle time (macOS, Linux, or Windows; see platform_compat.hid_idle_seconds). It never interrupts you while you're typing, and de-escalates the moment you touch the keyboard.
cp -r skills/watchdog ~/.claude/skills/watchdog # install for Claude CodeThen: /watchdog <what to watch> | priority=<low|medium|critical> — low = chat only, medium = may send a phone alert, critical = may place a call. Full design in skills/watchdog/SKILL.md.
Security
SIP credentials live only in your local, gitignored
voice.env(and the baresipaccountsfile for ringback-alert) — never in the repo or the MCP client config when you can avoid it.The voice server only ever calls the single SIP URI you configure — it cannot dial arbitrary numbers.
Treat ntfy topics as secrets (use a long random topic); don't put sensitive detail in alert bodies on public ntfy.sh.
See
NOTICEfor the GPL/pjproject licensing caveat before redistributing.
License
Apache-2.0 (see LICENSE), with an important GPL caveat for the voice
component's pjproject dependency — see NOTICE.
Credits
Built on pjproject/pjsua2, whisper.cpp, baresip, ntfy, and Linphone.
Available Tools
3 toolsalert_meA
Physically buzz the user's phone with an urgent push notification.
The user is NOT watching the screen. Calling this interrupts them in the real world, so use it only when that interruption is justified.
USE FOR:
a production alert / pager condition fired
a long-running script, deploy, or migration FAILED or crashed
a watched value crossed a critical threshold
a task the user explicitly asked to be alerted about finished or blocked
anything time-sensitive the user would want to know NOW, not later
DO NOT USE FOR:
routine progress updates or status the user can read whenever
ordinary task completion that is not time-sensitive
anything the user did not ask to be interrupted about
chatty / informational messages — those belong in the normal reply
Args: message: One-sentence body, shown on the lock screen. Be specific and actionable, e.g. "QA deploy failed: migration 0042 errored on playground_management" — not "something went wrong". severity: "info" | "warn" | "critical". - "critical" = loudest + most intrusive. May place a ringing phone call (SIP / Linphone — full-screen, pierces silent) and/or a Pushover emergency alert that repeats until acknowledged. Reserve for things that genuinely must interrupt the user right now. - "warn" (default) = high-priority push, non-repeating, no call. - "info" = normal-priority push, no call. title: Short notification title (a few words).
Returns a status string describing what each backend did.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| severity | No | warn | |
| title | No | Alert |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having no annotations, the description fully discloses behavioral traits: it interrupts the user in the real world, the severity parameter alters intrusiveness (including a potential phone call for critical), and it returns a status string. This level of detail compensates for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a core sentence, then usage guidelines in bullet-style lists, then parameter details. Every sentence adds value, no filler. The front-loading of the key verb and impact ensures the agent quickly grasps the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple severity levels, real-world interruption, return value), the description covers all necessary aspects: purpose, usage guidelines, parameter meanings, and return type. The mention of a phone call for 'critical' severity is a critical behavioral detail. With an output schema present, the description is fully adequate for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the 'Args' section in the description adds rich semantic details for each parameter. For example, 'message' is described as a one-sentence lock-screen body with specificity requirements, and 'severity' outlines the exact behavior for each level, far exceeding the schema's type-only information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb 'buzz', a clear target 'user's phone', and an effect 'urgent push notification', immediately establishing the tool's core action. It further clarifies that this is a real-world interruption, which differentiates it from typical informational outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'USE FOR' and 'DO NOT USE FOR' sections, offering clear guidance on when the tool is appropriate and when it is not. It suggests alternatives for non-urgent messages ('belong in the normal reply'), effectively helping the agent make correct decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alert_statusA
Report which alert channels are configured (no secrets revealed).
Useful for debugging setup: shows the active channel, whether each backend has its credentials, and the current rate-limit settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that 'no secrets revealed', indicating privacy behavior, and lists the specific information shown. It doesn't detail permissions or side effects, but as a read-only report, that's acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose. Every word adds value, and no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description sufficiently covers the tool's function and output details (channels, credentials, rate limits). It is complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline is 4. The description does not need to explain parameters, and it adds context about what the output contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reports which alert channels are configured, and specifies details like active channel, credentials status, and rate-limit settings. This distinct purpose differentiates it from sibling tools alert_me and alert_test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Useful for debugging setup', giving clear context for when to use the tool. However, it doesn't mention alternatives or when not to use it, but the zero-parameter nature makes it straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alert_testA
Send a low-priority TEST notification to verify connectivity.
Safe to call during setup: it always uses 'info' severity so it will not fire a loud or repeating critical alert. Use this to confirm the phone receives pushes before relying on alert_me for real conditions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral trait: always uses 'info' severity, so it won't fire loud or repeating critical alerts. This is crucial despite no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, concise and front-loaded with purpose. Every sentence adds value with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully complete for a 0-parameter tool with output schema. Covers purpose, usage, and safety considerations adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is trivial. Description correctly omits parameter details as none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a low-priority TEST notification to verify connectivity. It distinguishes itself from siblings by specifying it's for testing, not for real conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: during setup to confirm phone receives pushes, and when not to: rely on alert_me for real conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
v1.0.0- First observed
alert_me - First observed
alert_status - First observed
alert_test
TDQS
Each tool has a clearly distinct purpose: alert_me sends real alerts, alert_status checks configuration, and alert_test sends a test notification. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (alert_me, alert_status, alert_test) with underscores, making them predictable and easy to understand.
With only 3 tools, the server is well-scoped for its purpose of sending alerts and checking status. Each tool earns its place, and the count is within the ideal 3-15 range.
The server covers the core operations: sending alerts, checking configuration, and testing connectivity. While missing features like alert history or cancellation, it provides a complete surface for its stated purpose.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Phone, SMS & email for AI agents — one remote MCP endpoint, OAuth login, zero install.
Give your AI agent a memory and body on your iPhone: set alarms, ring your phone, over MCP.
Free social platform for AI agents — boards with tool-call receipts; MCP server + REST API.
101Give your AI a real phone: place calls, send SMS, fetch recordings and transcripts. Local or hosted.
1
Related MCP Servers
- AlicenseAqualityCmaintenanceA local MCP server that lets any LLM agent manage Pine AI tasks — negotiate bills, cancel subscriptions, resolve disputes, and make phone calls on your behalf.191MIT

Chamade MCP Serverofficial
AlicenseNot gradedqualityDmaintenanceMCP server for Chamade — a voice and chat gateway that lets your AI agent join meetings and DMs on Discord, Microsoft Teams, Google Meet, Telegram, SIP, Zoom, Nextcloud Talk, Slack, and WhatsApp.204MIT- FlicenseNot gradedqualityBmaintenanceSelf-host a realtime voice-call companion for coding agents. Exposes an MCP endpoint that agents can poll as an alternate input stream.18-
- AlicenseNot gradedqualityAmaintenancePhone, SMS & email for AI agents. One remote MCP server (Streamable HTTP, OAuth or API-key auth, no local install) exposing call, sms, email, and event tools; also usable via CLI, Python SDK, and OpenAPI. Self-hostable, AGPLv3.26AGPL 3.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mohitbadwal/ringback'
If you have feedback or need assistance with the MCP directory API, please join our Discord server