@plaud-ai/mcp 0.1.58 → 0.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,51 @@
1
+ ---
2
+ name: plaud-export
3
+ version: 1.0.0
4
+ description: "Push Plaud content or a generated artifact to Notion, Slack, HubSpot, Linear, Gmail, or a custom webhook. Use when the user says 'save to Notion', 'post to Slack', 'send to webhook', 'file this in HubSpot', or asks to deliver recording content to an external system."
5
+ metadata:
6
+ requires:
7
+ bins: []
8
+ ---
9
+
10
+ # plaud-export
11
+
12
+ **Read [`plaud-shared`](../plaud-shared/SKILL.md) first.**
13
+
14
+ ## When to use
15
+
16
+ - User has a ready artifact (from `plaud-followup`) or recording content and wants to **deliver** it somewhere.
17
+ - Destination is an external system (not the chat).
18
+
19
+ ## Out of scope
20
+
21
+ - Generating the artifact — that's `plaud-followup`.
22
+ - Reading recording content — that's `plaud-read`.
23
+
24
+ This skill is the final leg: take content that already exists and send it.
25
+
26
+ ## Steps
27
+
28
+ 1. **Confirm the payload.**
29
+ - Recording summary (raw `get_note` content)?
30
+ - Generated artifact (email, SOAP, brief — already drafted)?
31
+ - Raw transcript excerpt?
32
+ 2. **Confirm the destination + identifiers.** Ask for the exact target. Plaud does not store destination credentials.
33
+ 3. **Deliver using the MCP tool or integration available in the user's environment.** Plaud MCP itself does not expose a `push` tool — this skill assumes another MCP (Notion MCP, Slack MCP, a webhook tool, Gmail send) is available in the session.
34
+ 4. **Report the delivery URL** (Notion page URL, Slack message permalink, webhook HTTP status) back to the user.
35
+
36
+ ## Destination identifier cheat-sheet
37
+
38
+ | Destination | Required identifier | Typical ask |
39
+ |---|---|---|
40
+ | Notion | page ID or database ID | "Which Notion page should this go under?" |
41
+ | Slack | channel name or ID | "Which channel? (e.g., `#sales` or `C0123`)" |
42
+ | HubSpot / Salesforce | CRM object ID (deal / contact / company) | "Which deal/contact should this attach to?" |
43
+ | Linear | team or project ID | "Which Linear team or project?" |
44
+ | Gmail | recipient email(s) | "Who should this email go to?" |
45
+ | Webhook | full URL | "Paste the webhook URL" |
46
+
47
+ ## Anti-patterns
48
+
49
+ - Never persist destination credentials in the conversation or in files. Assume the MCP host provides them.
50
+ - Never send to a default destination ("I'll put it in `#general`") — always confirm.
51
+ - Never alter the artifact content during delivery. If Slack needs mrkdwn, convert format without changing meaning.
@@ -0,0 +1,54 @@
1
+ ---
2
+ name: plaud-find
3
+ version: 1.0.0
4
+ description: "Find a specific Plaud recording by name keyword, date range, or topic. Use when the user says 'find the Weekly Sync', 'the meeting from Monday', 'the call about Q2', 'recordings last week', or describes what they're looking for rather than listing."
5
+ metadata:
6
+ requires:
7
+ bins: []
8
+ ---
9
+
10
+ # plaud-find
11
+
12
+ **Read [`plaud-shared`](../plaud-shared/SKILL.md) first.**
13
+
14
+ ## Background
15
+
16
+ Plaud's `list_files` API does **not** accept `query` / `date_from` / `date_to` server-side — unknown params are silently ignored. Filtering happens client-side.
17
+
18
+ The MCP `list_files` tool accepts the same three optional params and performs the filter for you: pass the user's keyword and/or date window and let the tool paginate up to 5 pages.
19
+
20
+ ## Steps
21
+
22
+ 1. **Elicit criteria if vague.** If the user just said "find a recording", ask for at least one of:
23
+ - a name keyword (even a partial match),
24
+ - a rough date or date range,
25
+ - a duration range (less useful, ask only if name and date fail).
26
+ 2. **Call `list_files`** with the filter params you gathered:
27
+ - `query=<keyword>` — case-insensitive substring match on `name`.
28
+ - `date_from=YYYY-MM-DD`, `date_to=YYYY-MM-DD` — inclusive window on `created_at`.
29
+ - Omit any that the user did not specify.
30
+ 3. **If zero matches**, ask the user to broaden one axis (shorter keyword, wider date range).
31
+ 4. **If many matches** (> 10), return the top 10 sorted by `created_at` desc and mention the total.
32
+ 5. **Never auto-load transcripts**. Present the match list and wait for the user to pick one — that triggers `plaud-read`.
33
+
34
+ ## Date interpretation rules
35
+
36
+ | User phrase | Filter |
37
+ |---|---|
38
+ | "today" | `date_from` = today, `date_to` = today |
39
+ | "yesterday" | both = yesterday |
40
+ | "this week" | Monday of this week → today |
41
+ | "last week" | Monday of last week → Sunday of last week |
42
+ | "this month" | 1st of this month → today |
43
+ | "last month" | 1st → last day of previous month |
44
+ | "from Monday" | `date_from` = the most recent Monday, no `date_to` |
45
+
46
+ Resolve relative dates against the **current date** (from conversation context), not the model's training cutoff.
47
+
48
+ ## Example
49
+
50
+ User: "find the customer onboarding call from last week"
51
+
52
+ Agent:
53
+ - `list_files(query="onboarding", date_from="2026-04-13", date_to="2026-04-19")`
54
+ - Return matches: "Found 2 recordings. `abc123` Customer Onboarding — Acme (2026-04-15, 42m), `def456` Onboarding Q&A (2026-04-17, 18m). Which one?"
@@ -0,0 +1,59 @@
1
+ ---
2
+ name: plaud-followup
3
+ version: 1.0.0
4
+ description: "Turn a Plaud recording into a follow-up email, thank-you note, action-item list, SOAP note, or meeting brief. Use when the user says 'draft follow-up', 'what were the action items', 'send thank-you email', 'turn this into a SOAP note', 'write the recap', or names an artifact to generate from a recording."
5
+ metadata:
6
+ requires:
7
+ bins: []
8
+ ---
9
+
10
+ # plaud-followup
11
+
12
+ **Read [`plaud-shared`](../plaud-shared/SKILL.md) first.**
13
+
14
+ ## When to use
15
+
16
+ - User wants a **generated document** grounded in one recording.
17
+ - Target format is explicit (email, SOAP note, brief, action-item list) or implicit ("write the follow-up").
18
+ - If the user wants to *send* the output to Notion / Slack / a webhook, chain into `plaud-export` after drafting.
19
+
20
+ ## Steps
21
+
22
+ 1. **Identify the recording.** If the user didn't name one, hand off to `plaud-find` or `plaud-browse`.
23
+ 2. **Fetch source content.**
24
+ - `get_note` first — usually enough for summaries and action items.
25
+ - `get_transcript` only if the artifact needs verbatim quotes (e.g., legal memo) or speaker attribution (e.g., SOAP).
26
+ 3. **Generate the artifact** in the requested format. Ground every claim in the source; do not invent attendees, dates, decisions, or numbers.
27
+ 4. **Present to the user** in the chat, then ask if they want to refine or export.
28
+
29
+ ## Artifact templates
30
+
31
+ ### Follow-up email
32
+ - To: attendees (from notes if listed).
33
+ - Subject: "Follow-up — {recording name}, {date}".
34
+ - Opening line: thanks + one-line meeting summary.
35
+ - Body: 3–5 bullets of key points.
36
+ - Action items: numbered list with owner and due date if mentioned.
37
+ - Closing: "Let me know if I missed anything."
38
+
39
+ ### Thank-you email
40
+ - Short. One paragraph. One concrete thing you learned or appreciated from the call.
41
+
42
+ ### Action-item list
43
+ - Plain markdown: `- [ ] {owner}: {item} (due {date})`.
44
+ - Mark owner as `?` if unclear from notes — do not guess.
45
+
46
+ ### SOAP note (clinical)
47
+ - **Subjective** — patient's words (from transcript).
48
+ - **Objective** — observations (from transcript, not inferred).
49
+ - **Assessment** — summary's diagnosis if present.
50
+ - **Plan** — action items and next appointment.
51
+
52
+ ### Meeting brief
53
+ - Attendees, date, duration, decisions, risks, next steps.
54
+
55
+ ## Anti-patterns
56
+
57
+ - Never invent email recipients. If attendees weren't captured, ask the user.
58
+ - Never invent due dates. Mark as `due: TBD` if not stated.
59
+ - Do not send the email — this skill drafts. Handoff to `plaud-export` for delivery.
@@ -0,0 +1,51 @@
1
+ ---
2
+ name: plaud-read
3
+ version: 1.0.0
4
+ description: "Read the transcript, AI summary, notes, or download audio for a specific Plaud recording. Use when the user says 'show the transcript', 'summarize this', 'what was said', 'get audio', 'the notes from', or names a specific recording to dig into. Also covers extracting structured fields from a recording."
5
+ metadata:
6
+ requires:
7
+ bins: []
8
+ ---
9
+
10
+ # plaud-read
11
+
12
+ **Read [`plaud-shared`](../plaud-shared/SKILL.md) first.**
13
+
14
+ ## When to use
15
+
16
+ - User names a specific recording (by name or ID) and wants to read its content.
17
+ - User asks for "transcript", "summary", "action items", "audio", "who said what", or a structured extraction ("action items, decisions, attendees").
18
+ - If the user did **not** specify a recording, hand off to `plaud-find` (by topic) or `plaud-browse` (by recency) first.
19
+
20
+ ## Tool selection matrix
21
+
22
+ | User wants | Tool | Notes |
23
+ |---|---|---|
24
+ | AI summary, TL;DR, action items | `get_note` | Returns Markdown; usually enough — try this before `get_transcript` |
25
+ | Verbatim quotes, full dialogue | `get_transcript` | Timestamped; larger |
26
+ | Audio download link | `get_file` then use `presigned_url` | Link expires in 24h |
27
+ | Full metadata + availability flags | `get_file` | Check `source_list` / `note_list` populated before claiming content exists |
28
+
29
+ ## Structured extraction workflow
30
+
31
+ If the user provides a schema (e.g., `{"action_items": [], "decisions": [], "attendees": []}`):
32
+
33
+ 1. Call `get_note` first — the AI summary usually already contains these fields.
34
+ 2. Only call `get_transcript` if the summary is missing a required field.
35
+ 3. Return JSON matching the user's schema. Mark any missing field with `null` and note why.
36
+
37
+ Common schemas:
38
+ - Sales: `{ "pain_points": [], "follow_ups": [], "deal_stage": "" }`
39
+ - Clinical: `{ "diagnoses": [], "medications": [], "next_appointment": "" }`
40
+ - Project: `{ "action_items": [], "decisions": [], "attendees": [] }`
41
+
42
+ ## Output
43
+
44
+ - Transcripts: preserve `[MM:SS - MM:SS] Speaker: content`. Do not reformat timestamps.
45
+ - Summaries: render Markdown directly in the reply.
46
+ - Audio: print the URL and mention "expires in 24h".
47
+
48
+ ## Anti-patterns
49
+
50
+ - Do not call `get_transcript` speculatively — it's the largest payload.
51
+ - Do not paraphrase the AI summary unless the user asked; quote it verbatim.
@@ -0,0 +1,67 @@
1
+ ---
2
+ name: plaud-shared
3
+ version: 1.0.0
4
+ description: "First read before any Plaud operation. Auth flow, error handling, output conventions, token refresh. Use when the user mentions Plaud for the first time in a session, or when any other Plaud skill is invoked."
5
+ metadata:
6
+ requires:
7
+ bins: []
8
+ ---
9
+
10
+ # plaud-shared
11
+
12
+ **CRITICAL — read this before calling any Plaud tool.** Applies to every other `plaud-*` skill.
13
+
14
+ ## Authentication
15
+
16
+ - Plaud uses OAuth. Tokens are stored in `~/.plaud/tokens.json` and refreshed automatically.
17
+ - If any tool returns an auth error (message includes `Not authenticated` or `401`), call the `login` tool and wait for the browser callback. Do **not** retry the original tool until login returns success.
18
+ - Never ask the user to paste tokens. The `login` tool handles the whole flow.
19
+
20
+ ## Tool inventory
21
+
22
+ | Tool | Purpose |
23
+ |---|---|
24
+ | `login` | Open browser for OAuth; blocks until callback or 2-min timeout |
25
+ | `logout` | Revoke and clear tokens |
26
+ | `get_current_user` | Verify who is signed in |
27
+ | `list_files` | Browse, paginate, filter recordings (supports `query`, `date_from`, `date_to`) |
28
+ | `get_file` | Full record incl. `presigned_url`, `source_list`, `note_list` |
29
+ | `get_note` | AI-generated summary and action items |
30
+ | `get_transcript` | Timestamped transcript with speaker labels |
31
+
32
+ ## Error semantics
33
+
34
+ | Pattern in error message | Meaning | What to do |
35
+ |---|---|---|
36
+ | `401` / `Not authenticated` | Token missing or expired | Call `login`, then retry |
37
+ | `404` | File ID does not exist | Tell the user the ID is wrong; do not retry |
38
+ | `500` | Backend error (often an invalid ID too — see §7.1 of proposal) | Retry once; if still 500, treat as NOT_FOUND |
39
+ | `fetch failed` / `ECONNREFUSED` | Network problem | Abort; tell user to check connection |
40
+
41
+ ## Output conventions
42
+
43
+ When presenting recordings to the user:
44
+
45
+ - Always show name, date, duration, and file ID — users need the ID to ask follow-up questions.
46
+ - Format durations human-readable: `23s`, `5m23s`, `1h05m`. Raw milliseconds are for logs only.
47
+ - Format dates as `YYYY-MM-DD` in local time.
48
+ - Transcripts: preserve `[MM:SS - MM:SS] Speaker: content` format.
49
+ - Notes: render Markdown directly.
50
+
51
+ ## Data model quick reference
52
+
53
+ - `duration` field is **milliseconds**.
54
+ - `source_list` — array; each item with `data_type === "transaction"` holds the transcript segments (JSON-encoded string in `data_content`).
55
+ - `note_list` — array; each item with `data_type === "auto_sum_note"` holds the AI summary (Markdown in `data_content`).
56
+ - `presigned_url` — expires in 24 hours; re-fetch with `get_file` if stale.
57
+
58
+ ## When to load which sibling skill
59
+
60
+ | User intent | Skill to follow |
61
+ |---|---|
62
+ | "List / show / browse my recordings" | `plaud-browse` |
63
+ | "Find the meeting about X" / "from Monday" | `plaud-find` |
64
+ | "Show transcript / summary / audio" | `plaud-read` |
65
+ | "Weekly digest" / "what did I have this month" | `plaud-digest` |
66
+ | "Draft follow-up" / "action items" / "thank-you email" | `plaud-followup` |
67
+ | "Save to Notion / Slack / webhook" | `plaud-export` |
@@ -1,111 +0,0 @@
1
- // src/skills.ts
2
- var SKILLS = [
3
- {
4
- name: "search-recordings",
5
- description: "Search and filter Plaud recordings by date, tag, or keyword",
6
- content: `## Plaud Skill: search-recordings
7
-
8
- There is no server-side search or filter API. To find a recording, fetch all pages from \`list_files\` and match client-side.
9
-
10
- **Step 1 \u2014 Collect search criteria**
11
-
12
- If the user's request is vague, ask for more specific information before fetching:
13
- - Approximate date or time range?
14
- - Rough title or topic to look for in the name?
15
-
16
- The more specific the criteria, the earlier a match can be found during pagination.
17
-
18
- **Step 2 \u2014 Fetch pages and match**
19
-
20
- Call \`list_files\` starting from page 1. For each page, check if any recording matches the user's criteria by name, date, or duration. Continue fetching subsequent pages until a match is found or all pages are exhausted.
21
-
22
- **Step 3 \u2014 Present results**
23
-
24
- Show a clear list of matches: recording name, date, duration, and file ID. If no match is found, tell the user and suggest refining the criteria.
25
-
26
- Do not fetch transcripts or notes unless the user explicitly asks to view the content of a specific recording.`
27
- },
28
- {
29
- name: "extract-structured-data",
30
- description: "Extract structured fields from a Plaud recording using a custom schema",
31
- content: `## Plaud Skill: extract-structured-data
32
-
33
- When the user wants to extract specific fields or structured information from a recording, follow this workflow:
34
-
35
- 1. If no recording is specified, call \`list_files\` and ask the user to identify the target
36
- 2. Call \`get_note\` to retrieve the AI-generated summary, action items, and key topics
37
- 3. Call \`get_transcript\` if the extraction requires full verbatim content
38
- 4. Apply the user's schema or field list to the content and return the extracted data
39
- 5. Present each field clearly; flag any fields where the content is ambiguous or absent
40
-
41
- Example schemas the user might request:
42
- - \`{ "action_items": [], "decisions": [], "attendees": [] }\`
43
- - \`{ "pain_points": [], "follow_ups": [], "deal_stage": "" }\`
44
- - \`{ "diagnoses": [], "medications": [], "next_appointment": "" }\``
45
- },
46
- {
47
- name: "generate-artifact",
48
- description: "Generate a document (email, summary, SOAP note, brief) grounded in a Plaud recording",
49
- content: `## Plaud Skill: generate-artifact
50
-
51
- When the user wants to generate a document grounded in recording content, follow this workflow:
52
-
53
- 1. Call \`get_note\` to retrieve AI-generated notes for the target recording
54
- 2. Call \`get_transcript\` if the artifact requires verbatim quotes or precise detail
55
- 3. Generate the artifact using the recording content as the source of truth
56
- 4. Format the output to match the requested artifact type
57
-
58
- Common artifact types:
59
- - **Follow-up email** \u2014 summarize key points, list action items, professional tone
60
- - **Meeting summary** \u2014 attendees, decisions made, next steps
61
- - **SOAP note** \u2014 Subjective / Objective / Assessment / Plan format for clinical use
62
- - **Project brief** \u2014 background, goals, scope, timeline from a planning session
63
- - **Weekly digest** \u2014 highlights across multiple recordings from the past week`
64
- },
65
- {
66
- name: "synthesize-corpus",
67
- description: "Analyze trends and patterns across multiple Plaud recordings",
68
- content: `## Plaud Skill: synthesize-corpus
69
-
70
- When the user wants to analyze patterns, trends, or themes across multiple recordings, follow this workflow:
71
-
72
- 1. Call \`list_files\` with date or tag filters to identify the target set of recordings (max 50 per call)
73
- 2. For each recording, call \`get_note\` to retrieve the AI-generated summary
74
- 3. Call \`get_transcript\` only if deeper analysis requires full verbatim content from specific recordings
75
- 4. Synthesize insights across all recordings:
76
- - Recurring themes or topics
77
- - Trends over time
78
- - Consistent decisions or blockers
79
- - Patterns in action items or follow-ups
80
- 5. Present findings with references to specific recordings as supporting evidence
81
-
82
- Use date filters to scope the corpus (e.g., last week, last quarter, a specific project period).`
83
- },
84
- {
85
- name: "push-to-destination",
86
- supported: false,
87
- description: "Send recording content or a generated artifact to Notion, HubSpot, Slack, Linear, or a webhook",
88
- content: `## Plaud Skill: push-to-destination
89
-
90
- When the user wants to send recording content or a generated artifact to an external system, follow this workflow:
91
-
92
- 1. Confirm what content to send: extracted data, a generated artifact, or raw notes
93
- 2. Confirm the destination and any required identifiers:
94
- - **Notion** \u2014 page ID or database ID
95
- - **HubSpot / Salesforce** \u2014 CRM object ID (deal, contact, or company)
96
- - **Linear** \u2014 project or team ID
97
- - **Slack** \u2014 channel name or ID
98
- - **Webhook** \u2014 URL provided by the user
99
- 3. Deliver the content to the destination using the appropriate integration tool or API call available in your environment
100
- 4. Confirm successful delivery to the user
101
-
102
- Note: Destination credentials (API tokens, webhook URLs) must be provided by the user. Do not store them in conversation history \u2014 use environment variables or the user's config.`
103
- }
104
- ];
105
- var ACTIVE_SKILLS = SKILLS.filter((s) => s.supported !== false);
106
- var SKILLS_COMBINED = ACTIVE_SKILLS.map((s) => s.content).join("\n\n---\n\n");
107
-
108
- export {
109
- ACTIVE_SKILLS,
110
- SKILLS_COMBINED
111
- };
@@ -1,40 +0,0 @@
1
- ---
2
- name: plaud
3
- description: Access and manage Plaud recordings, transcriptions, and meeting notes. Use when the user mentions Plaud, wants to find recordings, review transcripts, check meeting summaries, or manage their audio files.
4
- ---
5
-
6
- You have access to the user's Plaud recordings via MCP tools. Use them to help the user find, review, and analyze their recordings.
7
-
8
- ## Available tools
9
-
10
- | Tool | When to use |
11
- |---|---|
12
- | `login` | User is not authenticated, or auth has expired |
13
- | `logout` | User wants to sign out or disconnect |
14
- | `get_current_user` | User asks who is logged in, or to verify account |
15
- | `list_files` | User wants to browse, search, or find recordings |
16
- | `get_file` | User wants full details of a specific recording (including download link) |
17
- | `get_note` | User wants the AI-generated summary, action items, or key topics of a recording |
18
- | `get_transcript` | User wants the full timestamped transcript with speaker labels |
19
-
20
- ## Typical workflows
21
-
22
- **First-time use:** Call `login` first. If any tool returns an auth error, call `login` before retrying.
23
-
24
- **Find a recording:** Call `list_files` to browse. Use pagination (`page`, `page_size`) if the user wants more results.
25
-
26
- **Review notes or summary:** Call `get_note` with the file ID.
27
-
28
- **Read transcript:** Call `get_transcript` with the file ID.
29
-
30
- **Get full details (including download link):** Call `get_file` with the file ID. The response includes:
31
- - `source_list`: timestamped transcript with speaker labels
32
- - `note_list`: AI-generated summaries in Markdown
33
- - `presigned_url`: temporary download link (valid 24 hours)
34
-
35
- ## Guidelines
36
-
37
- - Always check if the user is logged in before calling data tools. If you get an auth error, call `login` first.
38
- - When listing files, present results clearly with name, date, and duration.
39
- - When showing transcripts, format them readably with timestamps and speaker labels.
40
- - When showing notes, render the Markdown content directly.