Read and create SavvyCal scheduling links and booked events.
Scored across 8 tools
Each tool targets a distinct resource and action: event operations (cancel/get/list) versus link operations (duplicate/get/list/toggle/slots). There is no overlap between tools, making selection unambiguous.
All tool names follow a consistent snake_case verb_noun pattern with a uniform savvycal_ prefix. The naming convention is predictable throughout.
Eight tools is well-scoped for a scheduling API covering links and events. Each tool serves a clear purpose without redundancy or bloat.
The set covers listing, retrieving, canceling, duplicating, toggling, and slot retrieval, but lacks a direct create_link or update_link operation. Duplication provides a partial workaround, leaving a minor gap.
Cancel a booked event/meeting. This notifies attendees and frees the slot. SavvyCal REST: DELETE /events/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The event id to cancel. | |
| reason | No | Optional cancellation reason (→ request body { reason }). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare destructiveHint=true, so the description adds real value by disclosing that attendees are notified and the slot is freed, plus the raw DELETE semantics confirming a hard removal. It stops short of covering reversibility, idempotency, or permission requirements, which would be useful for an irreversible mutation.
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 short sentences, front-loaded with the core action, then side effects, then the REST mapping. Nothing is redundant or padded.
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 two-parameter destructive tool with no output schema and destructiveHint already set, the key facts an agent needs (what it does, who gets notified, that it maps to DELETE) are present. The remaining gap is failure/idempotency behavior on an irreversible operation.
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% for both parameters, so the schema already documents 'id' and 'reason' fully. The description adds no format, constraint, or behavioral detail about either parameter, so the 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?
States a specific verb and resource ('Cancel a booked event/meeting') and maps it to the underlying REST call DELETE /events/{id}, which distinguishes it cleanly from read-oriented siblings like savvycal_get_event and savvycal_list_events. An agent can identify the operation without opening the schema.
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 purpose implies when to use it (canceling an existing booking), but there is no explicit guidance on when not to use it or which sibling to prefer. No alternatives such as a soft-delete or reschedule tool are mentioned, so the routing burden falls on the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a copy of an existing scheduling link. SavvyCal REST: POST /links/{id}/duplicate.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The scheduling link id to duplicate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, which tells the agent this is a mutating operation, so the description need not re-establish that. It adds the REST mapping (POST /links/{id}/duplicate) but says nothing about whether the original link is modified, what the new copy inherits, or what the caller receives back. Adequate but thin for a mutating 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?
Two short sentences, zero filler, with the operation stated first and the API endpoint appended as reference. Nothing could be removed without losing information.
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 one-parameter tool with no output schema, the main missing piece is what the duplicate response contains (e.g., whether the new link id is returned), which the agent would need to chain into savvycal_get_link or savvycal_toggle_link. Everything else an agent needs to invoke it is present.
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 single parameter is already fully documented as 'The scheduling link id to duplicate.' The description only restates that an existing link is the target and adds no id format or source guidance, 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 states a specific verb and resource ('Create a copy of an existing scheduling link') and pins down the exact operation, which is plainly distinguishable from the read-oriented siblings like savvycal_get_link and savvycal_list_links. An agent can identify the operation without opening the schema.
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?
There is no when-to-use guidance, no prerequisites (e.g., whether the id must come from savvycal_list_links), and no statement of when duplication is preferable to any alternative. Usage can only be inferred from the tool name and the word 'copy'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single booked event/meeting by id. SavvyCal REST: GET /events/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The event id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the REST mapping (GET /events/{id}), which is mildly informative, but says nothing about error behavior for a missing/invalid id, auth requirements, or response shape.
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 short front-loaded sentences with zero padding: the purpose first, then the underlying REST endpoint. Nothing wastes the agent's attention.
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 one-parameter read tool with a readOnlyHint annotation, the definition covers what the agent needs to invoke it. The main omission is any hint of return contents or not-found behavior, which is minor given there is no output schema.
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% and the single id parameter is already documented in the schema, so the schema carries the load. The description's only added nuance is that the id refers to a booked event/meeting; baseline 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?
States a specific verb (get) and resource (a single booked event/meeting) scoped by id, which cleanly separates it from list_events and the mutation siblings. It stops short of naming an alternative tool, but the 'single ... by id' framing makes the intent 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?
Usage is only implied: retrieve one event when you already have its id. There is no explicit when-to-use, no condition distinguishing it from savvycal_list_events, and no mention of what happens for an unknown id. Adequate but with clear gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single scheduling link by id. SavvyCal REST: GET /links/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The scheduling link id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the REST mapping (GET /links/{id}), which is mildly useful context, but says nothing about error behavior for unknown ids or the shape of what is returned.
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 short sentences with no waste; the core purpose is front-loaded and the REST mapping is a compact secondary detail.
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 single-parameter read tool with readOnlyHint annotations and full schema coverage, the description is sufficient to invoke it correctly. The only omission is any hint about the returned link representation, which is a minor gap absent an output schema.
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% and the sole 'id' parameter is documented in the schema itself. The description's 'by id' adds no format, validation, or source-of-id detail beyond that, so the 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?
States a specific verb and resource ('Get a single scheduling link by id') and the word 'single' implicitly contrasts with the list_links sibling. It does not name an alternative explicitly, so it falls short of full sibling differentiation.
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?
Usage is implied — you call it with an id when you already know which link you want — but the description never states when to use this versus savvycal_list_links or savvycal_get_link_slots. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available booking time slots for a scheduling link. Returns slots with start_at/end_at/duration/rank. SavvyCal REST: GET /links/{id}/slots.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The scheduling link id. | |
| duration | No | Slot duration in minutes to request (→ query param duration). | |
| time_zone | No | IANA time zone for the slots, e.g. America/New_York (→ query param time_zone). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description still adds real value by disclosing the returned slot fields (start_at/end_at/duration/rank) and mapping the call to GET /links/{id}/slots. It stops short of noting auth requirements or slot-count/pagination limits.
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 tightly packed sentences: purpose first, then return shape and endpoint. No filler, nothing redundant, 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?
With no output schema, the description carries the burden of describing returns and does so by naming the slot fields. For a simple read-only retrieval with a fully documented schema this is nearly complete; only rate/availability caveats are missing.
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 all three parameters are already documented including their query-param mapping. The description adds no parameter-level meaning beyond the schema, making the baseline 3 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?
States a specific verb and resource ('Get available booking time slots for a scheduling link'), which is clearly distinct from the sibling list_links/get_link (link metadata) and list_events (booked events). An agent can tell this is the availability query without opening the schema.
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 names no alternatives and gives no conditions for choosing this over savvycal_get_link or savvycal_list_events. Usage is only implied by the resource name; an agent must infer that 'available slots' means availability lookup for scheduling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List booked events/meetings (paginated). SavvyCal REST: GET /events.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max records to return (pagination limit). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the safe-read profile is covered structurally. The description adds one behavioral trait beyond that — that results are paginated — but says nothing about page sizing, cursoring, or ordering, so the added context is thin relative to what a paginated lister could disclose.
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 short sentences, front-loaded with the operation and its scope. Nothing is redundant or padded; even the REST mapping is compressed to a single clause.
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-only lister with full schema coverage and annotations covering safety, the description is nearly sufficient. The remaining gap is the absence of any mention of filtering capabilities or result ordering, which matters for an events list but is not critical 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?
With a single parameter at 100% schema description coverage, the schema fully documents 'limit'. The word 'paginated' loosely corroborates that this is a paging control, but the description contributes no syntax, defaults, or bounds beyond the schema. 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 gives a specific verb and resource ('List booked events/meetings'), and the pagination hint plus the REST mapping (GET /events) make the operation unambiguous. It does not explicitly differentiate itself from siblings like savvycal_get_event or savvycal_list_links, but the resource noun is distinct enough that an agent can route correctly.
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?
There is no statement of when to use this versus savvycal_get_event for a single event, and no mention of whether filtering (by date, link, or attendee) is possible or should be handled elsewhere. The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the authenticated user's scheduling links (paginated). SavvyCal REST: GET /links.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max records to return (pagination limit). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds that results are paginated and maps to the REST endpoint GET /links, which is useful context, but it says nothing about how pagination advances (no cursor/page token is exposed) or what the response contains.
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 short sentences, front-loaded with the action and scope; nothing is padded. The REST endpoint mapping is mildly redundant but harmless.
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-only list tool with an annotated safety profile, no output schema, and one well-documented optional parameter, this is nearly complete. The only gap is that pagination is mentioned without explaining how to page.
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 single optional parameter has 100% schema description coverage, so the baseline is 3. The description only mentions "paginated" generically and adds no meaning beyond the schema's own limit 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?
States a specific verb and resource ("List ... scheduling links") with a clear scope qualifier ("the authenticated user's"). It does not explicitly distinguish itself from savvical_get_link or savvycal_list_events, so an agent must infer the list-vs-get distinction from the names alone.
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?
There is no when-to-use guidance and no mention of alternatives such as savvycal_get_link for a single link. Usage is only implied by the verb "List"; nothing tells the agent when this tool is the right choice over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toggle a scheduling link between active and disabled (changes whether the public booking page accepts bookings). SavvyCal REST: POST /links/{id}/toggle.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The scheduling link id to toggle. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint=true annotation already flags this as a state-changing operation, and the description adds real value beyond it by naming the user-visible consequence (public booking page stops/starts accepting bookings). It still omits that the call flips whatever the current state is (so intent must be reconciled with a prior read) and that no desired end-state can be specified.
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 short sentences with zero padding: the behavioral effect is front-loaded and the REST endpoint follows as supporting detail. Every clause 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 one-parameter, no-output-schema tool, the description covers purpose, effect, and endpoint adequately. The only miss is noting that the toggle is relative to current state (and that the response reflects the new state), which an agent may need in order to avoid redundant flips.
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% and the single parameter is fully documented in the schema ('The scheduling link id to toggle'). The description adds no format, ID-source, or lookup guidance beyond that, so the 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?
States a specific verb (toggle) and resource (scheduling link) plus the concrete effect: flipping between active and disabled and thereby controlling whether the public booking page accepts bookings. This distinguishes it cleanly from siblings like savvycal_get_link and savvycal_duplicate_link.
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?
Usage is implied by the effect statement ('changes whether the public booking page accepts bookings'), so an agent can infer this is the tool for enabling/disabling a link. However there is no explicit when-to-use guidance, no note about the state-dependent nature of a toggle, and no mention of checking current state via savvycal_get_link first.
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.
savvycal_cancel_event1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"savvycal_duplicate_link1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"savvycal_get_event1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"savvycal_get_link1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"savvycal_get_link_slots1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"savvycal_list_events1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"savvycal_list_links1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"savvycal_toggle_link1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"savvycal_cancel_eventsavvycal_duplicate_linksavvycal_get_eventsavvycal_get_linksavvycal_get_link_slotssavvycal_list_eventssavvycal_list_linkssavvycal_toggle_linkRead tasks, habits, events and scheduling links; create and update Reclaim tasks and habits.
Read and write NexHealth appointments, patients, providers and locations.
Read appointments, types, calendars and availability; create, cancel or reschedule bookings.
Read Mindbody classes, schedules, clients, staff and sales; book clients and appointments.
Add one secure layer between your agents and this server.