@calmesh/mcp-server

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation3/5
Most tools are clearly separated by domain (events, bookings, polls, connections), but 'get_events' and 'get_event_details' both fetch events in a date range with different detail levels, and 'check_availability' and 'get_slots' both return free time slots but in different contexts. These overlapping boundaries could cause agents to select the wrong tool.
Naming Consistency4/5
All tool names follow a consistent calmesh_verb_noun snake_case pattern, which is easy to read and predict. However, read operations use a mix of 'list', 'get', and 'check' (e.g., list_calendars, get_events, check_availability), a minor inconsistency that slightly reduces predictability.
Tool Count4/5
With 22 tools covering calendars, events, bookings, polls, and connections, the count is high but justified by the breadth of functionality. It sits slightly above the ideal 3-15 range but is not excessive for the domain.
Completeness3/5
The tool surface covers most workflows, but there is no update_event tool, making it impossible to modify existing events, and no delete_calendar. Bookings and polls also lack update operations, forcing workarounds like delete-and-recreate. These gaps could hinder common tasks.
Average 4/5 across 22 of 22 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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 failing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool returns free slots and requires 'read' scope, which adds some transparency. However, it does not explain how slots are determined (e.g., whether they account for existing events, working hours, or past times), nor does it describe error behavior or rate limits. This is partial but not comprehensive.
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 three concise sentences: purpose, return value, and a requirement. It is front-loaded with the action, and every sentence adds value without any redundant wording. This is exemplary conciseness.
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 tool has 4 parameters, no annotations, and no output schema. The description covers the core purpose and mentions the read scope, and the schema fully documents parameters. However, it lacks usage differentiation from sibling tools and does not address edge cases or return structure in detail, leaving some gaps for a complete understanding.
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 each parameter having a detailed description (date, slug, duration, timezone). The description text adds no additional meaning beyond what the schema already provides, so the 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?
The description clearly states the tool's function: 'Check available time slots on a calendar for a given date' and 'Returns free slots where meetings can be scheduled.' This is specific and uses a clear verb+resource structure. However, it does not differentiate from the sibling tool calmesh_get_slots, which likely has a similar purpose, preventing a score of 5.
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 provides no guidance on when to use this tool versus alternatives such as calmesh_get_slots or calmesh_find_conflicts. It only mentions the 'read' scope prerequisite, which is not usage context. There is no mention of scenarios or exclusions, leaving the agent without clear decision-making information.
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 are provided, so the description carries the burden. It discloses required scope and return values but omits failure behavior (e.g., unavailable slot), side effects, or whether the booking is temporary. The schema adds some behavioral context ('Must be an available slot') but the description itself is limited.
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 cover action, return values, and scope. No filler or redundancy, and the key information is front-loaded.
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?
Given no output schema and no annotations, the description provides essential facts: action, returns, and scope. However, it lacks error handling guidance, prerequisites like checking availability first, and usage context relative to sibling tools. It is adequate but not complete for a booking creation 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?
Schema description coverage is 100%, so parameters are already well documented. The description adds minimal parameter-specific meaning beyond the schema, only mentioning that the tool returns booking ID/status/confirmed time and requires scope, which is not directly param-related. 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?
The description states a specific action ('Create a new booking on a booking page') and indicates return values (booking ID, status, confirmed time), which clearly conveys the tool's purpose. It doesn't differentiate from siblings like calmesh_create_event or calmesh_create_poll, but the focus on 'booking page' provides enough context.
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?
It implies usage by describing the creation action and lists a prerequisite ('book' scope), but lacks explicit guidance on when to use this tool versus alternatives, and does not mention related tools like calmesh_check_availability or calmesh_get_slots. It gives some context but no exclusions or alternatives.
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 must carry the full burden of behavioral disclosure. It mentions the 'write' scope requirement, but omits critical behavioral traits such as whether deletion is permanent, irreversible, or affects related data. It also does not describe error behavior or side effects. For a delete operation, these are essential gaps.
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 exceptionally concise—two sentences front-loaded with the core action. Every sentence serves a purpose: defining the operation and explaining what IDs are needed and the scope requirement. No redundant or extraneous text.
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 tool has 3 parameters, no output schema, and no annotations. The description explains purpose, ID provenance, and scope, but omits the required 'slug' parameter entirely. It also does not mention return values or error handling, which matters since no output schema exists. These omissions make the description incomplete for a delete 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 coverage is 100%, so baseline is 3. The description adds value by noting that remote_event_id can come from calmesh_get_events in addition to calmesh_create_event, and clarifies source_id's role. However, it fails to mention the required 'slug' parameter, listing only remoteEventId and sourceId as requirements, which could confuse an agent about required inputs.
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's action: 'Delete a calendar event from a connected calendar.' The verb 'Delete' and resource 'calendar event' are specific, and the tool is clearly distinct from siblings like calmesh_create_event or calmesh_get_events. The purpose is unambiguous.
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 provides clear usage context: it requires the remoteEventId (from calmesh_create_event or calmesh_get_events) and the sourceId identifying the calendar source. It also notes the 'write' scope requirement. However, it does not explicitly mention alternatives or when-not-to-use scenarios, but the context is sufficient for selecting the 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It states the 'full' scope requirement, which is helpful, and indicates a read-only status check. However, it does not explicitly confirm no side effects, describe error handling, or specify the response format. This is adequate but not rich in detail.
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 two sentences, front-loaded with the primary purpose and then the key auth requirement. Every word earns its place, with no unnecessary detail 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 simple single-parameter status-check tool with no output schema, the description is complete enough: it states the action, the possible statuses shown, and the auth requirement. While it could mention the response format or alternative tools, those are not critical for this straightforward use case.
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 the parameter 'connection_id' clearly described as 'Connection ID to check.' The description adds no extra semantic value beyond the schema, so baseline 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 uses a specific verb ('Check') and resource ('calendar connection'), and clearly states the outcome ('Shows if the connection is active, errored, or disconnected'). It distinguishes itself from sibling tools like list_connections, which lists all connections, by focusing on a single connection's status.
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 checking a specific connection's sync status, but does not explicitly state when to use this instead of alternatives like list_connections or start_oauth_connection. No exclusions or alternative tool mentions are provided, so guidance is only implied.
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 full transparency burden. It discloses the required 'read' scope and mentions returned fields, which is helpful, but it does not address ordering, timezone handling, pagination behavior, or empty-result semantics, leaving gaps.
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 three short sentences with the primary purpose front-loaded. Each sentence adds a distinct fact—purpose, return fields, and auth requirement—with no repetition or filler.
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 no output schema and no annotations, the description covers the core essentials: what it does, the date range, returned fields, and required auth. It does not explicitly differentiate from get_event_details or note ordering, but the schema provides parameter detail and the description is otherwise adequate.
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 has 100% descriptive coverage for all parameters, including examples for start and end, so the baseline is 3. The description adds no meaning beyond the schema, aside from implicitly connecting the date range to start/end.
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 a specific verb 'Get' and resource 'calendar events' scoped by a date range, distinguishing it from sibling tools like get_event_details which targets a single event. It also lists returned fields, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The date-range wording implies when to use the tool, but no explicit alternatives, exclusions, or conditions are mentioned. Sibling tools such as get_event_details exist, yet the description does not guide users toward or away from them.
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 discloses that the tool requires user action in a browser, returns an auth_url, and mandates 'full' scope. It does not mention whether a pending connection record is created or the result of the authorization callback.
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 two sentences, front-loaded with the action, and every clause adds value. It avoids fluff and is easily scanned.
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 one parameter and no output schema, the description covers the essential behavior: the returned auth_url and the required user action. It could be improved by noting that after authorization the user must complete the flow or that a connection status will change, but it is sufficient for a low-complexity 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?
Schema description coverage is 100%, so the description adds no additional meaning beyond the schema's own provider enum and field description. The 'full scope' note is important context but not parameter-related.
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 tool starts an OAuth calendar connection and returns an auth_url for browser authorization. It does not explicitly distinguish from the sibling calmesh_start_credential_connection, but the term 'OAuth' hints at the difference.
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 when to use the tool (for OAuth connections) and mentions a hard requirement ('full' scope), but does not explicitly contrast it with the credential-based alternative or state when not to use it.
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 must carry the transparency burden. It tells the user about the 'full' scope requirement and per-provider credential needs. However, it lacks details about side effects (e.g., creating a connection record), what the response contains (e.g., connection ID), or any error conditions. This is partially helpful but incomplete for a state-changing action.
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 two sentences with no filler. The first sentence immediately states the purpose, and the second sentence compactly details the two modes and the scope requirement. Every clause earns its place.
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 tool with two modes and no output schema, the description covers the main purpose, prerequisites, and mode differences. However, it does not explain what happens after connecting (e.g., how to verify or use the connection) or what response to expect. Given the complexity and lack of output schema, this is a moderate gap in 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?
The input schema already covers all 4 parameters with descriptions, including 'Required for caldav provider' for username and password. The description essentially restates this information in prose ('For CalDAV: server URL, username, and password required') without adding significant new meaning. Since schema coverage is 100%, the baseline is 3, and the description does not elevate beyond that.
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's function: 'Connect a CalDAV server or iCal URL using credentials.' It identifies the specific verb ('Connect'), the resource (CalDAV server or iCal URL), and distinguishes it from the sibling 'calmesh_start_oauth_connection' by emphasizing 'using credentials' and the 'full' scope requirement. The two modes (CalDAV and iCal URL) are explicitly separated.
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 provides clear context for when to use each mode: CalDAV requires server URL, username, and password, while iCal URL only needs the public URL. It also notes the 'full' scope prerequisite. However, it does not explicitly mention avoiding this tool when OAuth is available or name the alternative, though the sibling name implies the distinction.
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 full burden. It discloses the state change ('Marks the poll as decided') and the required scope, but does not mention reversibility, idempotency, or behavior if the poll is already decided. This is adequate but not deeply transparent.
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 two concise sentences that lead with the purpose, then add essential requirement information. There is no filler or redundancy.
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 2-parameter mutation tool with no output schema, the description covers purpose, state change, and scope requirement. It omits details about success/error behavior and edge cases like already-decided polls, but the operation is simple enough that the description is mostly sufficient.
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 describes both parameters (slug and decided_time) with full coverage, so the baseline is 3. The description adds no additional parameter-level guidance beyond what the schema already provides.
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 specific action 'Finalize a poll by selecting the decided meeting time' and identifies the resource (poll) and the state change (Marks the poll as decided). This distinguishes it from sibling poll tools like calmesh_create_poll and calmesh_list_polls.
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 when to use this tool (when a poll needs to be finalized) and provides a prerequisite ('Requires "book" scope'), but it does not explicitly name alternatives or exclusion conditions. The context is clear enough for a distinct action.
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 carries the full burden. It discloses that 'read' scope is required, which implies a non-destructive read operation. However, it does not explicitly state side effects (e.g., read-only, no modifications) or behavior on missing polls, leaving some ambiguity. The scope requirement adds useful context but is not fully comprehensive.
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 two short sentences that front-load the core purpose. Every word earns its place; no filler or redundant information. It is well-structured and easy to scan.
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 tool's simplicity (single parameter, no output schema), the description provides sufficient context for an agent to use it correctly. It explains the purpose, the input (poll), the output type (time slots), and a key prerequisite (read scope). It falls short of a 5 only because it doesn't mention potential edge cases like empty polls or error handling, but these are not critical for such a straightforward 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?
Schema coverage is 100% with a clear 'Poll slug' description, so the baseline is 3. The description adds no additional meaning about the 'slug' parameter beyond what the schema already provides, so no extra credit is warranted.
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's function: 'Get overlapping availability slots for a poll.' It further explains the value ('Shows which time slots work for the most participants'), which distinguishes it from other poll-related tools like calmesh_create_poll or calmesh_decide_poll. The verb 'get' and resource 'poll' are specific and unambiguous.
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 context: analyzing poll results to find the most popular time slots. It clearly indicates this is for retrieving poll overlap data, which is distinct from other tools. However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a 5.
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 carries the burden of disclosing side effects and requirements. It mentions the "book" scope and that it returns visitor-bookable time slots, implying a read-only operation. However, it doesn't state whether it modifies data, handle timezone logic fully, or describe error conditions.
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 action and resource. Every word adds value, with no redundancy or filler.
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?
The tool is relatively simple (3 params, no output schema). The description covers purpose, return value, and auth requirement. It could be more detailed about edge cases, but for its complexity, it's sufficiently 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 description coverage is 100%, so the schema itself defines all parameters clearly. The description adds minimal additional meaning beyond naming the booking page and date. It doesn't explain timezone behavior or input format nuances beyond the 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 tool gets available booking slots for a booking page on a specific date, using a specific verb-resource pair. This distinguishes it from siblings like check_availability, which focuses on broader availability checks.
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 specifies the context (booking page, date) and the required scope ("book"), giving clear guidance on when it's appropriate. It does not explicitly exclude alternatives or name sibling tools, but the use case is unambiguous.
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, the description carries the full burden of behavioral disclosure. It clearly states that the operation returns which parts succeeded and failed, and explicitly mentions the required OAuth scope ('full'). It does not detail reversibility or atomicity, but the core behavioral trait of partial success is disclosed.
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 two sentences, front-loaded with the primary action, and contains no filler or redundant information. Every word contributes to understanding the tool's purpose and key behavior.
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 mutation tool with 6 parameters, no output schema, and no annotations, the description covers the essentials: what it does, key behaviors, and an important prerequisite (scope). It could mention prerequisites like the calendar existing, but the core information is sufficient for an agent to select and invoke it.
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 each parameter is already documented. The description adds minimal extra meaning by grouping the parameters into logical update operations (rename, timezone, connections), but it does not go beyond what the schema descriptions already imply. Baseline 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 clearly states the tool's purpose with a specific verb ('Update') and resource ('a calendar'), enumerating the exact types of updates (rename, change timezone, add/remove connections, set write-back). This distinguishes it from sibling tools like create_calendar and list_calendars.
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 when to use this tool (when you need to update an existing calendar) but does not explicitly mention alternatives or when not to use it. It does provide a usage constraint (requires 'full' scope), but lacks clear guidance on choosing this tool over siblings.
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 adds valuable behavioral context: it returns the booking ID and cancelled status, and it requires 'book' scope. This goes beyond the basic action to inform about output and authorization, though it does not cover edge cases like cancellation of already-cancelled bookings.
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 two short sentences that are front-loaded with the core purpose. Every word contributes necessary information (action, target, ID, return, scope), with no repetition or fluff.
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 single-parameter cancellation tool, the description covers the essential aspects: what it does, how (by ID), what it returns, and a required scope. It lacks details on error conditions or idempotency, but these are not critical for such a straightforward 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?
The input schema already fully covers the one parameter (booking_id) with its description. The tool description adds no additional parameter information, so it does not exceed the baseline of 3.
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 specific action ('Cancel'), the resource ('existing booking'), and the method ('by ID'). This unambiguously distinguishes it from sibling tools like calmesh_create_booking and calmesh_list_bookings.
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 offers clear context: use this tool when you have a booking ID and need to cancel it. It does not explicitly mention alternatives or exclusions, but the situation is clearly implied by the phrasing.
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 carries the burden. It discloses the auth requirement ('full' scope), return value, and partial failure behavior, which are meaningful operational details beyond the schema.
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 action, and no filler. Every sentence adds value: the first states core function, the second covers return behavior and auth prerequisite.
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?
The description covers the main return value and failure mode, and the schema fully documents all parameters. For a create tool with this complexity, it is reasonably complete, though it could briefly mention idempotency or rollback behavior.
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 parameters are already well-documented. The description adds minimal value by clarifying the optional nature of connection_ids, but does not meaningfully enhance 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?
Description uses specific verb 'Create' with clear resource 'new unified calendar' and optional 'attach connection sources'. This clearly distinguishes it from siblings like calmesh_list_calendars and calmesh_manage_calendar.
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?
Implies usage through the create verb and mentions optional attachment of sources, which clarifies intended use cases. However, it does not explicitly contrast with alternatives or state when not to use it beyond requiring 'full' scope.
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 available, the description takes on the full burden of disclosing side effects. It explicitly states that invitation emails are sent, that 'book' scope is required, and that the response includes a shareable URL. This covers key behavioral aspects: authentication, external side effect (emails), and return value. It doesn't mention reversibility or idempotency, but the create operation is inherently a write, and the stated details are strong.
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 two sentences, front-loaded with the core purpose and following with side effects and auth. Every sentence contributes meaningful information: the action, the side effect, the return value, and the required scope. There is no fluff or redundancy.
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 tool's simplicity (6 parameters, no nested objects) and the lack of an output schema, the description sufficiently covers the main aspects: what it does, the email side effect, auth requirement, and return value. It could optionally mention the default duration or how the shareable URL behaves, but the schema already documents parameters. The description is complete enough for an agent to select and use the tool correctly.
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 provides 100% coverage of all six parameters with descriptions, so the baseline is 3. The tool description adds no extra parameter-level detail beyond the schema, such as default values or format specifics. It doesn't worsen or improve the parameter understanding, so the baseline 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 uses a specific verb and resource: 'Create a scheduling poll' and clearly states the additional action 'send invitation emails to participants'. This distinguishes it from siblings like calmesh_create_booking and calmesh_create_event, which create different resource types. It also mentions the return value (shareable URL), further clarifying its purpose.
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 provides clear context: this tool is for creating scheduling polls and emailing invitations. It implies when to use it (when you need to poll multiple participants) without explicitly naming alternatives, but the context is clear enough to guide an agent. It doesn't state when not to use it, but the context distinguishes it from booking or event creation.
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 transparency burden. It explicitly discloses that the tool returns pairs of overlapping events and requires read scope, which gives the agent important behavioral context about safety and output shape. It doesn't cover edge cases like timezone handling or pagination, but for a simple read-only conflict finder this is sufficient.
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 core purpose, and every word earns its place. It states the action, the output, and the access requirement without any filler.
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 simple nature of the tool and no output schema, the description adequately explains what is returned ('pairs of events that overlap') and the required access level ('read' scope). It doesn't address potential edge cases, but the tool is straightforward and the description is sufficient for an agent to select and invoke it correctly.
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 fully describes all three parameters (slug, start, end) with 100% coverage, so the description doesn't need to add much. The phrase 'within a date range' aligns with start/end but doesn't add new meaning beyond the schema. Baseline 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 uses a specific verb ('Find') and identifies the exact resource ('overlapping events/conflicts') plus the scope ('within a date range'). It clearly distinguishes this from siblings like get_events or check_availability by focusing on conflict detection and explicitly stating it returns overlapping pairs.
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 context: use it to find overlapping events in a date range, and notes that it requires 'read' scope. It doesn't explicitly name alternatives or exclusions, but the stated scope and behavior make the appropriate use case obvious.
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 discloses key behavioral traits: it 'Fetches from calendar providers on demand' (indicating a network call) and requires 'read' scope (implying read-only). It also lists the returned fields. While it doesn't cover error handling or rate limits, the disclosure is adequate for a simple read 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 two sentences: first defines the purpose, second adds usage guidance and scope requirement. Every word earns its place, with no redundancy. Front-loaded with the specific verb and resource.
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 3-param tool with no output schema and no annotations, the description provides purpose, usage, behavior, and prerequisites. Slight ambiguity remains in 'full event details' vs the three listed fields, and it does not mention the number of events returned for a range, but overall it is nearly 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 clear descriptions for each param (slug, start, end) including format examples. The description only mentions 'for a date range', which maps to start/end but adds no additional meaning. Per the baseline, with high schema coverage, a 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 clearly states the verb ('Get'), resource ('full event details'), and scope ('for a date range'), with specific fields listed in parentheses. It distinguishes from sibling `calmesh_get_events` by emphasizing 'not just when they occur', making the tool's unique purpose explicit.
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?
It explicitly provides a when-to-use: 'Use this when you need to understand what events are about' and implies when-not-to-use ('not just when they occur'). However, it does not name an alternative tool explicitly, only implying the existence of a separate tool for occurrence times. Also mentions 'Requires read scope' as a prerequisite. Clear context but lacks an explicit alternative.
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 states that the tool returns booking details including visitor info and status, and requires 'book' scope, which are useful operational traits. It does not explicitly say it is read-only, but 'list' implies a non-mutating operation.
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, efficient sentence that conveys purpose, return contents, and scope requirement without any fluff. It is front-loaded with the primary verb and resource.
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 list tool with no output schema, the description covers the essential points: purpose, optional filtering, return data contents, and authentication scope. It does not specify response format or pagination behavior beyond the parameter descriptions, but this is adequate given the tool's simplicity.
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 all three parameters having descriptions. The description adds nominal value by labeling the parameters as 'pagination and filtering', which contextualizes limit/offset and stakeholder_id, but does not significantly augment the schema's own clear documentation.
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 and resource ('List bookings') and explicitly mentions optional pagination and filtering, distinguishing it from sibling tools like create_booking, cancel_booking, and list_calendars. The return details (visitor info, status) further clarify its purpose.
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 provides clear context for when to use this tool (listing bookings with pagination/filtering) and notes the required 'book' scope. It does not explicitly mention alternatives or when not to use it, but the usage scenario is evident.
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 the full burden. It discloses the required auth scope and the content of the output (provider, status, last sync time), which is helpful. However, it doesn't mention whether the operation is read-only (though likely obvious from 'List'), nor does it discuss pagination, rate limits, or errors, leaving some behavioral uncertainty.
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 two short sentences. The first sentence states the primary purpose and user scope; the second adds return details and an auth requirement. Every word earns its place, and it is front-loaded with the action.
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?
The tool is simple (0 params, no output schema), and the description covers the essential points: what it lists, for whom, what it shows, and a prerequisite. It could optionally mention pagination or ordering, but given the low complexity, the description is reasonably complete.
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 0 parameters, so the schema fully covers parameter semantics (vacuously). The baseline for 0 params is 4, and the description adds no unnecessary param information, which 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 uses the specific verb 'List' with the resource 'calendar connections', clearly identifying the operation. It also specifies the return fields (provider, status, last sync time) and the user scope, which distinguishes it from sibling tools like check_connection_status or start_oauth_connection.
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 clear that this tool is for listing all calendar connections for the authenticated user, and it mentions a prerequisite ('Requires full scope'). It does not explicitly name alternative tools for other scenarios, but the context is clear enough that an agent would know when to use it.
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 carries the full burden of disclosing behavioral traits. It explicitly states the destructive nature (removes the connection and stops syncing) and the required scope ('full'). This is valuable context beyond what the name implies, though it does not mention reversibility or side effects on dependent data.
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 consists of three short sentences, each serving a distinct purpose: stating the action, explaining the behavioral effect, and specifying the permission requirement. There is no redundancy or unnecessary detail, and the purpose is front-loaded.
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 single-parameter removal tool with no output schema, the description adequately covers the core function, the consequence of the action, and the required scope. It provides sufficient context for an AI agent to select and invoke the tool correctly, without needing additional return value details.
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 a complete description of the single parameter: 'Connection ID to remove.' The description does not add any additional parameter-specific meaning, so the baseline score of 3 is appropriate given 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 action ('Remove') and the specific resource ('a calendar connection'). It further explains the consequence (disconnects the provider and stops syncing), which distinguishes it from sibling tools like list or start connections. The verb-object structure is unambiguous.
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 provides clear context that this tool removes an existing calendar connection, which implies when it should be used. However, it does not explicitly mention alternatives or state when not to use it. The effect description ('disconnects the provider and stops syncing') helps an agent decide, but there is no direct comparison to other connection-related tools.
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, the description carries the full burden. It discloses the mutation (creates an event), the requirement for 'write' scope or higher, and the default source selection behavior. It could mention potential failure modes, but the key side effects and prerequisites are covered.
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 three sentences, front-loaded with the action, and each sentence contributes: purpose, default target behavior, and prerequisite/scope. There is no wasted text.
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 8 parameters, 100% schema coverage, and no output schema, the description provides essential non-schema information: default target, slug lookup, and required scope. It does not explicitly cover the return value, but that is not mandatory without an output schema, and the description suffices for safe invocation.
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?
All parameters have schema descriptions, so the baseline is 3. The description adds value by explaining the default source_id behavior and directing users to list_calendars for slugs, enriching the semantics of these parameters beyond their schema text.
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 calendar event on a connected calendar, using a specific verb and resource. It distinguishes itself from sibling tools like calmesh_create_booking and calmesh_create_poll by specifying 'calendar event' and explaining the default write target behavior.
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 provides clear context by directing users to calmesh_list_calendars for finding slugs and explains the default write target logic. However, it does not explicitly mention alternatives or when not to use this tool, so it lacks full exclusionary guidance.
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, the description carries the burden. It discloses the return fields (name, slug, timezone, default status) and the required 'read' scope, which helps the agent understand safety and output. It doesn't cover pagination or rate limits, but for a simple list tool, this is sufficient.
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 two concise sentences, each adding meaningful information: what it does and what it returns/requires. No redundant or vague language.
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 no-parameter list tool, the description covers the essential context: purpose, target user, return shape, and auth requirement. It lacks details like ordering or error handling, but these are not critical for a straightforward list operation.
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, so the schema coverage is 100% and the description doesn't need to explain parameters. Per the rubric, a zero-parameter tool receives a baseline score of 4.
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' with a clear resource 'all unified calendars for the authenticated user,' distinguishing it from sibling tools like get_events or create_calendar. It clearly states the action and scope.
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 provides clear context for when to use this tool (when you need to enumerate the user's unified calendars), but it does not explicitly mention alternatives or exclusions. Since the purpose is unambiguous, it earns a 4.
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 discloses that the tool requires 'read' scope and that it returns participant counts and status. This is useful behavioral context beyond the raw action, though it does not cover potential pagination or rate limits. For a simple list operation, this is adequate.
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 two concise sentences, front-loaded with the core action and followed by return info and a scope requirement. Every sentence earns its place with no redundancy.
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 list tool with no parameters and no output schema, the description is largely complete. It explains the purpose, return contents, and required scope. It doesn't mention pagination or ordering, but these are not necessarily expected for a tool that lists 'all' polls. The description is sufficient for an agent to invoke it correctly.
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, so the input schema is trivially fully covered. The description adds no parameter details but doesn't need to; the 'all' wording clarifies that no filtering parameters exist. Baseline for 0 parameters is 4, which 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 clearly states the tool's purpose: 'List all scheduling polls' with a specific verb and resource, and distinguishes it from sibling tools like create_poll and decide_poll. It also specifies what the return includes (participant counts and status), making the purpose unambiguous.
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 gives clear context: use this when you need to list all scheduling polls. It does not explicitly mention alternatives or exclusions, but the scope is well-defined and the 'all' implies no filtering. Since sibling tools are distinct, the usage is reasonably 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:

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

Score Badge

Copy to your README.md:

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

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/davidklemme/calmesh-mcp-server'

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