Cloud-native, serverless Model Context Protocol (MCP) server using Streamable HTTP (https://brightcanoe.com/api/mcp) that enables AI agents like Claude and Cursor to check live calendar availability, create appointments, search Client 360 CRM records, and retrieve 24/7 AI voice receptionist call logs.
Scored across 9 tools
Each tool has a distinct resource and action: booking creation/cancellation, availability lookup, upcoming bookings, analytics, business profile, and separate CRM search/get/update operations. Client retrieval by email versus client search versus notes update are clearly differentiated.
All tool names use a consistent brightcanoe_ prefix followed by snake_case verb_noun phrasing. The convention is predictable across booking, analytics, profile, and client tools.
Nine tools is well-scoped for an appointment booking and client CRM server. Each tool covers a meaningful operation without obvious redundancy.
Core booking and CRM workflows are covered, including create/cancel, availability, upcoming bookings, analytics, and client lookup/update. Minor gaps exist, such as no explicit booking reschedule/update tool or client creation tool, though cancel-and-recreate may work around the former.
Cancel an existing appointment.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Optional reason for cancellation | |
| appointmentId | Yes | The unique ID of the appointment to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden for a destructive mutation. It does not say whether cancellation is reversible, whether the freed slot is released or the client is notified, what error occurs for an already-cancelled or unknown ID, or whether the reason is surfaced anywhere.
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?
A single front-loaded sentence with no filler. It is efficient, though its brevity is partly under-specification rather than disciplined restraint.
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 no-annotation mutation tool with no output schema, the definition should cover irreversibility, error conditions, and side effects. None of that is present, leaving an agent unable to predict what a successful or failed cancellation does.
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 both appointmentId and reason documented in the schema itself. The description adds no syntax, format, or constraint detail beyond that, so the baseline of 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 ('Cancel an existing appointment'), which is unambiguous and clearly distinct from the sibling create_booking. It stops short of naming the boundary against update-style siblings, but the operation itself is clear.
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 guidance on when to use this versus alternatives, nor on preconditions such as whether the appointment must be in a cancellable state. The word 'existing' hints that the ID must resolve, but the agent gets no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a new confirmed appointment for a client.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date in YYYY-MM-DD format | |
| time | Yes | Time in HH:MM format (24h or AM/PM) | |
| notes | No | Appointment notes or intake details | |
| clientName | Yes | Client full name | |
| clientEmail | Yes | Client email address | |
| clientPhone | No | Client phone number | |
| serviceName | Yes | Name of the service |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and only supplies the word 'confirmed', which hints that no separate confirmation step exists but never says whether the client is emailed, whether conflicting slots are rejected, or whether the call fails on an invalid time. For a write operation with real-world side effects, this is a significant disclosure gap.
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?
A single front-loaded sentence with no filler or redundancy. It is efficient but so terse that nothing useful is front-loaded beyond the bare purpose.
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 seven-parameter, five-required mutation with no annotations and no output schema, the description says nothing about what happens on success, what identifier is returned, or what preconditions must hold. An agent could not call this confidently without guessing about conflict handling and notifications.
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 every one of the seven parameters, including date/time formats and which five are required, is already documented in the schema. The description adds only the notion that the record belongs to 'a client', which is already evident from clientName and clientEmail; 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 — 'Schedule a new confirmed appointment' — which is unmistakable. It does not distinguish itself from siblings like brightcanoe_get_available_slots or brightcanoe_cancel_booking, so the agent gets no help discriminating between them.
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, and no mention of the obvious alternative workflow (checking brightcanoe_get_available_slots before booking). The agent must infer the entire usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get business analytics summary including bookings, revenue, and active clients.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden and adds only the metric list. It does not disclose the aggregation period (all-time? current month?), whether figures are scoped to the authenticated business, what permissions are needed, or whether results are cached. For an analytics tool, the missing time window is a material 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?
A single tight sentence with no filler, front-loading the verb and resource. It is efficient, though the terseness comes at the cost of the behavioral and scoping details an agent needs.
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?
No annotations and no output schema mean the description must explain the return shape, and it only names three broad categories without saying what fields, what format, or over what time horizon. For a zero-parameter analytics endpoint whose entire value is its output, this leaves the agent guessing about the result and its scope.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The only gap is that no parameters existing means any filtering (date range, client) must be done elsewhere, which is not explained.
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?
Clear verb ('Get') and resource ('business analytics summary') with an enumeration of the metric categories covered (bookings, revenue, active clients). It reads distinctly against siblings like get_business_profile or get_upcoming_bookings, which are record-level rather than aggregate. It stops short of saying how this differs from a business profile snapshot.
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 word 'summary' implies this is the aggregate roll-up one should call instead of looping over booking or client tools, but that routing is never stated. No when-to-use, when-not-to-use, or named alternative is given. Usage is inferable only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find open appointment slots for a specific date or date range.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date in YYYY-MM-DD format (e.g. 2026-08-20) | |
| serviceId | No | Optional ID of the service to check availability for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and it discloses almost nothing behavioral: not that it is read-only/no side effects, nothing about timezone or business-hours interpretation, no rate limits, and no indication of what an empty result means. It also says 'or date range' when the schema accepts only a single date, leaving ambiguity about range behavior.
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?
A single front-loaded sentence with no filler. It is efficiently written, though the efficiency comes partly from omitting information the agent would need.
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 annotations and no output schema, the description should explain what comes back (slot list shape, timezone of returned times, empty-result meaning). None of that is present, and the 'date range' phrasing conflicts with the single-date parameter, so gaps remain for a core booking-workflow lookup.
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 both parameters are already documented with format examples (YYYY-MM-DD) and the serviceId's purpose. The description adds no semantics beyond the schema, which is the expected baseline when the schema does the work.
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?
Clear verb ('Find') and resource ('open appointment slots') with a scope (date or date range). An agent can distinguish it from siblings like brightcanoe_get_upcoming_bookings (existing bookings) and brightcanoe_create_booking (writes). It stops short of explicitly naming those alternatives, so no 5.
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?
No statement of when to use this versus brightcanoe_get_upcoming_bookings or brightcanoe_create_booking, and no prerequisites or exclusions. The agent must infer the booking-flow context from the sibling list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the Bright Canoe business profile including business name, services catalog, working hours, and booking policies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. 'Retrieve' signals a read, and the enumerated fields hint at what comes back, but it says nothing about authentication requirements, caching/freshness, or error behavior for an unconfigured profile.
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?
One front-loaded sentence with the resource named first and the returned fields listed after — nothing superfluous, nothing buried.
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 zero-parameter read with no output schema, enumerating the returned fields largely compensates for the missing return documentation. Only minor gaps remain, such as response shape or failure modes.
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 tool takes zero parameters, which is the baseline-4 case; there is no parameter semantics to explain. The schema is trivially complete for an empty object.
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 (Retrieve) and resource (Bright Canoe business profile) and enumerates the contents returned: business name, services catalog, working hours, booking policies. That clearly separates it from siblings like get_client or get_analytics_summary, though it doesn't name an alternative explicitly.
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 zero-parameter, read-only shape — you call it to learn about the business. But there is no statement of when to prefer it over siblings such as get_analytics_summary or get_available_slots, and no prerequisites noted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve detailed Client 360 CRM record for an individual client by email.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Client email address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Retrieve' implies a read-only, non-mutating lookup, which is useful, but it says nothing about behavior when the email matches no client, permission/auth requirements, or what 'detailed' entails. Adequate but with clear gaps for a no-annotation 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?
A single front-loaded sentence with no filler; the resource and the lookup key come before anything else.
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 read tool with a fully described schema this is close to sufficient, but with no annotations and no output schema the agent learns nothing about the returned record's structure or the not-found case. Minor, but a real gap.
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 parameter is fully documented in the schema ('Client email address'). The description only restates 'by email' and adds no format, case-sensitivity, or exact-match guidance 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?
Specific verb ('Retrieve') plus specific resource ('detailed Client 360 CRM record for an individual client'), and the 'by email' qualifier makes it distinguishable from brightcanoe_search_clients. It stops short of a 5 because it never names the sibling or states the lookup-vs-search boundary explicitly.
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 phrase 'for an individual client by email' implies the use case (single-record lookup when you already have the email) rather than a broad search, but there is no explicit when-to-use, when-not-to-use, or named alternative such as brightcanoe_search_clients.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List upcoming confirmed appointments and client meetings.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of appointments to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It reveals only that results are upcoming and confirmed, saying nothing about the time window covered, ordering, whether cancelled or tentative bookings appear, or any auth requirements.
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?
A single front-loaded sentence with no filler, appropriately sized for a one-parameter read tool. Every word contributes to scope.
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 fully documented parameter, this is close to adequate, but with no output schema the description should say more about what comes back (fields, ordering) and what "upcoming" means as a time horizon.
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 limit parameter includes its default, so the schema does the work. The description adds nothing about the parameter, which is acceptable at this coverage level.
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 (List) and a specific resource scope (upcoming confirmed appointments and client meetings). It's clear what the tool returns, but it doesn't reference any sibling such as get_available_slots or get_analytics_summary to sharpen the boundary.
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 word "confirmed" implicitly distinguishes this from get_available_slots (unbooked capacity) and create_booking, so a careful agent can infer when to use it. However there is no explicit when-not guidance, no mention of alternatives, and no statement of preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Client 360 CRM records by name, email, company, or lifecycle status.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search term for name, email, or company | |
| status | No | Filter by lifecycle status (e.g. active, lead, churned) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a read-only search but does not disclose result limits, pagination, matching behavior, permissions, 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?
The definition is a single front-loaded sentence with no wasted words. It is appropriately sized for a simple two-parameter search 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?
For a simple two-parameter search with complete schema descriptions, the core purpose is covered. However, with no annotations and no output schema, the description leaves behavioral details about results and limits unaddressed.
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 both parameters are already documented. The description repeats the searchable fields without adding syntax, matching rules, or examples beyond what the schema provides.
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: search Client 360 CRM records, with the searchable fields named. It is clear what the tool does, but it does not explicitly differentiate itself from the sibling get_client lookup tool.
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 implies usage by listing searchable fields such as name, email, company, and lifecycle status. However, it gives no explicit guidance on when to use this search versus get_client, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update notes, tags, and lifecycle details for a client in Client 360 CRM.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Array of tag labels | |
| Yes | Client email address | ||
| notes | No | Notes to record on the client record |
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 say whether notes/tags overwrite or append, whether omitting a field leaves it unchanged, whether the client must already exist, or what permission or error behavior to expect. For a mutation tool with zero annotation coverage this is a significant gap.
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?
A single efficient sentence with the verb and target front-loaded and no wasted words. It is terse to the point of under-specifying behavior, but the size itself is appropriate.
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 mutating CRM tool with no annotations and no output schema, the description leaves key operational questions unanswered: update-vs-replace semantics for tags and notes, required pre-existing state, and return behavior. The thorough schema helps but does not cover mutation semantics.
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 each parameter (email, notes, tags) is described, so the schema does the heavy lifting. The description adds nothing about semantics and even references "lifecycle details," which has no corresponding parameter, mildly muddying the mapping.
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 ("Update") and resource (client record in Client 360 CRM) and names the fields touched, which distinguishes it from read-oriented siblings like get_client and search_clients. It does not explicitly contrast with those siblings, but the mutation framing is 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?
No guidance on when to use this instead of get_client or search_clients, and no preconditions (e.g., client must already exist, email is used as the lookup key). The agent must infer all usage context.
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.
brightcanoe_cancel_bookingbrightcanoe_create_bookingbrightcanoe_get_analytics_summarybrightcanoe_get_available_slotsbrightcanoe_get_business_profilebrightcanoe_get_clientbrightcanoe_get_upcoming_bookingsbrightcanoe_search_clientsbrightcanoe_update_client_notes
Add one secure layer between your agents and this server.