@useclypt/mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLYPT_API_KEY | Yes | Bearer token for the Clypt API. `clk_live_*` or `clk_test_*`. | |
| CLYPT_BASE_URL | No | Override for staging or local development. Trailing slash is stripped. | https://useclypt.com |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| submit_jobA | 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. |
| get_jobA | 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. |
| list_jobsA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each 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.