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., "@jamie-mcp list my meetings from yesterday"
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.
MCP (Model Context Protocol) server for Jamie AI — the AI meeting assistant. This server allows Claude to interact with your Jamie account: list meetings, read summaries and transcripts, search across meetings, manage tasks, and more.
Tool | Description |
| List meetings with optional filters (date range, email, tag, pagination) |
| Get full meeting details: summary, transcript, participants, tasks, tags, calendar event |
| Permanently delete a meeting and all its data (irreversible) |
| Semantic search across meeting content (personal key only) |
| List action items extracted from meetings |
| List available tags with colors (personal key only) |
Related MCP server: MCP Fathom Server
Add this MCP server to your Claude configuration:
{
"mcpServers": {
"jamie": {
"command": "npx",
"args": ["-y", "github:vicampuzano/jamie-mcp"],
"env": {
"JAMIE_API_KEY": "jk_your_api_key_here",
"JAMIE_KEY_TYPE": "personal"
}
}
}
}Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows)
Claude Code: ~/.claude.json or project-level .mcp.json
JAMIE_API_KEY (required)Your Jamie API key. To generate one:
Open Jamie and go to Settings → Developers → API Keys
Click Add API Key
Choose a scope (Personal or Workspace) and give it a name
Copy the key immediately — it is only shown once
All keys start with the jk_ prefix. API access requires a Pro, Team, or Enterprise plan.
JAMIE_KEY_TYPE (optional)Determines which API routes are used. Defaults to "personal".
Value | Routes | Access scope |
|
| Your own meetings + meetings shared with you |
|
| All meetings in the workspace |
Note:
search_meetingsandlist_tagsare only available with a personal key.
Node.js >= 18
A Jamie AI account with Pro, Team, or Enterprise plan
MIT
PERMANENTLY delete a meeting and ALL its data (summary, transcript, tasks). This action is IRREVERSIBLE. Always confirm with the user before calling this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| meetingId | Yes | The unique meeting identifier to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the crucial behavioral traits: permanent deletion, deletion of ALL associated data (summary, transcript, tasks), and irreversibility. It also mandates user confirmation. This gives the agent complete awareness of consequences before invoking the tool.
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 most critical information ('PERMANENTLY delete'), followed by the irreversibility warning and confirmation requirement. Every sentence earns its place; no wasted words.
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?
For a simple one-parameter delete tool with no output schema, the description covers all essential aspects: what is deleted, the affected data types, irreversibility, and the required confirmation step. It fully prepares the agent for the tool's usage and consequences.
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% (one parameter, meetingId, with description 'The unique meeting identifier to delete'). The description adds no additional parameter detail 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 explicitly states the action: 'PERMANENTLY delete a meeting and ALL its data (summary, transcript, tasks)'. It clearly distinguishes from read-only siblings like list_meetings, get_meeting, and search_meetings by using the destructive verb 'delete' and emphasizing permanence.
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 clear safety guidance: 'Always confirm with the user before calling this tool.' This implies the tool should not be invoked lightly. It does not explicitly name alternatives, but the destructive nature is self-evident compared to the read-only sibling tools, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a specific meeting: summary (markdown/html), transcript, participants, tasks, tags, and calendar event info.
| Name | Required | Description | Default |
|---|---|---|---|
| meetingId | Yes | The unique meeting identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility; it transparently lists the returned content components (summary, transcript, participants, tasks, tags, calendar event info), providing a clear picture of behavior. It does not include error handling or permission requirements, which is 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?
Single sentence with front-loaded purpose and enumerated data categories; no wasted words.
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 tool's simplicity (one parameter, no output schema), the description provides sufficient context by listing all return data categories; the agent knows what it will receive.
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?
Input schema covers meetingId with a clear description (the unique meeting identifier), and schema coverage is 100%, so the description adds no additional parameter semantics; baseline 3 applies.
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?
Clearly states 'Get full details of a specific meeting' with a specific verb and resource, and enumerates the content areas (summary, transcript, participants, tasks, tags, calendar info), distinguishing it from list_meetings which lists meetings.
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 implies use for a specific meeting by ID, which differentiates from list/search siblings, but no explicit when-not or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List meetings from Jamie AI. Returns meeting IDs, titles, and timestamps. Use get_meeting to retrieve full details of a specific meeting.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag name (personal key only) | |
| limit | No | Number of meetings to return (1-100, default 50) | |
| cursor | No | Pagination cursor from a previous response | |
| endDate | No | ISO 8601 date — only return meetings starting on or before this date | |
| startDate | No | ISO 8601 date — only return meetings starting on or after this date | |
| userEmail | No | Filter by user email (workspace key only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It states the return shape (IDs, titles, timestamps) and the source (Jamie AI). Missing are pagination behavior, authentication prerequisites, or side effects, which for a list operation are generally minimal. This is adequate but not rich.
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: first states purpose and return value, second provides guidance to a sibling tool. No wasted words and information is front-loaded.
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?
For a list tool with 6 optional parameters and no output schema, the description adequately covers the return value and points to get_meeting for details. It lacks explicit mention of pagination (cursor) but the schema covers it. Nearly complete for a straightforward read operation.
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 description coverage is 100%, with all 6 parameters having descriptive text. The description adds no parameter-specific information, but the baseline of 3 is appropriate since the schema does the heavy lifting.
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 clearly states action ('List meetings') and resource ('from Jamie AI'), and specifies the output fields (meeting IDs, titles, timestamps). It distinguishes from sibling get_meeting by indicating that full details require a different tool.
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?
Explicitly advises using get_meeting to retrieve full details, which provides clear alternative context. However, it does not mention other siblings like search_meetings or list_tags, so the guidance is not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available tags with their names and colors. Only available with a personal API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals an access restriction ('Only available with a personal API key') but does not state whether the operation is read-only, how results are returned (pagination, list array), or error handling. For a simple list operation, this is adequate but not rich.
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 a single sentence that immediately states the action and key detail. It contains zero filler words and is well-structured for quick scanning.
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?
For a simple zero-parameter list tool, the description covers the purpose (listing tags), a key output feature (names and colors), and a usage constraint (API key). It does not explicitly describe the return structure (e.g., array of objects), but this is a minor omission given the tool's simplicity.
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 tool has zero parameters and the schema is empty, so no additional parameter explanations are needed. The description adds no param semantics, but none are required, matching the baseline for a no-parameter tool.
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 'List all available tags', a specific verb and resource, and adds detail about what is returned (names and colors). It clearly distinguishes itself from sibling tools that focus on meetings or tasks.
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 makes it clear that this tool is for listing tags when those are needed, and the sibling tools are all about meetings/tasks, so context is unambiguous. No explicit exclusions or alternative recommendations are provided, but they are not necessary here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List action items and tasks extracted from meetings.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of tasks to return (1-100, default 50) | |
| cursor | No | Pagination cursor from a previous response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'List' implies a safe read-only operation, but the description does not explicitly state this, nor does it mention any caveats, default behaviors, or return format. It is adequate but minimal.
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 a single, concise sentence that directly states the tool's purpose without any unnecessary words.
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?
For a simple list tool with self-explanatory optional parameters and no output schema, the description is complete. The schema covers pagination details, and the verb 'List' clearly indicates a read operation. No critical information is missing.
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 schema fully describes both parameters (limit with min/max/default, cursor for pagination), so the description adds no additional meaning beyond the schema. This meets the baseline for 100% 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?
The description clearly states the tool lists action items and tasks extracted from meetings, using a specific verb and resource. It distinguishes from siblings like list_meetings and list_tags by the resource type.
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 intended use is implied: if you need tasks/action items from meetings, use this tool. However, there is no explicit comparison to alternatives like search_meetings or list_meetings, and no guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search across meeting content. Returns matching text excerpts with meeting references. Max 40 results from the past 6 months. Only available with a personal API key.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms for semantic matching | |
| endDate | No | ISO 8601 date — only search meetings on or before this date | |
| startDate | No | ISO 8601 date — only search meetings on or after this date |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It honestly reveals key limitations: 'Max 40 results from the past 6 months' and 'Only available with a personal API key.' It also states the return format, which is useful. It does not mention whether search is read-only, but 'search' implies no mutation.
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 extremely concise, consisting of three short declarative sentences. It front-loads the core purpose, then adds return details and key constraints. Every sentence earns its place with no filler or repetition.
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?
For a search tool with no output schema, the description adequately covers the return type ('matching text excerpts with meeting references') and important practical limits. It does not explain error handling or the full scope of what 'meeting content' includes, but given the simplicity of the schema and sibling context, it is reasonably complete.
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 thorough descriptions for all three parameters (query, startDate, endDate) with 100% coverage, so the baseline is 3. The description adds no parameter-specific details beyond what the schema states, but it does clarify the overall behavior (semantic matching) without altering parameter meaning.
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 states 'Semantic search across meeting content' with a specific verb and resource, clearly distinguishing it from sibling tools like list_meetings, get_meeting, and delete_meeting. It also specifies the output ('matching text excerpts with meeting references'), making the purpose unmistakable.
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 clearly implies when to use this tool (for semantic content search rather than listing or retrieving individual meetings), but it does not explicitly name alternatives or exclusion criteria. It does add a practical constraint: 'Only available with a personal API key,' which guides usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource and action: meeting listing, meeting detail, meeting deletion, tag listing, task listing, and meeting search. There is no functional overlap that would cause an agent to select the wrong tool.
All tools follow a consistent snake_case verb_noun pattern (list_meetings, get_meeting, delete_meeting, search_meetings, list_tags, list_tasks). Pluralization is correctly used for list operations and singular for get/delete, making the convention predictable.
With 6 tools, the server is well-scoped for its purpose. Each tool serves a clear core function without unnecessary bloat, staying comfortably within the ideal 3-15 range.
The tool set covers the primary meeting lifecycle (list, get, delete) and includes semantic search plus auxiliary listing for tags and tasks. Minor gaps exist, such as no task detail retrieval or update operations, but these are likely acceptable since meetings are AI-generated and the focus is read/delete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Search meetings, export summaries and transcripts, and manage recordings from any AI tool.
Search, read, create and edit your Memol notes from Claude. Team note-taking with AI search.
Search and read your Laxis meeting transcripts, AI summaries, and participants from Claude.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vicampuzano/jamie-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
