mcp-meetsync

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose, with detailed descriptions that explicitly differentiate similar actions (e.g., cancelBooking vs. cancelProposal vs. rescheduleBooking). Descriptions warn against misuse and guide correct tool selection, eliminating ambiguity.
Naming Consistency5/5
All tool names consistently follow the verbNoun pattern in camelCase (e.g., createProposal, findMutualAvailability, setParticipantPreferences). Verbs are descriptive and predictable, with no mixing of conventions or vague names.
Tool Count4/5
19 tools cover the full scheduling domain, but the count slightly exceeds the ideal 3-15 range for a well-scoped set. Still, each tool earns its place for participant, proposal, booking, and availability management, so the slight excess is reasonable.
Completeness5/5
The tool surface covers the complete lifecycle: participant CRUD plus preferences, proposal creation/response/cancellation, booking CRUD with rescheduling, and availability lookup (individual and group). No obvious gaps are present for the stated purpose of meeting scheduling.
Average 4.4/5 across 19 of 19 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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 provided, so description must fully convey behavior. It does not mention pagination, default limit, sorting, or what happens without filters. The read-only nature is implied but not stated. This is a significant gap 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?
Three concise sentences that front-load purpose, followed by filtering capabilities and an example use. No waste.
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?
Missing output schema, no mention of response format, default sorting, or pagination limits. For a list tool with 6 parameters, the description should cover these to be complete.
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 descriptions cover 4 of 6 parameters, but the description adds no extra insight beyond the schema. The 'page' and 'limit' parameters lack descriptions, and the description does not explain pagination behavior. Schema description coverage at 67% is moderate, but the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'retrieve confirmed, cancelled, or rescheduled meetings' and gives examples, making purpose clear. However, it does not strongly differentiate from sibling tools like getBooking (singular) or listParticipants.
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 explicit usage contexts: 'when you need to retrieve meetings', 'check a participant's upcoming meetings', 'find a specific booking before rescheduling or cancelling'. This guides when to use the tool, though it could mention when not to (e.g., for a single booking use getBooking).
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 the full burden. It does not explicitly state that the tool is read-only, nor does it disclose any side effects, rate limits, or error conditions. The read-only nature is implied but not guaranteed.
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?
Three concise sentences: (1) purpose and use case, (2) when not to use with alternative, (3) prerequisite. No redundancy, front-loaded, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for usage intent but lacks details about return format and behavior (e.g., does it return free windows or busy slots? Pagination? Defaults for timezone and minDurationMinutes are mentioned in schema, not description. No output schema provided.
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 input schema already documents all parameters. The description adds a prerequisite context (participantId from other tools) but does not enhance parameter semantics 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's purpose: inspect free time windows for exactly one participant. It specifies use cases (verify availability before booking, understand constraints) and explicitly distinguishes from the sibling tool findMutualAvailability for group scheduling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use (single participant) and when not to (group scheduling, recommending findMutualAvailability instead). It also includes a prerequisite: the participant's UUID from createParticipant or listParticipants.
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 must disclose behavioral traits. It mentions conflict detection and status validation but omits important details like whether notifications are sent, if the previous slot is freed, or permission requirements. It provides some transparency 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?
Four concise sentences, each adding essential information. The purpose is front-loaded, and every sentence earns its place without redundancy or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key constraints but lacks any mention of what the tool returns (e.g., success indication, updated booking object) or error conditions. Given no output schema, this is a 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?
Schema coverage is 100%, so the description adds limited value beyond restating constraints. It mentions 'conflict detection' and 'only confirmed' status, which are not in the schema, but does not elaborate on the 'reason' parameter or output 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 verb ('move'), resource ('a confirmed meeting'), and specific constraints (new time, only confirmed bookings). It distinguishes from siblings like 'cancelBooking' and 'updateParticipant' by focusing on rescheduling.
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 explicitly states when to use the tool ('when you need to move a confirmed meeting') and includes conditions (future start time, conflict detection, confirmed status). However, it does not mention explicit alternatives, which would raise it to 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?
No annotations are provided, so the description must carry the behavioral information. It states that the participant's calendar will be considered during scheduling, which implies a read/write side effect. It also lists supported providers (Google, Outlook, iCal). However, it does not disclose authentication requirements, rate limits, or what happens if the participant already exists. This is adequate 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?
Three sentences, each serving a distinct purpose: what the tool does, when to use it, and provider support. No wasted words; front-loaded with the main 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 has 5 parameters, one conditional, and no output schema or annotations. The description explains the prerequisite (must be called before other operations) and provider support. It lacks return value information and error handling details, but given the complexity, it 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?
Input schema has 100% description coverage, so the baseline is 3. The description adds value by noting that 'icalUrl is required when calendarProvider is "ical"', which is not conveyed in the individual parameter descriptions. This extra context justifies a 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 clearly states the tool's purpose: 'register a new person in MeetSync so their calendar can be considered during scheduling.' This provides a specific verb and resource, and distinguishes it from siblings like deleteParticipant and updateParticipant.
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 explicitly states when to use this tool: 'Must be called before a participant can appear in proposals, bookings, or availability queries.' It does not mention when not to use or alternatives, but the context is clear and actionable.
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. It discloses that returned slots are scored 0–1 by suitability based on working hours, buffer fit, and daily meeting load. It also states that start/end values can be passed into createProposal. This provides good insight into the tool's behavior, though it could mention whether the tool is read-only (it appears to be, but not explicitly stated).
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 focused paragraph that covers purpose, prerequisites, and output usage. Every sentence provides value, and the information is well-organized. It could be slightly more structured (e.g., bullet points for prerequisites), but it is appropriately concise for the complexity of the tool.
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 the lack of an output schema, the description partially explains the return format (scored slots with start/end values) but does not detail all fields in the response. This could hinder an agent's understanding of the full output. For a tool with no output schema, a more complete description of the return structure would be beneficial.
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 coverage is 100%, so baseline is 3. The description adds significant context beyond the schema: it explains that participantIds must be UUIDs from createParticipant, defines the scope of durationMinutes and date range, and notes that the timezone defaults to the first participant's timezone. This enhances the agent's understanding of how to use the parameters correctly.
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 that the tool finds meeting times for all participants simultaneously and positions itself as the primary scheduling intelligence tool. It also distinguishes itself by noting that the returned slots can be passed directly into createProposal, which differentiates it from sibling tools like getParticipantAvailability.
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 guidance on when to use the tool ('when you need to find meeting times that work for all participants') and lists prerequisites (participants must be registered via createParticipant, UUIDs required). It does not explicitly state when not to use it, but the context is sufficient for an agent to understand its primary use case.
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 mentions filtering by status and organizer but does not disclose behavioral details such as pagination behavior (page/limit parameters exist but are unexplained), ordering, or whether the tool is read-only. This is adequate but not thorough.
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 concise sentences, front-loaded with the usage guidance. Every sentence adds value 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?
Given the tool has five parameters, no output schema, and no annotations, the description provides a good overview of purpose and typical use cases. It is missing details about pagination and return format, but it is reasonably complete for a list tool with clear parameters.
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 60% (descriptions for three out of five parameters). The description adds context for filtering by status and organizer but does not cover the participantId filter or explain the page and limit parameters. It adds minimal value 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's purpose: browsing existing meeting proposals. It provides specific examples (check pending, find by participant, audit) and distinguishes itself from sibling tools like getProposal or createProposal by focusing on listing and filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this tool when you need to browse existing meeting proposals' and gives concrete use cases. It implies alternatives exist for modifying proposals, as sibling tools like cancelProposal, createProposal, and respondToProposal are listed separately.
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?
Discloses that conflict detection runs automatically and the call fails on overlap. No annotations exist, so the description carries full burden; it adequately informs about behavior but could mention side effects like creation persistence.
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?
Structured into clear modes with numbered instructions. While well-organized, it is slightly verbose; concise mode labels and a list could reduce length without losing meaning.
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 11 parameters, no output schema, and two modes, the description provides sufficient workflow context and conflict detection notes. It lacks return value details but compensates with mode-specific parameter guidance.
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 coverage is 100%, so baseline is 3. The description adds value by grouping parameters by mode and explaining relationships (e.g., proposalId and slotId come from getProposal), exceeding the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to confirm a meeting. It explains two distinct modes (proposal-based and direct) and how to use each, effectively distinguishing this from siblings like createProposal and cancelBooking.
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 explicit guidance on when to use each mode, including prerequisite steps (e.g., calling getProposal for proposal-based mode). However, it does not explicitly state when not to use the tool, but the context makes it clear that this is for finalizing a booking.
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 provided, so description must disclose behavior. It accurately describes a read-only retrieval operation, lists the returned data, and implies no side effects. It does not mention error handling or permissions, but for a simple getter 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 purpose, no unnecessary words. Every sentence adds value.
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?
Despite lacking an output schema, the description enumerates the returned fields and provides practical usage examples. For a single-parameter read operation, it is 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?
Parameter schema already has full coverage (UUID description). The description does not add extra semantics beyond the schema's definition, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'retrieve full details about a specific booking' and lists the included fields (status, participants, times, event IDs, proposal). It clearly distinguishes from siblings like listBookings which lists multiple 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 explicitly says 'Use this tool when you need to retrieve full details' and provides concrete use cases (confirming creation, building summary). It lacks explicit when-not-to-use or alternative tools, but the context is clear enough.
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 does not disclose behavioral traits beyond listing (e.g., that it is non-destructive or any rate limits). The mention of 'active participants' slightly contradicts the schema which also includes inactive status, but this is minor.
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 concise, with two sentences that front-load the primary purpose and immediately provide usage guidance. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and no output schema, the description covers all essential aspects: when to use, what it returns (list of participants), and how it differs from siblings. It is complete for the context.
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% description coverage, so the baseline is 3. The description does not add additional meaning beyond what is already in the schema parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: finding participants without UUID, verifying registration, and enumerating active participants. It distinguishes from getParticipant by specifying the prerequisite (UUID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (when no UUID, need to verify or enumerate) and when to use the alternative (getParticipant if UUID is known), providing clear 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?
Without annotations, the description fully bears the burden of behavioral disclosure. It reveals that the proposal starts as 'pending', each participant must respond via respondToProposal, and once all accept it becomes 'accepted' leading to createBooking. It mentions default expiration (48 hours) but does not specify behavior on rejections or partial responses, keeping it slightly short of a perfect score.
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 relatively concise but front-loads the purpose. It consists of 5 sentences, each contributing to clarity. It could potentially be shortened slightly without losing information, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description provides a complete picture: the tool's role in the workflow, prerequisites, lifecycle, and chaining with sibling tools. It covers all critical aspects for correct agent usage, missing only minor edge cases like rejection handling.
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 100% description coverage for all 8 parameters, so the description needs to add minimal value beyond schema. It does not elaborate on parameter meaning beyond what is in the schema, meeting 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 identifies the tool's purpose: 'send candidate meeting times to a group and collect their votes before confirming a booking'. The verb 'create' combined with the resource 'Proposal' is specific, and the description distinguishes it from sibling tools like findMutualAvailability and createBooking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Use this tool when you want to...'), provides prerequisites (all participants must be registered, organizerParticipantId must be in participantIds), and gives a typical usage sequence (createParticipant → findMutualAvailability → createProposal). It also indicates subsequent steps (respondToProposal, then createBooking).
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. It discloses that only pending proposals can be cancelled and that cancellation affects all participants. However, it does not mention whether the action is reversible or any post-cancellation behaviors, leaving minor 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 extremely concise—two sentences plus a clarifying note—with no redundant or unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is complete: it covers purpose, usage, preconditions, and alternatives. No additional information is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description for proposalId. The description adds no extra parameter details beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'withdraw' (cancel) and the resource 'proposal', and explicitly distinguishes it from the sibling 'respondToProposal' for single participant rejection. It specifies that it cancels the entire proposal for all participants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use (organizer withdraws entire proposal, only pending status) and when-not-to-use (single participant decline) guidance, and directs to the alternative tool 'respondToProposal'.
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?
The description clearly implies a read-only operation by stating 'read a participant's scheduling preferences,' but it does not explicitly declare that the tool has no side effects, especially in the absence of annotations. While the read intent is unambiguous, a more explicit statement about non-mutation would increase transparency. Score 4 reflects minor omission.
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, each serving a distinct purpose: stating the tool's function, warning about a sibling limitation, and providing usage best practices. There is no redundant or filler content, 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is complete. It explains what data is returned (preferences components) and supplies context about sibling tools and usage sequencing. No further details (e.g., error handling, pagination) are necessary 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?
The input schema has 100% coverage with a single parameter (participantId) already documented as a required UUID. The description does not add any additional semantics about this parameter beyond what the schema already provides. The baseline for high coverage is 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 explicitly states the tool reads a participant's scheduling preferences and lists the components (working hours, blackout windows, buffer time, max meetings per day). It distinguishes itself from the sibling getParticipant by noting that getParticipant does not return preferences, making the purpose clear and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance ('Use this tool when you need to read a participant's scheduling preferences'), a when-not-to-use note (getParticipant does not return preferences), and a usage recommendation relative to setParticipantPreferences ('Call this before setParticipantPreferences if you only want to update some fields, since setParticipantPreferences replaces the entire preference object'). This is comprehensive and educational.
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. It implies a read-only operation (inspect, see, check, retrieve) but does not explicitly state that no changes are made or mention any side effects. The description is sufficient for a simple retrieval tool, but explicit read-only confirmation would be ideal.
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 concise: three sentences that front-load the main purpose, list specific use cases, and provide a conditional instruction. No unnecessary words, every sentence contributes meaning.
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 no output schema, the description adequately describes the type of return data (status, participant responses, acceptedSlotId). It covers enough for an agent to understand what to expect, though a full list of properties would be more 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 input schema has 100% coverage for the single parameter proposalId. The description adds value by advising how to obtain the parameter (via listProposals if missing) and explaining that the output includes key data like acceptedSlotId, which is useful context beyond the schema's type description.
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: inspect a specific proposal. It lists concrete use cases (status, participant responses, acceptedSlotId) and distinguishes from sibling listProposals by advising to call that first if no proposalId is available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage instructions: use when you need to inspect a specific proposal, and if you lack the proposalId, call listProposals first. Also explains that the acceptedSlotId is needed for createBooking, offering clear context on when this tool is appropriate.
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, so description carries full burden. It discloses that the tool must be called per participant, the auto-acceptance condition, and the follow-up action. Lacks details on error states but sufficient for a recording 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?
Three sentences, each with purpose. Front-loaded usage guide, no wasted words. Efficiently conveys necessary workflow.
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?
Covers the workflow fully, mentions pre-step (getProposal) and post-step (createBooking). Missing error handling (e.g., duplicate responses) but complete for typical use.
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 coverage is 100%, baseline 3. Description adds context: preferredSlotId only for 'accepted', participantId per participant, and linking to candidateSlots. Adds value beyond 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 it records a participant's response to a meeting proposal, specifying the verb 'record' and the resource. It distinguishes from siblings like createProposal and getProposal by focusing on the response action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: after calling getProposal, once per participant. Provides a step-by-step workflow and mentions the follow-up call to createBooking after all accepted. Clear distinction from alternatives.
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?
Given no annotations, the description carries full burden. It discloses irreversibility and preconditions, but could add more about side effects (e.g., notifications). Still, it covers key behavioral traits well.
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 concise sentences, front-loaded with purpose and usage. No wasted words. Every sentence earns its place.
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 tool with one parameter and no output schema, the description covers purpose, usage, preconditions, side effects, and error conditions. It is complete and sufficient.
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 coverage is 100%, so baseline is 3. The description adds value by stating that bookingId must belong to a confirmed booking, providing usage context beyond the schema's type and format.
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 cancels a confirmed meeting permanently for all participants, distinguishing it from rescheduleBooking by specifying when to use each. It uses a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (confirmed meetings needing permanent cancellation), when not to (use rescheduleBooking for time changes), and includes a prerequisite (only 'confirmed' bookings). It also warns about errors for already-cancelled bookings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the critical behavioral trait of full replacement, warning that omitted preferences revert to defaults. Since no annotations are provided, the description carries the full burden, and it does so effectively, alerting the agent to a potentially destructive side effect.
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 long, front-loads the purpose, and uses a clear warning format. Every sentence serves a purpose: stating use case, listing fields, and warning about replacement behavior. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects) and absence of output schema, the description adequately covers the scenario. It explains the full-replacement behavior, guides partial updates, and references the read tool. This is sufficient for correct invocation.
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 has 100% coverage with descriptions for every parameter. The description adds no per-parameter semantics but provides overarching behavioral context. Baseline 3 is appropriate as the description does not detract but adds limited extra value beyond 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's action ('set a participant's scheduling preferences') and enumerates the specific fields it manages (working hours, blackout windows, buffer time, daily meeting cap). It also distinguishes itself from sibling tool 'getParticipantPreferences' by implying a complementary relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool ('when you need to set a participant's scheduling preferences') and when not to (if only changing one field, recommending a read-then-write pattern). It provides clear guidance on avoiding data loss.
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 discloses partial-update behavior (only supplied fields change) and soft-deactivation via status. It could mention more about idempotency or authorization, but the key behavior is 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?
Three sentences, all essential: purpose, partial-update clarification, and sibling differentiation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description fully explains the tool's purpose, behavior, and when to use alternatives. It covers soft-deactivation and partial update clearly.
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 coverage is 100%, so baseline is 3. The description adds value by explicitly stating it's a partial update and listing the common fields to update, reinforcing the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'update', the resource 'participant', and lists exactly which fields can be changed (name, email, timezone, calendar provider, status). It also distinguishes itself from the sibling deleteParticipant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Prefer this over deleteParticipant when you want to stop scheduling someone without erasing their history.' This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: permanence, irreversibility, failure by default if participant has active proposals/bookings, and force=true cancels those. All key traits 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?
Three sentences, each earning its place: purpose+contrast, alternative, nuance. No wasted words. Front-loaded with the critical usage instruction.
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 deletion tool with no output schema, the description covers prerequisites (active proposals/bookings), behavior with force, and alternative. It is complete given the tool's complexity.
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 coverage is 100% with descriptions. The description adds context: force=true is for cancelling active proposals/bookings, and implies default behavior. It adds value beyond the schema but does not detail the UUID format beyond what's in 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 permanently and irreversibly erases a participant and all their data. It distinguishes from updateParticipant for deactivation, and uses specific verbs like 'erase' and 'delete'. The resource and action are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this tool only when you need to permanently and irreversibly erase a participant'. Provides alternative (updateParticipant for inactivation) and warns about force=true. Excellent guidance on when and when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses what is returned, what is not (scheduling preferences), and the prerequisite. No contradictions.
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 efficient sentences, logically flow from purpose to prerequisite to boundary, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple lookup tool: covers what is returned, what is not, and how to obtain the input.
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 description adds context that the participantId UUID comes from prior create/list calls, enriching the schema's minimal description.
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: to look up participant details (timezone, calendar provider, status) using their UUID, distinguishing it from siblings like getParticipantPreferences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use (when UUID is known), prerequisite (UUID from prior call), and alternative (listParticipants for name/email).
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-meetsync MCP server](https://glama.ai/mcp/servers/nicholasemccormick/mcp-meetsync/badges/card.svg)](https://glama.ai/mcp/servers/nicholasemccormick/mcp-meetsync)

Score Badge

Copy to your README.md:

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

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/nicholasemccormick/mcp-meetsync'

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