Skip to main content
Glama

ringback

License Platform MCP Install with Claude Code

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 (say on 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

alert_me, alert_test, alert_status

Fire-and-forget notification: a loud push (ntfy / Pushover) and/or a SIP ring + chat message.

ringback-voice

call_start, converse, get_conversation, call_end, …

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@ringback

Claude 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 rings

ringback-alert is simpler: it shells out to ntfy/Pushover HTTP and/or baresip for a SIP ring + chat message.


Prerequisites

  • One of:

  • 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 python3 you point at)


Set up ringback-voice — 4 steps

1. Clone + install everything:

git clone https://github.com/mohitbadwal/ringback && cd ringback
./setup.sh

setup.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.sh instead — 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 launcher python3 run_voice_mcp.py (the .sh is macOS-only).

Hit a snag on macOS? docs/SETUP_MACOS.md is 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

VOICE_SIP_ID

Your SIP address, e.g. sip:you@sip.linphone.org

VOICE_SIP_USER

SIP username (the part before @)

VOICE_SIP_PASS

Your SIP password

VOICE_SIP_CALLEE

= VOICE_SIP_ID

Address to call (normally yourself)

VOICE_SIP_PROXY

sip:sip.linphone.org;transport=tls

SIP registrar/proxy

WHISPER_MODEL

~/.whisper-models/ggml-small.en.bin

STT model: base.en (fast) · small.en (default) · medium.en (accurate)

VOICE_TTS

auto

TTS engine: auto (Piper if installed, else OS voice) · piper · say · espeak · sapi

VOICE_PIPER_MODEL

~/.piper-voices/en_US-lessac-medium.onnx

Piper voice (.onnx; needs the matching .onnx.json beside it)

VOICE_TTS_CMD

Custom TTS command template with {text}/{out} (overrides VOICE_TTS)

VOICE_NULL_AUDIO

auto

Force pjsua2 null audio device (auto = on except macOS; 1/0 to force)

RINGBACK_PRESENCE

Override watchdog idle/presence: present or absent (for Wayland/headless)

PJPROJECT_DIR

~/build/pjproject-2.17

pjsua2 build dir (auto-detected)

PYTHON_BIN

$(command -v python3)

Python that has pjsua2 (auto-detected)

OPENSSL_PREFIX

$(brew --prefix openssl@3)

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 ringback

Then 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.py

See 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 up
  • converse(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_me as 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 critical by 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 Code

Then: /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 baresip accounts file 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 NOTICE for 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 tools
alert_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYes
severityNowarn
titleNoAlert

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

  1. 3 tool updatesv1.0.0
    • First observedalert_me
    • First observedalert_status
    • First observedalert_test

TDQS

A4.7/5.0
Disambiguation5/5

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.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (alert_me, alert_status, alert_test) with underscores, making them predictable and easy to understand.

Tool Count5/5

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.

Completeness4/5

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

ActivityStale
ResponsivenessSyncing

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

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    MCP 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.
    204
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Phone, 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.
    26
    AGPL 3.0

Latest Blog Posts

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