Skip to main content
Glama
kfinkels

gcalendar-mcp

by kfinkels
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Server Quality Checklist

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

  • Latest release: v0.1.0

  • Disambiguation5/5

    Each tool has a clearly distinct purpose: creating location-based reminders, creating time-based reminders, deleting reminders, and listing reminders. There is no overlap or ambiguity.

    Naming Consistency5/5

    All tools follow a consistent verb_noun pattern with lowercase snake_case (create_location_reminder, create_time_reminder, delete_reminder, list_reminders). No deviations.

    Tool Count5/5

    With 4 tools covering creation (two types), deletion, and listing, the set is well-scoped for a reminder management server. Each tool adds clear value.

    Completeness4/5

    Core operations are present, but an update tool for modifying reminders is missing, which agents may need. This is a minor gap given the scope.

  • Average 3.5/5 across 4 of 4 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

  • Behavior2/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations, the description must provide behavioral context. It implies a destructive action but does not disclose permanence, error handling, authorization needs, or side effects. The description is too 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?

    Single sentence, front-loaded, no wasted words. Highly concise and easy to parse.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/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, the description is adequate but incomplete. It does not explain the outcome (e.g., success, no return value) or error cases, which would be helpful given no output schema.

    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%, and the schema already describes event_id. The description adds no new semantics beyond restating 'by its event ID'. Baseline score of 3 is appropriate.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    Description clearly states the verb 'Delete' and the resource 'reminder from Google Calendar' with the method 'by its event ID'. It is unambiguous and distinct from sibling tools (create, list), though it does not explicitly differentiate itself.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or context that would help an agent decide between deleting a reminder and using other operations.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior2/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations provided, so description carries full burden. It fails to mention authentication requirements, whether reminders are filtered to future only, or the output format. The term 'upcoming' is vague.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness4/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    Single sentence, no fluff. Could include more context but still concise and front-loaded with action and resource.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Simple tool with one optional parameter, no output schema. Description is minimal but adequate for a list operation, though it omits details about return type and scope.

    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% with a clear description for max_results. The tool description adds no extra parameter meaning, so baseline 3 is appropriate.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    Clearly states it lists upcoming reminders and events from Google Calendar. The verb 'list' and resource are explicit. Sibling tools are all create/delete, so it stands out as the sole list 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?

    No explicit when-not-to-use or alternatives, but since siblings are all create/delete, there is no ambiguity. The description implies using this to view reminders.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior2/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, and the description only says 'create' without disclosing behavioral traits such as required permissions, side effects, or return behavior. Examples add context but do not compensate for the lack of transparency about the tool's actions.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness4/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is concise (two sentences plus examples) and front-loaded with purpose. Examples are relevant but slightly lengthy; no superfluous text.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    The description explains what the tool does and gives usage examples, but it omits what the tool returns (e.g., success indication, created object) and does not discuss error cases. For a creation tool with no output schema, this is a moderate gap.

    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%, so the schema already documents all parameters. The description provides examples that illustrate parameter usage but does not add new semantics beyond the schema descriptions.

    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 creates a 'location-based reminder in Google Calendar,' with specific examples that distinguish it from time-based reminders (sibling create_time_reminder). The verb 'create' and resource 'location-based reminder' are specific.

    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 usage for location-based reminders versus time-based alternatives (sibling create_time_reminder) through the phrase 'location-based' and examples. However, it does not explicitly state when not to use or name alternatives, though the context is clear.

    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?

    No annotations provided; description does not disclose side effects, permissions, or response. It only states creation, which is minimally adequate for a simple 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 plus examples; no wasted words. Front-loaded with purpose, then examples. Highly efficient.

    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 creation tool with no output schema, the description and schema cover purpose and parameters adequately. Missing return value info, but overall 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?

    Schema coverage is 100% with good descriptions for each parameter. The description adds no new semantic info beyond what the schema provides, meeting baseline.

    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 'Create a time-based reminder in Google Calendar' with specific verb and resource. Examples reinforce purpose and distinguish from sibling tools like create_location_reminder.

    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?

    Examples provide context for when to use (time-based reminders), but no explicit exclusion of location-based reminders or alternatives beyond the sibling tool list.

    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

gcalendar-mcp MCP server

Copy to your README.md:

Score Badge

gcalendar-mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/kfinkels/gcalendar-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server