@aiwerk/mcp-server-cal

Official

by AIWerk

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v1.0.5
Disambiguation5/5
Each tool targets a distinct action on a specific resource (booking, event type, availability, schedule). No overlapping purposes; clear boundaries between list vs get, create vs update, etc.
Naming Consistency5/5
All tools follow the 'cal_verb_noun' pattern in snake_case, with consistent verbs (list, get, create, update, delete, cancel, reschedule). No mixing of conventions.
Tool Count4/5
12 tools is a reasonable number for a scheduling server. It covers the main workflows without being excessive. Missing schedule CRUD tools, but core functionality is well-scoped.
Completeness3/5
Bookings have create, get, list, cancel, reschedule (missing update of details). Event types have full CRUD. Schedules only have list, lacking create/update/delete. Availability is read-only. Some gaps in booking update and schedule management.
Average 3.3/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
No annotations are provided, so the description carries full burden. It only says 'Delete', which is already obvious from the name. No disclosure of side effects, reversibility, or permissions.
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 a single concise sentence with no filler. It could benefit from more context, but it is efficient for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and only one parameter, the description fails to provide sufficient context about return values, side effects, or behavior. It is minimal and leaves many unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description adds no detail beyond the schema. 'Required: id' merely restates the schema's required field. The id is not explained or clarified.
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 action ('Delete') and resource ('event type'), and specifies the required parameter ('id'). This distinguishes it from siblings like create, update, and list.
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 is provided on when to use this tool versus alternatives. It only states the required id, without context on prerequisites or appropriate scenarios.
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 the description must disclose behavioral traits. It states 'Cancel' (implying mutation) but omits side effects, permissions needed, reversibility, or error conditions (e.g., if booking is already canceled). For a cancellation tool, this is insufficient.
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 very short (two sentences) and front-loads the core purpose. It lists parameters efficiently. However, it could be slightly more structured (e.g., grouping param details). Still, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and low schema coverage, the description is incomplete. It does not explain what the tool returns (e.g., confirmation, error codes), any constraints (e.g., time limits for cancellation), or the effect on the booking. The description alone is insufficient for an agent to use the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must add meaning. It repeats parameter names and marks required/optional but offers no explanation: 'uid' is implied as booking UID but not confirmed; 'cancellationReason' is left as any string with no guidance (e.g., free text vs predefined values). This adds minimal value over the schema structure.
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 action ('Cancel') and resource ('booking') in the first sentence, and the 'by UID' clarifies the identifier. This distinguishes it from siblings like cal_create_booking, cal_get_booking, and cal_reschedule_booking.
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 cancel vs reschedule or other alternatives. While required and optional parameters are listed, there is no context about prerequisites (e.g., only future bookings) or situations where cancellation is appropriate.
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, and the description does not disclose side effects, authentication requirements, rate limits, or failure conditions (e.g., conflicts). It only states it creates a booking, leaving behavioral traits unclear.
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 listing required and optional parameters, front-loaded with the action. No redundant information, but could benefit from slight restructuring for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description does not describe return values or side effects. For a creation tool, this is incomplete; agents need to know what is returned (e.g., booking ID) and whether confirmation occurs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description merely lists parameter names without explaining their purpose or adding context beyond the schema. For instance, 'metadata' is an object but no clarification on expected keys or usage.
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 starts with 'Create a new booking', uses a specific verb and resource. It lists required and optional fields, clearly distinguishing it from sibling tools like cancel, reschedule, etc.
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 explicit guidance on when to use this tool vs siblings. The description only states what the tool does, not when to prefer it over alternatives like cal_reschedule_booking or cal_cancel_booking.
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?
With no annotations provided, the description carries full responsibility for behavioral transparency. It states 'Get details', implying a read operation, but does not confirm idempotency, disclose any side effects, or mention potential errors (e.g., not found, auth failure). The agent cannot infer safety or restrictions.
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: two sentences with no redundant words. Every part is necessary. It is front-loaded with the primary purpose, making it quick to parse. No improvement needed.
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 tool with one parameter and no output schema, the description conveys the essential purpose. However, it does not explain what 'details' are returned or how the agent can interpret the response. While functionally tolerable, it leaves a gap in the agent's understanding of the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only restates that 'uid' is required, which is already evident from the schema. No additional meaning is added about the format, source, or expected value of the UID. This does not help the agent beyond the schema itself.
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?
The description clearly states the action ('Get details') and the resource ('a specific booking') and specifies the identifier ('by its UID'). This distinguishes it from siblings like 'cal_list_bookings' (list all) and 'cal_create_booking' (create). However, 'details' is vague and could be more precise, preventing a higher score.
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?
The description only mentions that 'uid' is required. It provides no guidance on when to use this tool versus alternatives (e.g., when you need all bookings vs a single one), nor does it mention prerequisites or scenarios to avoid. This leaves the agent without explicit decision support.
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 does not disclose behavioral traits such as read-only operation, side effects, or authorization needs. For a 'get' operation, read-only nature is implied but not stated, so the description carries the full burden and falls short.
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 very concise at one sentence, front-loading the action. However, the phrase 'Required: id' is redundant with the schema's required field. Still, it is efficient and not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks completeness. It does not describe the return value, potential errors, or any prerequisites. For a tool with one parameter and simple purpose, it is minimally adequate but leaves significant gaps.
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 single parameter 'id' has schema coverage of 0% meaning the schema provides details (type, constraints), but the description only states it is required. This adds minimal semantic value beyond the schema, just clarifying it's required. Baseline score of 3 is appropriate given low coverage but functional clarity.
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?
The description clearly states it retrieves details of a specific event type by ID, using a specific verb and resource. While it does not explicitly differentiate from siblings like cal_list_event_types (which lists all), the distinction is clear from the action being singular.
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 description mentions the required parameter 'id', which is minimal usage guidance. It does not specify when to use this tool over alternatives or provide any exclusions, which limits its helpfulness for an AI agent deciding between sibling tools.
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, so the description carries full responsibility. It only lists parameter requirements and fails to disclose behavioral traits such as idempotency, error handling (e.g., duplicate slug), or side effects. The description is insufficient for a mutation tool.
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, consisting of two front-loaded sentences. It efficiently conveys the primary purpose and parameter categories, although it sacrifices depth for brevity. There is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, no annotations, no output schema), the description is significantly incomplete. It does not explain return values, error behavior, or how the created event type relates to other tools. The agent would lack critical context for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must add semantic meaning beyond parameter names. It merely labels parameters as required or optional, which is already defined in the schema. No explanations are given for parameter purposes or formats (e.g., what 'slug' represents, how 'locations' should be structured).
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 'Create a new event type', using a specific verb and resource. It lists required and optional parameters, clearly differentiating from sibling tools like cal_update_event_type (update) and cal_delete_event_type (delete).
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 description implies usage for creating a new event type but provides no explicit context on when to use this tool versus alternatives. It does not mention prerequisites or when not to use it, leaving the agent to infer from the tool name.
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?
With no annotations, the description carries full burden for behavioral disclosure. It only mentions optional filters but does not disclose default behavior (e.g., which bookings are returned if no filters applied), ordering, pagination beyond the limit parameter, authentication needs, or side effects. This is insufficient for a listing 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 short sentences with no fluff. The first sentence states purpose, the second lists filters. Every word carries meaning, and it is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is too minimal. It omits return format, default sorting, default status filter, and error conditions. For a listing tool with multiple filters, more context is needed to guide the AI agent.
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 0%, so the description compensates by listing the parameters and their meanings: status with enum values, eventTypeId, dateFrom/dateTo as ISO 8601, and limit. It adds value beyond the raw schema but lacks details like what eventTypeId refers to or default limit (though schema says 20). It is adequate but not thorough.
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?
The description clearly states 'List bookings with optional filters,' identifying the resource (bookings) and action (list). It lists filter parameters, which distinguishes it from sibling tools like cal_get_booking (single booking) or cal_list_event_types (different resource). However, it does not explicitly differentiate from siblings.
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 description tells when to use the tool (to list bookings with filters) but does not specify when not to use it or mention alternatives like cal_get_booking for a single booking. No exclusions or context about prerequisites are provided.
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, so the description carries full burden for behavioral disclosure. It states the tool updates an event type but does not mention any side effects, required permissions, or whether unmentioned fields are preserved. This is insufficient for a mutation 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?
The description is a single, well-structured sentence that efficiently states the purpose and lists parameters. No unnecessary information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, no output schema, no annotations), the description is too minimal. It lacks details on parameter formats, constraints, and usage context, leaving significant gaps for an agent to correctly invoke the tool.
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 description enumerates the optional fields (title, slug, lengthInMinutes, etc.), which adds some meaning beyond the schema that only defines types. However, it does not explain the semantics of each parameter (e.g., what 'hidden' controls, structure of 'locations'), and the schema coverage is 0%, so more detail would benefit.
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?
The description clearly states the action ('update') and resource ('event type'), and lists required and optional fields. It effectively communicates the tool's function, though it does not explicitly distinguish from sibling tools like create or delete, but the verb is sufficiently specific.
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 description identifies the required parameter 'id' and lists optional fields, providing basic guidance on usage. However, it lacks context on when to use this tool versus alternatives (e.g., create_event_type for new) and does not mention prerequisites such as the event type existing.
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, the description bears full transparency burden. It mentions ISO 8601 format for dates, adding value beyond the schema. However, it does not disclose return format, pagination, or behavior for invalid inputs, leaving some ambiguity.
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 with one clear sentence listing parameters, no duplicated information, and no fluff. Every word contributes to understanding the tool's purpose and input requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should describe the return value, but it omits any mention of what the tool returns (e.g., list of time slots, availability statuses). For a read operation with no output schema, this is a significant gap that reduces completeness.
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 0%, so the description must clarify parameters. It specifies that dateFrom and dateTo require ISO 8601 format and that timeZone is optional, providing meaning beyond plain names. Yet it does not define the exact role of timeZone (e.g., input interpretation or output formatting) or the precise meaning of dateFrom/dateTo.
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 gets available time slots for a specific event type within a date range, using strong verb 'Get' and specific resource 'available time slots'. It distinguishes itself from sibling tools like cal_create_booking and cal_list_event_types by focusing on availability lookups.
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 description lists required (eventTypeId, dateFrom, dateTo) and optional (timeZone) parameters, providing basic usage hints. However, it lacks explicit guidance on when to use this tool versus alternatives like cal_get_booking or cal_list_schedules, and does not state prerequisites or limitations.
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 present, so the description carries the full burden. It only states 'List all event types' without disclosing whether the operation is read-only, side effects, authentication requirements, or rate limits. Minimal behavioral context.
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 and a short fragment, with no wasted words. It is front-loaded and to the point.
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 listing tool with two optional integer parameters and no output schema, the description is fairly complete. It tells what the tool does and what the parameters filter. Missing details like pagination or response format, but still adequate.
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?
Schema description coverage is 0%, but the description adds meaning by stating that 'teamId' and 'userId' are optional filters for team or user, which goes beyond the schema's type and range constraints. However, no further details on formats or behavior.
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 all event types, which is a specific verb+resource action. It is distinct from sibling tools like 'cal_get_event_type' (single) or 'cal_create_event_type' (create).
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 description implies usage for listing event types with optional filtering, but does not explicitly state when to use this over alternatives like 'cal_get_event_type' or 'cal_list_bookings'. No when-not-to-use guidance is provided.
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, so the description carries full burden for behavioral disclosure. It only states 'reschedule a booking to a new time' without detailing side effects (e.g., old slot availability, confirmation, permissions) or prerequisites.
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 very concise with two sentences, front-loading the action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about return values, error conditions, or constraints (e.g., only future times). With no output schema, the agent is left uninformed about the outcome of the tool call.
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 schema has 0% description coverage, but the description adds meaning by specifying the format (ISO 8601 for newStart) and which parameters are required vs optional. For 3 parameters, this provides useful guidance beyond the raw schema.
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 action (Reschedule) and resource (booking). It distinguishes from sibling tools like cal_create_booking (create) and cal_cancel_booking (cancel), so the agent knows when to use this 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?
The description lists required and optional parameters explicitly, providing clear usage instructions. It does not explicitly state when to use this tool vs alternatives, but the tool name and purpose are sufficiently distinct.
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. It implicitly states a safe read operation by saying 'list all', and clarifies the content as 'working hours and availability rules'. It does not mention side effects, but for a list operation that is acceptable.
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, front-loaded sentence with no fluff. Every word is meaningful.
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?
Given the lack of output schema, the description does not specify the structure or fields of returned schedules. However, for a simple list-all operation with zero parameters, the description is sufficient for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the baseline is 4. The description adds value by explaining what schedules are (working hours and availability rules), which goes beyond the schema. This is optimally clear.
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 uses a specific verb 'List' and resource 'schedules', with parenthetical clarification 'working hours and availability rules'. It clearly distinguishes from sibling tools like cal_list_bookings or cal_list_event_types.
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?
While there is no explicit when-to-use or when-not-to-use guidance, the simplicity of the tool (no parameters, lists all schedules) and the sibling names imply its use case. A more explicit contrast with other listing tools would improve clarity.
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:

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

Score Badge

Copy to your README.md:

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

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/AIWerk/mcp-server-cal'

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