jamie-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.2/5 across 5 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![jamie-mcp MCP server](https://glama.ai/mcp/servers/vicampuzano/jamie-mcp/badges/card.svg)](https://glama.ai/mcp/servers/vicampuzano/jamie-mcp)

Score Badge

Copy to your README.md:

[![jamie-mcp MCP server](https://glama.ai/mcp/servers/vicampuzano/jamie-mcp/badges/score.svg)](https://glama.ai/mcp/servers/vicampuzano/jamie-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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