Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-meetsync Find a time for Alice and Bob to meet for an hour next Tuesday."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for MeetSync — a calendar negotiation API built for AI agents.
Exposes all 19 MeetSync endpoints as MCP tools so any MCP-compatible LLM can autonomously find availability, propose meeting times, and confirm bookings — no human back-and-forth required.
npm install -g mcp-meetsyncOr run directly with npx:
npx mcp-meetsyncRelated MCP server: M365 Calendar MCP Server
The server reads two environment variables:
Variable | Required | Default | Description |
| No |
| Base URL of your MeetSync API |
| Yes | — | API key sent in |
Copy .env.example to .env and fill in your values, or pass them directly in the Claude tool definition.
Paste this snippet into your Claude desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"meetsync": {
"command": "npx",
"args": ["-y", "mcp-meetsync"],
"env": {
"MEETSYNC_API_URL": "https://api.yourmeetsync.com",
"MEETSYNC_API_KEY": "your-api-key-here"
}
}
}
}After saving, restart Claude. The 19 MeetSync tools will appear in Claude's tool list.
All 19 MeetSync operationIds are exposed as tools. Tool names match operationIds exactly.
Tool | When to use |
| Browse or search registered participants |
| Register a new person before they can be scheduled |
| Look up a specific participant's timezone/provider details |
| Change a participant's name, email, timezone, or calendar setup |
| Permanently remove a participant (use |
| Read a participant's working hours and scheduling constraints |
| Define or replace working hours, blackout windows, and buffers |
Tool | When to use |
| Find free windows for a single participant |
| Find scored slots that work for all participants simultaneously |
Tool | When to use |
| Browse pending or historical proposals |
| Propose candidate time slots and send to participants for consensus |
| Check proposal status and see who has responded |
| Withdraw a pending proposal |
| Record a participant's acceptance or rejection |
Tool | When to use |
| Browse confirmed, cancelled, or rescheduled meetings |
| Confirm a booking from an accepted proposal, or book directly |
| Retrieve full details of a specific meeting |
| Move a confirmed meeting to a new time |
| Cancel a meeting permanently |
Here is a complete scheduling workflow an AI agent would follow using these tools:
1. createParticipant ← register alice@example.com
2. createParticipant ← register bob@example.com
3. setParticipantPreferences ← Alice: Mon–Fri 09–17, 15 min buffer
4. setParticipantPreferences ← Bob: Mon–Fri 10–18, no back-to-back
5. findMutualAvailability ← find 60-min slots next week for [alice, bob]
→ returns top 5 scored slots
6. createProposal ← "Budget Review" with top 3 slots, expires in 24h
→ proposal id: prop_abc123
7. respondToProposal ← alice accepts, prefers slot 1
8. respondToProposal ← bob accepts, prefers slot 1
→ proposal auto-transitions to "accepted", acceptedSlotId set
9. getProposal ← confirm acceptedSlotId
10. createBooking ← proposalId + slotId
→ booking confirmed, calendarEventIds written# Install dependencies
npm install
# Type-check without building
npm run typecheck
# Build to dist/
npm run build
# Run in dev mode (auto-reloads)
MEETSYNC_API_URL=http://localhost:3000 MEETSYNC_API_KEY=dev-key npm run devsrc/
index.ts ← MCP Server, ListTools + CallTool handlers, stdio transport
client.ts ← Typed fetch wrapper: GET/POST/PUT/PATCH/DELETE + X-API-Key injection
tools/
participants.ts ← 7 participant tools + handlers
availability.ts ← 2 availability tools + handlers
proposals.ts ← 5 proposal tools + handlers
bookings.ts ← 5 booking tools + handlersEach tool file exports:
A Tool[] array with name, description, and inputSchema (strict JSON Schema)
A handle*Tool(name, args) async function that calls the MeetSync API via client
MIT
Use this tool when a confirmed meeting needs to be permanently cancelled for all participants. If the intent is to move the meeting to a different time rather than cancel it entirely, use rescheduleBooking instead — cancellation is irreversible. Only bookings with status "confirmed" can be cancelled; already-cancelled bookings will return an error.
| Name | Required | Description | Default |
|---|---|---|---|
| bookingId | Yes | UUID of the booking to cancel. |
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.
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.
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.
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.
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.
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.
Use this tool when the organizer needs to withdraw an entire proposal — cancelling it for all participants so no booking can result. Only proposals with status "pending" can be cancelled. Important: this is not the tool to use when a single participant wants to decline. If one participant wants to say no while others continue, call respondToProposal with status="rejected" for that participant instead.
| Name | Required | Description | Default |
|---|---|---|---|
| proposalId | Yes | UUID of the proposal to cancel. |
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.
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.
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.
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.
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.
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.
Use this tool to confirm a meeting. Choose the mode based on how you arrived here: MODE 1 — Proposal-based (used after a proposal workflow): call this when a proposal's status is "accepted". First call getProposal to retrieve the acceptedSlotId, then pass proposalId + slotId (= acceptedSlotId) here. All participant UUIDs are already known from the proposal. MODE 2 — Direct (skipping the proposal workflow): call this when you already know the exact meeting time and want to book immediately. You must provide organizerParticipantId, participantIds (all UUIDs from createParticipant), startTime, and endTime. Use this only when consensus is already established outside of MeetSync. In both modes, conflict detection runs automatically and the call fails if any participant has an overlapping confirmed booking.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the meeting. | |
| description | No | Optional meeting description or agenda. | |
| proposalId | No | (Proposal-based mode) UUID of an accepted proposal. | |
| slotId | No | (Proposal-based mode) UUID of the accepted slot within the proposal. | |
| organizerParticipantId | No | (Direct mode) UUID of the participant organizing the meeting. | |
| participantIds | No | (Direct mode) UUIDs of all participants including the organizer. | |
| startTime | No | (Direct mode) Meeting start as ISO 8601 datetime with timezone offset. | |
| endTime | No | (Direct mode) Meeting end as ISO 8601 datetime with timezone offset. | |
| timezone | No | (Direct mode) IANA timezone for the booking. Defaults to UTC. | |
| location | No | Physical location or meeting room. | |
| conferenceLink | No | Video conference URL. |
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.
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.
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.
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.
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.
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.
Use this tool when you need to register a new person in MeetSync so their calendar can be considered during scheduling. Must be called before a participant can appear in proposals, bookings, or availability queries. Supports Google, Outlook, and iCal providers.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full name of the participant. | |
| Yes | Unique email address. | ||
| timezone | No | IANA timezone identifier (e.g. "America/New_York"). Defaults to UTC. | |
| calendarProvider | No | Calendar integration provider. Defaults to "none". | |
| icalUrl | No | iCal feed URL. Required when calendarProvider is "ical". |
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.
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.
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.
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.
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.
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.
Use this tool when you want to send candidate meeting times to a group and collect their votes before confirming a booking. Prerequisites: every participant in participantIds must already be registered via createParticipant; the organizerParticipantId must be one of the participantIds. Typical sequence: createParticipant for each person → findMutualAvailability to get slots → createProposal with those slots. After creation the proposal is "pending". Each participant must respond via respondToProposal (one call per person). Once all participants accept, the proposal becomes "accepted" and you call createBooking to confirm.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Short title for the proposed meeting (e.g. "Q2 Planning Sync"). | |
| description | No | Optional longer description or agenda. | |
| organizerParticipantId | Yes | UUID of the participant organizing this meeting. Must be in participantIds. | |
| participantIds | Yes | UUIDs of all participants, including the organizer. | |
| candidateSlots | Yes | Proposed time slots for participants to vote on. Provide between 1 and 10. | |
| expiresAt | No | When the proposal expires if not fully responded to. Defaults to 48 hours from creation. | |
| location | No | Optional physical location or meeting room. | |
| conferenceLink | No | Optional video conference URL. |
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.
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.
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.
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.
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.
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.
Use this tool only when you need to permanently and irreversibly erase a participant and all their data. If the goal is simply to stop scheduling someone, use updateParticipant with status="inactive" instead — that preserves their history and can be reversed. deleteParticipant cannot be undone. By default it fails if the participant has active proposals or confirmed bookings; pass force=true only when you explicitly intend to cancel those as well.
| Name | Required | Description | Default |
|---|---|---|---|
| participantId | Yes | UUID of the participant to delete. | |
| force | No | If true, cancel any active proposals and bookings before deleting. Defaults to false. |
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.
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.
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.
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.
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.
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.
Use this tool when you need to find meeting times that work for all participants simultaneously. This is the primary scheduling intelligence tool — call it to get scored candidate slots before creating a proposal. Prerequisites: every participant in participantIds must already be registered via createParticipant (UUIDs required — names and emails are not accepted). Have ready: the UUIDs of all participants, the meeting duration in minutes, and the date range to search. The returned slots are scored 0–1 by suitability (working hours, buffer fit, daily meeting load) and the start/end values can be passed directly into createProposal as candidateSlots.
| Name | Required | Description | Default |
|---|---|---|---|
| participantIds | Yes | UUIDs of all participants who must be available (minimum 2). | |
| durationMinutes | Yes | Required meeting duration in minutes. | |
| startDate | Yes | Start of the search window (YYYY-MM-DD, inclusive). | |
| endDate | Yes | End of the search window (YYYY-MM-DD, inclusive). Max 30 days from startDate. | |
| timezone | No | IANA timezone to express candidate slots in. Defaults to the first participant's timezone. | |
| limit | No | Maximum number of candidate slots to return. Defaults to 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.
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.
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.
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.
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.
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.
Use this tool when you need to retrieve full details about a specific booking — including its status, participants, start/end times, calendar event IDs, and any linked proposal. Useful for confirming a booking was created successfully or for building a summary to share with participants.
| Name | Required | Description | Default |
|---|---|---|---|
| bookingId | Yes | UUID of the booking to retrieve. |
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.
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.
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.
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.
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.
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.
Use this tool when you already have the participant's UUID and need to look up their details — timezone, calendar provider, or status. Prerequisite: you must have the UUID from a prior createParticipant or listParticipants call. If you only have a name or email address and need the UUID, call listParticipants first. Note: this does not return scheduling preferences — call getParticipantPreferences for that.
| Name | Required | Description | Default |
|---|---|---|---|
| participantId | Yes | UUID of the participant. |
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.
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.
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.
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.
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.
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.
Use this tool when you need to inspect the free time windows for exactly one participant — for example, to verify they are free at a specific time before booking directly, or to understand one person's constraints before a conversation. Do not use this for group scheduling — if you need a time that works for multiple people at once, call findMutualAvailability instead. Prerequisite: you must have the participant's UUID from createParticipant or listParticipants.
| Name | Required | Description | Default |
|---|---|---|---|
| participantId | Yes | UUID of the participant whose availability you want. | |
| startDate | Yes | Start of the date range to check (YYYY-MM-DD, inclusive). | |
| endDate | Yes | End of the date range to check (YYYY-MM-DD, inclusive). Max 30 days from startDate. | |
| timezone | No | IANA timezone to express results in. Defaults to the participant's own timezone. | |
| minDurationMinutes | No | Exclude free windows shorter than this. Defaults to 30. |
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.
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.
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.
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.
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.
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.
Use this tool when you need to read a participant's scheduling preferences — working hours by day, blackout windows, buffer time between meetings, and maximum meetings per day. Important: getParticipant does not return preferences; you must call this tool separately. Call this before setParticipantPreferences if you only want to update some fields, since setParticipantPreferences replaces the entire preference object.
| Name | Required | Description | Default |
|---|---|---|---|
| participantId | Yes | UUID of the participant. |
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.
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.
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.
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.
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.
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.
Use this tool when you need to inspect a specific proposal — to see its current status, check which participants have and have not yet responded, or retrieve the acceptedSlotId you will need to pass into createBooking once the proposal is accepted. If you do not have the proposalId, call listProposals first.
| Name | Required | Description | Default |
|---|---|---|---|
| proposalId | Yes | UUID of the proposal to retrieve. |
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.
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.
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.
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.
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.
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.
Use this tool when you need to retrieve confirmed, cancelled, or rescheduled meetings. Supports filtering by participant, status, and time range. Call this to check a participant's upcoming meetings or to find a specific booking before rescheduling or cancelling it.
| Name | Required | Description | Default |
|---|---|---|---|
| participantId | No | Filter to bookings that include this participant. | |
| status | No | Filter by booking status. | |
| startAfter | No | Return bookings that start after this ISO 8601 datetime. | |
| startBefore | No | Return bookings that start before this ISO 8601 datetime. | |
| page | No | ||
| limit | No |
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.
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.
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.
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.
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.
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.
Use this tool when you need to find participants and you do not yet have their UUID — for example, when you only know their name or email address. Also use it to verify a person is registered before scheduling, or to enumerate all active participants. If you already have a participant's UUID, use getParticipant instead.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter participants by status. | |
| page | No | Page number (1-based). | |
| limit | No | Results per page. |
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.
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.
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.
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.
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.
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.
Use this tool when you need to browse existing meeting proposals — for example, to check whether a proposal is still pending, to find proposals involving a particular participant, or to audit all pending proposals before creating a new one. Supports filtering by status and organizer.
| Name | Required | Description | Default |
|---|---|---|---|
| organizerParticipantId | No | Filter to proposals created by this participant. | |
| participantId | No | Filter to proposals that include this participant. | |
| status | No | Filter by proposal status. | |
| page | No | ||
| limit | No |
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.
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.
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.
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.
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.
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.
Use this tool when you need to move a confirmed meeting to a new time. The new startTime must be in the future. Conflict detection runs automatically for all participants. Only bookings with status "confirmed" can be rescheduled.
| Name | Required | Description | Default |
|---|---|---|---|
| bookingId | Yes | UUID of the booking to reschedule. | |
| startTime | Yes | New start time as ISO 8601 datetime with timezone offset. Must be in the future. | |
| endTime | Yes | New end time as ISO 8601 datetime with timezone offset. | |
| reason | No | Optional reason for the reschedule. |
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.
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.
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.
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.
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.
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.
Use this tool to record one participant's response (accept or reject) to a meeting proposal. This must be called once per participant — if a proposal has 3 participants, you must call this tool 3 separate times, once for each participantId. Call getProposal first to see which participants have not yet responded (check the responses array). When accepting, the participant can indicate a preferredSlotId from the proposal's candidateSlots. Once every participant has responded and all accepted, the proposal automatically becomes "accepted" and you can then call createBooking (proposal-based mode) to confirm the meeting.
| Name | Required | Description | Default |
|---|---|---|---|
| proposalId | Yes | UUID of the proposal being responded to. | |
| participantId | Yes | UUID of the participant submitting their response. | |
| status | Yes | "accepted" to agree to the proposal, "rejected" to decline. | |
| preferredSlotId | No | UUID of the participant's preferred slot within the proposal (only used when status is "accepted"). | |
| note | No | Optional message to include with the response (e.g. reason for rejection). |
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.
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.
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.
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.
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.
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.
Use this tool when you need to set a participant's scheduling preferences: working hours, blackout windows, buffer time, and daily meeting cap. WARNING — this is a full replacement, not a partial update: any preference not included in your call reverts to its default value, which will silently overwrite existing settings. If you only want to change one field (e.g. bufferMinutes), call getParticipantPreferences first to read the current values, then send the full merged object back here.
| Name | Required | Description | Default |
|---|---|---|---|
| participantId | Yes | UUID of the participant. | |
| workingHours | No | Working hours keyed by day of week (monday–sunday). Each day has start/end in HH:MM format and an enabled flag. | |
| blackoutWindows | No | Recurring unavailable time blocks (e.g. lunch, standup). | |
| bufferMinutes | No | Minimum gap (minutes) between consecutive meetings. | |
| maxMeetingsPerDay | No | Maximum number of meetings per calendar day. |
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.
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.
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.
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.
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.
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.
Use this tool when you need to change a participant's name, email, timezone, or calendar provider, or when you want to soft-deactivate a participant by setting status to "inactive". Only the fields you supply are changed (partial update — other fields stay as-is). Prefer this over deleteParticipant when you want to stop scheduling someone without erasing their history.
| Name | Required | Description | Default |
|---|---|---|---|
| participantId | Yes | UUID of the participant to update. | |
| name | No | Updated full name. | |
| No | Updated email address. | ||
| timezone | No | Updated IANA timezone identifier. | |
| calendarProvider | No | Updated calendar provider. | |
| icalUrl | No | Updated iCal URL (required if switching to ical provider). | |
| status | No | Set to "inactive" to soft-deactivate. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.0.0cancelBookingcancelProposalcreateBookingcreateParticipantcreateProposaldeleteParticipantfindMutualAvailabilitygetBookinggetParticipantgetParticipantAvailabilitygetParticipantPreferencesgetProposallistBookingslistParticipantslistProposalsrescheduleBookingrespondToProposalsetParticipantPreferencesupdateParticipantEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Calendar API for AI agents: events, availability, Google/Microsoft setup, scheduling, and iCal.
Scheduling infrastructure for AI agents across Google and Microsoft calendars.
Agent-first meeting schedule polls for humans and agents. Create polls, vote, find times.
AI-native scheduling and booking: check availability, book meetings, share links.
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
