Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@useclypt/mcp-server Clip this podcast: https://feeds.simplecast.com/abc123"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol server for Clypt. Lets AI agents (Claude Desktop, Cursor, Claude Code, any MCP-aware client) submit a podcast URL and receive clips, an optional trailer, show notes, a guest-share link, and the transcript.
Pure shim over the public REST API at https://useclypt.com/api/v1 — three tools, no clever middleware.
Tool | Wraps | Returns |
|
|
|
|
| Current job state. When |
|
| Cursor-paginated list of the org's recent jobs. |
The flow is asynchronous: submit_job returns immediately with a queued id; the agent polls get_job until terminal. Once a webhook is registered against your org, job.completed and job.failed events fire on every terminal transition — register via the public API at POST /v1/webhooks (no MCP tool for this yet; coming in a later minor).
Related MCP server: riocloud-reader
With the server configured in Claude Desktop, ask:
Use Clypt to clip this podcast and tell me when it's done: https://feeds.simplecast.com/abc123
Claude will call submit_job, get back a job id, poll get_job until terminal, and surface the clips + trailer + transcript inline. Wall-clock: ~2-5 min for audio/RSS, ~10-12 min for video + trailer.
npm install -g @useclypt/mcp-serverOr run without installing:
npx -y @useclypt/mcp-server~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"clypt": {
"command": "npx",
"args": ["-y", "@useclypt/mcp-server"],
"env": {
"CLYPT_API_KEY": "clk_live_..."
}
}
}
}Restart Claude Desktop. Then prompt: "Use Clypt to clip this podcast: ".
Same recipe — the binary is mcp-server (or run without global install via npx -y @useclypt/mcp-server) and the only required env var is CLYPT_API_KEY.
If your key starts with clk_test_ instead of clk_live_, every job returns a deterministic fixture instead of running the real pipeline. No transcription cost, no R2 storage cost, no Stripe charges. Useful for wiring up your agent before you commit to real submissions.
Fixture mapping:
source.type='video_url' (any URL) → success fixture with 3 clips + optional trailer
source.type='audio_url' / rss_feed_url (URL without "fail") → success fixture
Any URL containing "fail" → transcription_failed error fixture
source.type='youtube_url' → youtube_ingestion_failed error fixture
Malformed URL → invalid_source_url validation error at submit
Get a sandbox key in seconds at useclypt.com/developers/signup — no credit card, no waiting list. Sandbox keys (prefix clk_test_) return deterministic fixtures so you can wire up your agent for free before swapping in a clk_live_ key.
Variable | Required | Default | Purpose |
| yes | — | Bearer token for the Clypt API. |
| no |
| Override for staging or local development. Trailing slash is stripped. |
npm install
npm run build
npm test # vitest unit tests with mocked fetch
npm run dev # tsc --watchSmoke against the live API with the MCP inspector CLI:
npm run build
CLYPT_API_KEY=clk_test_xxx \
npx @modelcontextprotocol/inspector --cli node dist/index.js --method tools/listAPI reference: useclypt.com/developers/docs
Get a key: useclypt.com/developers/signup
About Clypt: useclypt.com
MIT — see LICENSE.
Fetch the current state of a previously submitted job. When status='complete', the returned envelope contains the output object with clips, optional trailer, guest_share_url, show_notes, and transcript. When status='failed', the envelope contains an error object with code + message. Call this repeatedly (every 30-60s is plenty — jobs take minutes, not seconds) until status is one of complete/failed.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The job id returned by submit_job. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It clearly discloses the two terminal states (complete with output object, failed with error object), indicates that polling is required, and notes the interval advice. It doesn't mention non-mutating behavior explicitly, but 'fetching state' implies a read-only operation. At best, it could enumerate all statuses (e.g., pending/running) but that's a minor gap.
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, front-loaded with the action, then a compact description of return states and polling cadence. Every word earns its place; no redundancy.
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?
The tool has only 1 parameter, no output schema, and no annotations. The description fully covers what the tool does, how to call it, what to expect in the response, and how often to poll. Nothing critical is missing for an agent to invoke it successfully.
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?
Schema coverage is 100% — the single id parameter is fully described as 'The job id returned by submit_job.' The description adds minimal extra meaning with 'previously submitted' but doesn't need to. Baseline 3 is appropriate given high schema coverage.
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?
Description opens with 'Fetch the current state of a previously submitted job' — a specific verb+resource pairing that clearly distinguishes it from siblings (submit_job creates a job, list_jobs lists jobs). It also narrows the scope to previously submitted jobs via the id parameter.
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?
Provides explicit polling guidance: 'Call this repeatedly (every 30-60s is plenty — jobs take minutes, not seconds) until status is one of complete/failed.' It implies when to use this tool (to check a specific job's status) rather than list_jobs, though it doesn't explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent jobs for the authenticated organisation, newest first. Cursor-paginated via starting_after. Useful for inspecting recent submissions when you don't have the id to hand.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max items per page (1-100, default 20). | |
| starting_after | No | Cursor: pass the last job id from the previous page to fetch the next page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses ordering ('newest first'), pagination ('cursor-paginated via starting_after'), and authentication context ('authenticated organisation'). It doesn't describe return format or error behavior, but for a simple list operation these are not critical gaps, and the disclosed traits are genuinely useful.
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, each earning its place: the first states the core function and ordering, the second explains pagination and the intended use case. No redundant details, front-loaded with the primary 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 low complexity (two optional params, no output schema) and the presence of sibling tools that clarify the API landscape, the description is adequate. It could have explicitly mentioned the response shape, but the tool's name and purpose imply a list of job objects. The description covers the key contexts: auth scope, ordering, pagination, and when to use it.
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?
Schema coverage is 100% with descriptions for both parameters: 'limit' and 'starting_after'. The description adds context about pagination via starting_after and ordering, but this mostly reinforces schema info (e.g., 'Cursor: pass the last job id...'). It does not add meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
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 uses a specific verb+resource pattern: 'List recent jobs' with a clear scope ('for the authenticated organisation') and ordering ('newest first'). It distinguishes from sibling tools by stating 'when you don't have the id to hand,' which contrasts with get_job and implicitly with submit_job.
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 explicitly states the use case: 'Useful for inspecting recent submissions when you don't have the id to hand.' This clearly tells the agent when to use this tool instead of a direct ID-based lookup, and implies it's the correct choice for browsing recent items without a known ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a podcast for processing. Returns a job id immediately with status='queued'; the pipeline runs asynchronously — call get_job to poll. Typical wall-clock to terminal is ~2-5 min for audio_url/rss_feed_url, ~10-12 min for video_url with include_trailer=true. Source type 'youtube_url' is in beta — sandbox keys return a fixture failure; live keys reject it for now. For free deterministic testing, use a sandbox key (prefix clk_test_) — every submission returns canned fixture output ~10-70s later.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Where to fetch the source media from. | |
| options | No | Optional job-level overrides. | |
| idempotency_key | No | Optional idempotency token (8-255 chars). Re-submitting the same body with the same key inside 24h returns the original job instead of creating a new one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the async behavior (immediate 'queued' status), expected wall-clock times for different source types, and special sandbox behavior (canned fixture output). This is transparent about what the caller should expect. No contradictions with 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 four sentences, each delivering actionable information: behavior, timing, beta status, and sandbox testing. There is no fluff; every sentence earns its place.
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?
The description is comprehensive for a submission tool: it explains the immediate response ('queued' with a job id), how to track progress (get_job), expected performance, beta limitations, and testing options. Although there is no output schema, the description covers the key return behavior. The nesting and options are well documented in the schema, and the description adds the behavioral context necessary for correct usage.
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 already provides full descriptions for all parameters (100% coverage), so the baseline is 3. The description adds beyond that by giving timing estimates that depend on source type and include_trailer, enriching the semantics of those parameters. It does not explain each parameter individually, but the schema does, and the added context about time is useful.
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 opens with a clear verb and resource ('Submit a podcast for processing'), and distinguishes itself from siblings by noting that it returns a job id immediately and that polling is done via get_job. This makes its role unambiguous.
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 provides explicit guidance: the tool submits a job asynchronously, and callers should use get_job to poll status. It also clarifies constraints for youtube_url (beta, rejected for live keys) and suggests sandbox keys for deterministic testing, which are valuable usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.5get_joblist_jobssubmit_jobEach tool has a clearly distinct purpose: submit creates a job, get retrieves a specific job, and list enumerates jobs. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern: submit_job, get_job, list_jobs. The slight pluralization in list_jobs is a minor and natural deviation.
Three tools is well-scoped for the server's purpose of managing asynchronous podcast processing jobs. Each tool earns its place with no redundancy.
The surface covers the core lifecycle: submit, poll, and list jobs. Missing cancel/delete is a minor gap but not essential for the stated async-processing workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Podcast intelligence for agents: transcripts, clips, speaker diarization, mention tracking.
Turn podcasts and long videos into ranked, finished short clips via the hosted ClipZyn API.
Create, import, and publish Jellypod podcast episodes from your AI assistant.
Podcast search, metadata, chapters, and transcripts for AI agents — from $15/mo
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nelsonjordanme/clypt-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
