MCP Servers for Audio Intelligence: The Developer's Guide

What MCP Is

Model Context Protocol (MCP) is an open specification, released by Anthropic in November 2024, that standardizes how language models communicate with external tools, APIs, and data sources. Before MCP, every AI framework invented its own tool-calling convention: OpenAI's function calling schema (introduced June 2023), Anthropic's own tool_use content blocks, LangChain's BaseTool interface, and so on. If you wanted your tool to work with three different AI hosts, you wrote three different adapters.

MCP collapses that into a single interface. An MCP server exposes a set of tools over JSON-RPC 2.0, a lightweight remote procedure call protocol. The server declares each tool's name, description, and input schema in a standard format. Any MCP-compatible host — Claude Desktop, Continue.dev, Cursor, Zed, a LangChain agent, a custom Python script — can connect to the server, discover the available tools, and call them without knowing anything about the underlying implementation.

The transport layer is HTTP with Server-Sent Events (SSE) for streaming, or standard input/output for local processes. The ListenBrief MCP server runs as a hosted HTTP service at https://listenbrief.com/mcp/v1 — no local install required.

Why Audio Intelligence Is a Natural Fit for MCP

Audio briefing generation is an inherently multi-step, asynchronous process. Content is fetched from sources, synthesized by an LLM, converted to speech by a TTS engine, encoded, and stored. That pipeline takes 60–180 seconds end to end. A synchronous HTTP request would time out. A polling loop is awkward to implement in every client independently.

MCP handles this elegantly. The agent calls generate_briefing and receives a job ID. It calls get_briefing_status at intervals — the model itself can reason about how long to wait based on the tool's description. When the job completes, it calls get_latest_briefing to retrieve the full result including the audio URL and structured story data.

The model's reasoning ability makes this more robust than a traditional polling client. If a tool call fails with a transient error, the model can decide to retry. If it fails repeatedly, the model can surface the error to the user rather than silently giving up. The agent is the error-handling layer.

See the MCP podcast server use case for a high-level overview. For deeper technical integration options, the AI podcast API use case covers the REST layer that underpins everything.

The 10 Tools on the ListenBrief MCP Server

Each tool's input schema is declared in the MCP manifest. The model reads the descriptions and parameter names to understand what each tool does and what arguments it needs — no separate documentation required during an agent session.

Code Example: A Claude Agent That Creates a Profile and Schedules a Daily Run

The following is a simplified Python script using the Anthropic SDK's tool use feature, calling the ListenBrief MCP server to bootstrap a new briefing profile. In a real MCP host like Claude Desktop, you wouldn't write this code — the host handles it. But this illustrates the underlying mechanics.

Authentication: API Keys, Scoped Permissions, and Test Keys

ListenBrief uses API key authentication for both the REST API and the MCP server. Keys are prefixed to indicate their type and environment:

• lb_live_... — production key, full access, billed against your plan.
• lb_test_... — test key, returns mock responses, no audio generated, no billing.
• lb_ro_... — read-only key, can call list_* and get_* tools but not generate_briefing, create_profile, or add_source.

When configuring the MCP server in Claude Desktop or another host, you provide the API key in the server configuration. The key scopes what the model can do — a read-only key prevents an agent from accidentally creating profiles or triggering generation during an exploration session.

For multi-user platforms, you generate per-user API keys via the developer API and pass the appropriate key when configuring the MCP connection for each user's agent context. Never share a single production key across multiple end users — you lose audit trail and can't isolate rate limit consumption.

Rate Limits and Quotas by Plan

Rate limits apply at the API key level. The ListenBrief MCP server enforces the same limits as the REST API, since it's the same backend:

• Starter ($9/mo): 1 briefing profile, 1 generation per day, 60 API requests per hour. Suitable for personal use or developer testing.
• Pro ($19/mo): 5 profiles, 5 generations per day, 300 API requests per hour. Suitable for power users and small integrations.
• Power ($39/mo): 20 profiles, 20 generations per day, 1,000 API requests per hour. Suitable for teams and production integrations.

The MCP server returns 429 Too Many Requests JSON-RPC errors when rate limits are exceeded, with a Retry-After header indicating how many seconds to wait. A well-behaved agent will read the tool's error response and either wait or surface the limitation to the user.

Building a Multi-User System

If you are building a product where multiple end users each get their own briefing, the pattern is:

1. At user registration, call POST /v1/api-keys with a scoped permission set to create a per-user API key. Store it in your database associated with the user record.
2. When that user's agent session starts, initialize the MCP connection with their specific API key. All tool calls in that session are isolated to their data and billed against your master account.
3. When the user deletes their account, call DELETE /v1/api-keys/{key_id} to revoke the key and prevent further usage.

This pattern ensures each user's briefing data is isolated, billing is trackable per user, and a compromised key affects only one user's data.

Webhook Integration: Async Briefing Completion

Polling is fine for agent sessions where the LLM is present and can reason about wait times. For backend systems generating briefings in batch — say, 500 users' briefings before 7 AM — polling is expensive and fragile. Webhooks are the right model.

Configure a webhook endpoint on your profile:

When a briefing finishes generating, ListenBrief POSTs to your webhook URL with the full briefing payload including the audio URL. Your server validates the X-ListenBrief-Signature header (HMAC-SHA256 of the raw body using your webhook secret), then processes the event: write the audio URL to your database, push a notification to the user, or trigger the next step in your pipeline.

Webhook delivery is retried up to 5 times with exponential backoff if your endpoint returns a non-2xx status. After 5 failures, the event is logged and marked as failed — you can retrieve missed events via GET /v1/webhook-events for up to 7 days.

Testing: Sandbox Mode and Mock Responses

Use a lb_test_... key during development. In test mode:

• generate_briefing returns immediately with a synthetic job ID. No audio is generated.
• get_briefing_status returns complete after two calls (simulating a short generation time).
• get_latest_briefing returns a static mock payload with 5 fake stories and a static demo MP3 URL.
• No rate limits are enforced in test mode — you can make as many calls as you need during development.
• Webhook events are fired synchronously in test mode with a 2-second delay, so you can test your handler without running a real briefing generation.

To switch from test to production, replace the lb_test_... key with a lb_live_... key. No other code changes are required.

Production Checklist Before Going Live

• Using lb_live_... keys in production and lb_test_... keys in development and CI.
• API keys are stored in environment variables, not hardcoded in source files.
• Webhook secret validated on every incoming event using HMAC-SHA256.
• Retry logic implemented for generate_briefing polling (exponential backoff, max 10 attempts).
• Per-user API keys issued if building a multi-user system; master key never exposed client-side.
• Rate limit errors (429) handled gracefully — queue the request and retry after Retry-After seconds.
• Briefing audio URLs cached in your own database — don't call get_latest_briefing on every user request.
• Webhook endpoint responds within 5 seconds (offload processing to a queue if needed).
• Plan capacity confirmed: number of daily generations matches your user base against your plan's quota.
• Error monitoring set up for briefing.failed webhook events.

Full API reference documentation is at developer.listenbrief.com, including OpenAPI 3.1 spec, TypeScript and Python SDKs, and interactive examples for each endpoint.