Nexwin

Server Details

Check bookings, review calls and chats, and manage appointments in your Nexwin AI receptionist.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.8% over 21 days
Last Tested: 2026-10-14 11:46
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.3/5.0

Scored 2026-10-08 01:50 across 9 tools

Disambiguation5/5

Each tool targets a distinct resource and action: bookings (create/get/reschedule/cancel), calls/chats (history/detail), team members (list), and account info. The detail vs. history split for calls/chats and the cancel vs. reschedule split for bookings are clearly differentiated by their descriptions.

Naming Consistency4/5

Strong verb_noun convention throughout (create_booking, cancel_booking, get_bookings, reschedule_booking, list_team_members, get_call_chat_history/detail). The only deviation is about_nexwin, which breaks the pattern but is a minor, understandable exception for a no-account info tool.

Tool Count5/5

Nine tools is well-scoped for a booking-plus-call-management server. Each tool earns its place with no redundant or filler operations, and the set covers the core workflow without bloat.

Completeness4/5

The booking lifecycle is fully covered (create, list, reschedule, cancel) along with team member lookup, call/chat review, and account usage. Minor gaps exist such as no single-booking get-by-id or team member management, but agents can work around these via get_bookings and list_team_members.

Available Tools

21 tools

about_nexwinAbout NexwinA

Read-onlyIdempotent

Inspect

Explains what Nexwin is and how to sign up. Use when the user asks what Nexwin is, what it does, or how to get started — no account connection needed.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	Yes
`features`	Yes
`signupUrl`	Yes
`description`	Yes

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the note that no account connection is needed, which is valuable behavioral context not present in the annotations. No contradictions found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. The purpose is front-loaded ('Explains what Nexwin is and how to sign up') and the usage condition follows directly. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, zero-parameter informational tool with an output schema present and annotations already carrying safety properties, this description is complete. It covers the purpose, the trigger conditions, and the lack of authentication requirement — nothing an agent needs is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4 per the rubric. The schema is fully covered (100%) and there is nothing for the description to add about parameters. The description correctly avoids inventing parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'explains' and names the resource 'Nexwin', stating exactly what it does: explain what Nexwin is and how to sign up. It also implicitly distinguishes from siblings like create_booking, which are action-oriented, by focusing on informational content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly specifies when to use the tool: 'when the user asks what Nexwin is, what it does, or how to get started.' It also adds the condition 'no account connection needed,' giving clear context for when this is the right tool versus more functional siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

add_assetsAdd assetsInspect

Adds bookable assets (rooms, campsites, vehicles, equipment) to the connected Nexwin account, up to 100 in one call, and tells the live receptionist about them. Use it to set up a whole list the user has pasted or uploaded. All of them are added or none: if any row is invalid, or a name is already in use, nothing is saved and the error says which row. Identical units go in one asset with a quantity (e.g. "Standard Room", quantity 12) rather than twelve assets. bookingType: nightly (check in one day, out a later day), day (a block within one day), date_range (whole days), or not_applicable. Executes immediately. Call list_assets first to avoid clashing names.

ParametersJSON Schema

Name	Required	Description	Default
`assets`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`created`	Yes
`message`	Yes
`success`	Yes
`liveWarning`	Yes
`_environment`	Yes	The Nexwin country and environment that supplied the result
`liveOnReceptionist`	Yes

add_team_memberAdd a team memberInspect

Adds a person to the connected Nexwin account's team without a login, so bookings can be made with them. Nobody is emailed. Use invite_team_member instead if they need to sign in. Set isInternalOnly for someone callers should never be told about by name. Returns the new teamMemberId.

ParametersJSON Schema

Name	Required	Description
`email`	No	Optional; kept on their profile
`lastName`	Yes
`timezone`	No	IANA timezone, e.g. Australia/Sydney (the default)
`firstName`	Yes
`isInternalOnly`	No	true hides this person's name from callers

Output Schema

ParametersJSON Schema

Name	Required	Description
`invited`	No
`message`	Yes
`success`	Yes
`_environment`	Yes	The Nexwin country and environment that supplied the result
`teamMemberId`	No

cancel_bookingCancel a bookingA

Destructive

Inspect

Cancels a booking (appointmentId from get_bookings) by PERMANENTLY DELETING it — it will not appear afterwards, even as canceled. Also removes its Zoom meeting and calendar event and emails the customer a cancellation. Cannot be undone. Before calling, tell the user which booking (customer, time) will be cancelled and that the customer will be emailed, and get their explicit yes; then pass confirm: true.

ParametersJSON Schema

Name	Required	Description	Default
`confirm`	Yes	true only after the user has explicitly confirmed cancelling this specific booking in the conversation
`appointmentId`	Yes	From get_bookings

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`success`	No
`_environment`	Yes	The Nexwin country and environment that supplied the result
`appointmentId`	No

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructiveHint=true and idempotentHint=false, but the description goes well beyond them: it discloses the deletion semantics (won't appear even as canceled), the side effects (Zoom meeting, calendar event removal, customer email), irreversibility, and the required user-confirmation flow. This is rich, non-redundant behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and its destructive nature, then side effects, then the preconditions. Every clause carries information the agent needs; nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and the description covers the mutation's consequences, irreversibility, side effects, and confirmation protocol. Nothing needed to call it safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by tying confirm to an explicit user 'yes' about a specific booking and reiterating appointmentId's origin. It reinforces the schema rather than merely restating it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (cancel a booking) and immediately clarifies the scope by defining it as PERMANENT DELETION rather than a status change — which is exactly the distinction that separates it from reschedule_booking among the siblings. An agent can select it unambiguously.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use it, that it cannot be undone, where appointmentId comes from (get_bookings), and the exact conversational precondition plus the confirm: true gate before invoking. No conditions are left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_bookingCreate a bookingAInspect

Creates a new appointment on the connected Nexwin account and emails the customer a confirmation. Executes immediately. Get teamMemberId and timezone from list_team_members first. Online bookings require customerEmail and create a Zoom meeting; in-person bookings need customerEmail or customerPhone. Fails if the team member is already booked at that time.

ParametersJSON Schema

Name	Required	Description
`title`	Yes
`endTime`	Yes	ISO 8601 with UTC offset, e.g. 2026-09-20T15:00:00+10:00
`timezone`	Yes	IANA timezone, e.g. Australia/Sydney — use the team member's timezone from list_team_members
`startTime`	Yes	ISO 8601 with UTC offset, e.g. 2026-09-20T14:00:00+10:00
`meetingType`	Yes
`customerName`	Yes
`teamMemberId`	Yes	From list_team_members
`customerEmail`	No
`customerPhone`	No
`meetingAddress`	No	For in_person bookings

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`success`	No
`_environment`	Yes	The Nexwin country and environment that supplied the result
`appointmentId`	No

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the write/non-idempotent character is known. The description adds real context beyond that: immediate execution with no confirmation step, an outbound customer confirmation email, and a documented conflict failure mode ('Fails if the team member is already booked'). Auth/permission requirements are still unspecified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four dense sentences, all load-bearing: purpose and side effect first, then prerequisites, then conditional parameters, then failure mode. No filler or repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. The description covers prerequisites, conditional requirements and the conflict failure, leaving only minor gaps such as behavior if the confirmation email fails or any rate/permission constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, and the description compensates by encoding conditional parameter requirements that the schema does not express: customerEmail for online bookings, customerEmail or customerPhone for in-person, and the source of teamMemberId/timezone. It could say more about meetingAddress and title, which remain purely schema-defined.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Creates a new appointment on the connected Nexwin account') plus the immediate side effect of emailing the customer a confirmation. This is distinguishable from read-oriented siblings like get_bookings and from reschedule_booking without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete prerequisites ('Get teamMemberId and timezone from list_team_members first') and explicit branching rules for meetingType ('Online bookings require customerEmail ... in-person bookings need customerEmail or customerPhone'). It stops short of stating when NOT to use this tool, e.g. pointing at reschedule_booking for existing appointments.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_customerFind a customer

Read-onlyIdempotent

Inspect

Looks up customers on the connected Nexwin account by part of a name, phone number or email address. Returns contact details, how often they've called or chatted, and what their last conversation was about. Use for "has Sam called before?" or "what did Sam want last time?".

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Most matches to return (default 10)
`search`	Yes	Part of a name, phone number or email address

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	Yes
`hasMore`	Yes
`customers`	Yes
`_environment`	Yes	The Nexwin country and environment that supplied the result

get_account_usage_summaryGet account usage summaryA

Read-onlyIdempotent

Inspect

Plan, subscription status, minutes/messages used this period, and wallet balance for the connected Nexwin account.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`plan`	No
`_environment`	Yes	The Nexwin country and environment that supplied the result
`walletBalance`	No
`subscriptionStatus`	No

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the connected-account scope and output fields, but it does not disclose behaviors such as data freshness, authentication requirements, or rate limits. This is adequate but not exceptional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that lists the key result dimensions with no filler. Every word contributes meaning and the structure is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter read-only tool with a rich output schema and readOnly/idempotent annotations, a one-sentence summary of what is returned and the account scope is complete. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no parameter ambiguity for the description to resolve. The baseline of 4 applies; the description appropriately focuses on what data will be returned rather than parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('get account usage summary') and enumerates the exact data returned: plan, subscription status, minutes/messages used, and wallet balance for the connected Nexwin account. This clearly differentiates it from siblings like about_nexwin or get_bookings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the natural use case — checking plan, usage, and wallet for the connected account — but gives no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like about_nexwin. The intended usage is inferable but not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_activity_summaryGet activity summary

Read-onlyIdempotent

Inspect

Summarises what happened on the connected Nexwin account over a period: the answer to "what's happened the last two days?" or "anything I need to follow up?". Returns totals for calls and for chats (how many, resolved, needing follow-up, transferred to staff, sentiment, bookings made) and one entry per conversation, newest first, with the receptionist's own summary and action items. Give lastDays (today counts as day 1, in the business's timezone) or startDate and endDate; 30 days at most. Set followUpsOnly for "who do I need to call back?". For a full transcript, pass an entry's channel and id to get_call_chat_detail.

ParametersJSON Schema

Name	Required	Description
`endDate`	No	YYYY-MM-DD, business-local
`lastDays`	No	How many days back, today included. Use instead of startDate/endDate.
`maxItems`	No	Conversations to list (default 50)
`startDate`	No	YYYY-MM-DD, business-local
`followUpsOnly`	No	Only list conversations that have action items

Output Schema

ParametersJSON Schema

Name	Required	Description
`calls`	Yes
`chats`	Yes
`items`	Yes
`endDate`	Yes
`partial`	Yes	True when the period had more conversations than were read; only the two totals then cover the whole period
`timezone`	Yes
`startDate`	Yes
`_environment`	Yes	The Nexwin country and environment that supplied the result
`itemsOmitted`	Yes
`followUpsOnly`	Yes

get_ai_setupGet receptionist settings

Read-onlyIdempotent

Inspect

Shows how the connected account's AI receptionist is set up right now, as callers hear it: business name, about text and address, the How to Handle Calls handbook, the receptionist's name and greetings, what it does after hours, whether confirmation emails go out, and the business hours (read-only). Also lists the last few published versions, for restore_ai_setup_version. Call this before update_ai_setup so a change is based on the current wording.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`version`	No
`settings`	No
`published`	Yes
`publishedAt`	No
`_environment`	Yes	The Nexwin country and environment that supplied the result
`businessHours`	No
`recentVersions`	No

get_bookingsGet bookingsA

Read-onlyIdempotent

Inspect

Lists the connected Nexwin account's appointments/bookings in a date range (max 30 days, first 25 results). Each booking includes its appointmentId and teamMemberId (needed for reschedule_booking and cancel_booking), exact ISO startTime/endTime, and timezone. Requires a connected account.

ParametersJSON Schema

Name	Required	Description
`status`	No
`endDate`	Yes	YYYY-MM-DD, business-local
`startDate`	Yes	YYYY-MM-DD, business-local

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	Yes
`endDate`	Yes
`startDate`	Yes
`truncated`	Yes
`_environment`	Yes	The Nexwin country and environment that supplied the result
`appointments`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior beyond annotations: it discloses the 30-day maximum range, 25-result limit, and the specific fields included in each booking (appointmentId, teamMemberId, ISO startTime/endTime, timezone), plus the connected-account requirement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences front-load the core purpose and limits, then add relation to sibling tools and account requirement. No filler or redundant restating of the title or schema. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity, the presence of an output schema, and rich annotations, the description covers the essential operational context: purpose, date range limits, result cap, key fields, sibling-tool usage, and account prerequisite. No critical information needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides descriptions for startDate and endDate ('YYYY-MM-DD, business-local'), giving 67% coverage. The description adds the 30-day max range constraint and clarifies the result fields, which aids parameter interpretation, but it does not address the optional status parameter's meaning or filtering behavior beyond the enum in the schema. Overall, it adds some value but the schema still carries the main parameter burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Lists'), a clear resource ('appointments/bookings in a date range'), and adds the account scope ('connected Nexwin account'). It also distinguishes the tool's output by noting fields needed for sibling tools reschedule_booking and cancel_booking, so an agent can identify its role 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies when to use this tool: to retrieve bookings in a date range, especially when needing appointmentId and teamMemberId for reschedule_booking or cancel_booking. It also notes the 'Requires a connected account' prerequisite. It does not explicitly state when not to use it or name an alternative for listing bookings, 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.

get_call_chat_detailGet call or chat detailA

Read-onlyIdempotent

Inspect

Fetches the full transcript and detail for one call or chat, by id. Requires a connected account.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The callId or chatId from get_call_chat_history
`channel`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`callId`	No
`chatId`	No
`endedAt`	No
`summary`	No
`messages`	No
`sentiment`	No
`startedAt`	No
`successful`	No
`transcript`	No
`actionItems`	No
`_environment`	Yes	The Nexwin country and environment that supplied the result
`recordingUrl`	No
`durationSeconds`	No

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds the requirement for a connected account, which goes beyond annotations, and notes it fetches a 'full transcript' implying a potentially large payload. However, it doesn't elaborate on performance or error behavior. With annotations carrying the safety profile, this adds modest value, so a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero fluff. The verb and resource are front-loaded, and the auth requirement is placed at the end as a concise precondition. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple fetch tool with two params, an enum, and an output schema (which covers return values), the description is nearly complete. It covers what the tool returns (full transcript/detail), how to identify the target (id), and the auth prerequisite. It doesn't mention error scenarios or timeouts, but these are minor gaps given the output schema and simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% – only 'id' has a description ('The callId or chatId from get_call_chat_history'), while 'channel' only has an enum. The description says 'for one call or chat' which clarifies that 'channel' distinguishes between the two, and 'by id' aligns with the id schema. It adds some context beyond the schema but doesn't fully compensate for the missing channel description, so it meets the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Fetches' and the resource 'full transcript and detail for one call or chat, by id.' It distinguishes this from the sibling 'get_call_chat_history' by focusing on a single item via id, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context: you need an id from history ('by id') and a connected account is required. While it doesn't explicitly name alternatives or say 'use when you have an id', the structure implies this tool is for retrieving a specific record after listing, and the auth requirement is a useful precondition. No exclusions or alternative-routing are given, so it's not a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_call_chat_historyGet call or chat historyA

Read-onlyIdempotent

Inspect

Lists recent calls or chats for the connected Nexwin account in a date range, without full transcripts. Requires a connected account.

ParametersJSON Schema

Name	Required	Description
`limit`	No
`channel`	Yes
`endDate`	Yes	YYYY-MM-DD
`startDate`	Yes	YYYY-MM-DD

Output Schema

ParametersJSON Schema

Name	Required	Description
`calls`	No
`chats`	No
`total`	Yes
`channel`	Yes
`endDate`	Yes
`hasMore`	Yes
`startDate`	Yes
`_environment`	Yes	The Nexwin country and environment that supplied the result

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish that the operation is read-only, idempotent, and non-destructive. The description adds meaningful behavior beyond that: it requires a connected account and deliberately omits full transcripts. Nothing contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One tight, front-loaded sentence states the core action, the scope, the date constraint, the transcript limitation, and the prerequisite. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only listing tool with an output schema and safety annotations, the description covers purpose, scope, and the key prerequisite. It is complete enough for an agent to invoke correctly, though it could have made the limit behavior slightly more explicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50%, and the description compensates slightly by mapping 'calls or chats' to the channel enum and 'date range' to startDate/endDate. However, the limit parameter is not explained in prose, and the description does not add format or constraint details beyond what the schema already shows.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Lists'), a clear resource ('recent calls or chats'), and a scope ('connected Nexwin account', 'date range'). It also distinguishes itself from the sibling get_call_chat_detail by explicitly noting it returns no full transcripts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when the tool is appropriate: recent calls/chats in a date range for the connected account. However, it never explicitly states when to prefer get_call_chat_detail or which conditions rule this tool out, leaving the sibling distinction mostly implied by 'without full transcripts.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

import_customersImport customersInspect

Adds customers to the connected Nexwin account, up to 200 in one call, from a list the user has pasted or uploaded. The receptionist then recognises them by phone number when they call. A row whose phone number or email already belongs to a customer is skipped, as is a row with no first name; the result says how many of each. Existing customers are never changed. Nobody is contacted. Executes immediately.

ParametersJSON Schema

Name	Required	Description	Default
`customers`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`success`	Yes
`imported`	Yes
`_environment`	Yes	The Nexwin country and environment that supplied the result
`skippedNoName`	Yes
`skippedDuplicates`	Yes

invite_team_memberInvite a team memberInspect

Emails someone an invitation to join the connected Nexwin account with their own login. They become a team member once they accept; the link expires after 24 hours. Use add_team_member instead for a person who only needs to be bookable and won't sign in. The invitee starts with calendar access only; access to call history, the knowledge base or AI Setup is granted in the Nexwin dashboard. Executes immediately: the email is sent as soon as this is called, so check the address with the user first.

ParametersJSON Schema

Name	Required	Description
`role`	Yes	admin can manage the team and settings; member cannot
`email`	Yes
`lastName`	Yes
`timezone`	No	IANA timezone, e.g. Australia/Sydney (the default)
`firstName`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`invited`	No
`message`	Yes
`success`	Yes
`_environment`	Yes	The Nexwin country and environment that supplied the result
`teamMemberId`	No

list_assetsList assets

Read-onlyIdempotent

Inspect

Lists the bookable assets on the connected Nexwin account: things customers book rather than people, such as hotel rooms, campsites, vehicles or equipment. Shows each asset's type, how many identical units it has, how it is booked and its check-in and check-out times. Call this before add_assets to see what is already there.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`assets`	Yes
`_environment`	Yes	The Nexwin country and environment that supplied the result

list_team_membersList team membersA

Read-onlyIdempotent

Inspect

Lists the connected Nexwin account's active team members with their teamMemberId and timezone. Call this before create_booking to get a real teamMemberId and the timezone to book in. Requires a connected account.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`teamMembers`	Yes
`_environment`	Yes	The Nexwin country and environment that supplied the result

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds the prerequisite 'Requires a connected account,' which is an authorization need not present in annotations, and adds the 'active' filter on team members, further describing behavior. It doesn't describe error cases or pagination, but the bar is lower given annotations; the addition of auth context earns a 4.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, both earning their place. The first sentence front-loads the primary purpose with the exact action and result. The second sentence provides crucial usage direction and a prerequisite. There is no fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only list tool with an output schema and comprehensive annotations, the description is complete. It covers what the tool does, its prerequisite, and its intended use within the workflow. The output schema handles return value details, and annotations cover safety, so nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there are no parameter semantics to add. The baseline for 0 parameters is 4, and the description appropriately avoids any parameter discussion. It does mention the output fields (teamMemberId, timezone) which aligns with the output schema, adding value beyond the empty input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists active team members with their teamMemberId and timezone, using the specific verb 'lists' with a clear resource. It also distinguishes the tool from siblings by specifying it returns team member identifiers and timezone, which is not ambiguous with other list-like tools like get_bookings or get_account_usage_summary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent when to use this tool: 'Call this before create_booking to get a real teamMemberId and the timezone to book in.' This is a clear usage context with a named companion tool, but it doesn't explicitly state when not to use it. The guidance is adequate and actionable, though not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

remove_team_memberRemove a team member

Destructive

Inspect

PERMANENTLY removes a team member (teamMemberId from list_team_members) from the connected Nexwin account. If they have a login it is deleted, so they can no longer sign in, and their connected calendars are disconnected. Cannot be undone; they would have to be invited again. The account owner cannot be removed, and nobody can remove themselves. Before calling, tell the user exactly who will be removed and that their sign-in is deleted, and get their explicit yes; then pass confirm: true.

ParametersJSON Schema

Name	Required	Description	Default
`confirm`	Yes	true only after the user has explicitly confirmed removing this specific person in the conversation
`teamMemberId`	Yes	From list_team_members

Output Schema

ParametersJSON Schema

Name	Required	Description
`invited`	No
`message`	Yes
`success`	Yes
`_environment`	Yes	The Nexwin country and environment that supplied the result
`teamMemberId`	No

reschedule_bookingReschedule a bookingA

Destructive

Inspect

Moves an existing booking (appointmentId from get_bookings) to a new time and emails the customer about the change. Before calling, tell the user which booking (customer, current time) is moving to which new time, and get their explicit yes; then pass confirm: true. Executes as soon as it is called with confirm: true.

ParametersJSON Schema

Name	Required	Description
`confirm`	Yes	true only after the user has explicitly confirmed this specific change in the conversation
`endTime`	Yes	ISO 8601 with UTC offset, e.g. 2026-09-20T15:00:00+10:00
`timezone`	No	IANA timezone; defaults to the booking’s existing timezone
`startTime`	Yes	ISO 8601 with UTC offset, e.g. 2026-09-20T14:00:00+10:00
`appointmentId`	Yes	From get_bookings

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`success`	No
`_environment`	Yes	The Nexwin country and environment that supplied the result
`appointmentId`	No

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructive/non-idempotent, but the description adds genuinely new behavioral context: the customer is emailed, and the operation executes immediately once confirm: true is passed. That execution-timing and side-effect disclosure goes well beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loading what the tool does before the confirmation protocol and the immediate-execution warning. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, and the description covers the safety-critical confirmation flow and side effect. Nothing an agent needs in order to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all five parameters (including ISO 8601 formats, timezone default, and the confirm gate) are already documented in the schema. The description only restates the confirm requirement and appointmentId origin, adding little beyond the structured data. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Moves an existing booking ... to a new time') plus a side effect (emails the customer). This clearly distinguishes it from siblings cancel_booking and create_booking without needing to open either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly prescribes the pre-call workflow: tell the user which booking (customer, current time) is moving where, get an explicit yes, then pass confirm: true. It also names the prerequisite source for appointmentId (get_bookings), leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

restore_ai_setup_versionRestore earlier receptionist settings

Destructive

Inspect

Undoes changes made with update_ai_setup by putting those same settings back to what they were in an earlier published version (version numbers come from get_ai_setup or from an update_ai_setup result). Goes live for callers straight away and is itself saved as a new version. Settings that update_ai_setup cannot change are left as they are now. Before calling, tell the user which version is being restored and get their explicit yes; then pass confirm: true.

ParametersJSON Schema

Name	Required	Description	Default
`confirm`	Yes	true only after the user has explicitly approved restoring this version in the conversation
`version`	Yes	The published version to go back to

Output Schema

ParametersJSON Schema

Name	Required	Description
`changes`	Yes
`message`	Yes
`success`	Yes
`version`	No
`liveWarning`	Yes
`_environment`	Yes	The Nexwin country and environment that supplied the result
`restoredFrom`	No
`previousVersion`	No

update_ai_setupChange receptionist settings

Destructive

Inspect

Changes how the connected account's AI receptionist answers, and puts the change live for real callers straight away. Editable fields: businessName, aboutYourBusiness (max 500 characters), businessAddress, handbook (the How to Handle Calls instructions), assistantName, greetingNew, greetingReturning, afterHoursAction (message, callback or voicemail) and sendConfirmationEmail (true or false). For the handbook, set append: true to add a line to the end of what's there, or remove: true to take one exact piece of text back out and leave the rest untouched; with neither, the whole handbook is replaced. Call get_ai_setup first. Before calling, tell the user exactly which settings will change and to what, and get their explicit yes; then pass confirm: true. All changes in one call are applied together or not at all, and are saved as a new version that restore_ai_setup_version can undo. For something temporary (someone on leave, a holiday closure): append a note to the handbook that carries its own dates, e.g. "TEMPORARY, from Mon 12 Oct 2026 until Sun 18 Oct 2026: Raj is on leave. Offer callers a callback from Monday 19 October. Ignore this note outside those dates." Nothing removes the note automatically, so tell the user it stays in the handbook until they ask you to take it out, which is another call with remove: true and the exact text of the note.

ParametersJSON Schema

Name	Required	Description	Default
`changes`	Yes
`confirm`	Yes	true only after the user has explicitly approved these specific changes in the conversation

Output Schema

ParametersJSON Schema

Name	Required	Description
`changes`	Yes
`message`	Yes
`success`	Yes
`version`	No
`liveWarning`	Yes
`_environment`	Yes	The Nexwin country and environment that supplied the result
`restoredFrom`	No
`previousVersion`	No

update_team_memberUpdate a team member

DestructiveIdempotent

Inspect

Changes a team member's settings (teamMemberId from list_team_members): their timezone, role, how much notice they need before a booking (leadTimeMinutes), the travel gap kept around each of their bookings (travelBufferMinutes), or whether their name is hidden from callers (isInternalOnly). Only the fields given are changed. Only the account owner can change a role or isInternalOnly. Before calling, tell the user who is being changed and how, and get their explicit yes; then pass confirm: true.

ParametersJSON Schema

Name	Required	Description
`role`	No
`confirm`	Yes	true only after the user has explicitly approved this specific change in the conversation
`timezone`	No	IANA timezone, e.g. Australia/Perth
`teamMemberId`	Yes	From list_team_members
`isInternalOnly`	No
`leadTimeMinutes`	No	Minutes from now before their next booking is allowed
`travelBufferMinutes`	No	Minutes kept free before and after each booking; 0 turns it off

Output Schema

ParametersJSON Schema

Name	Required	Description
`invited`	No
`message`	Yes
`success`	Yes
`_environment`	Yes	The Nexwin country and environment that supplied the result
`teamMemberId`	No

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

12 tool updatesOct 10, 2026
- Addedadd_assets
- Addedadd_team_member
- Addedfind_customer
- Addedget_activity_summary
- Addedget_ai_setup
- Addedimport_customers
- Addedinvite_team_member
- Addedlist_assets
- Addedremove_team_member
- Addedrestore_ai_setup_version
- Addedupdate_ai_setup
- Addedupdate_team_member

2 tool updatesOct 8, 2026

Changedcancel_booking2 fields changed

addedInput schema / properties / confirm

Added value: +{
+  "description": "true only after the user has explicitly confirmed cancelling this specific booking in the conversation",
+  "type": "boolean"
+}

changedInput schema / required

Previous value: -[
-  "appointmentId"
-]New value: +[
+  "appointmentId",
+  "confirm"
+]

Changedreschedule_booking2 fields changed

addedInput schema / properties / confirm

Added value: +{
+  "description": "true only after the user has explicitly confirmed this specific change in the conversation",
+  "type": "boolean"
+}

changedInput schema / required

Previous value: -[
-  "appointmentId",
-  "startTime",
-  "endTime"
-]New value: +[
+  "appointmentId",
+  "startTime",
+  "endTime",
+  "confirm"
+]

9 tool updatesSep 24, 2026
- First observedabout_nexwin
- First observedcancel_booking
- First observedcreate_booking
- First observedget_account_usage_summary
- First observedget_bookings
- First observedget_call_chat_detail
- First observedget_call_chat_history
- First observedlist_team_members
- First observedreschedule_booking

Related MCP Connectors

Telofy B
app.telofy
AI phone receptionist for small businesses: read calls, leads and booked appointments.
Customer Support Calendar Management CRM
31
Famulor BOAuth
io.famulor
Manage AI assistants, history, calls, campaigns, contacts, knowledge, messaging, and automations.
Speech Processing Communication Knowledge & Memory
21
FrontDesk ChatOAuth
io.github.5ak3t
AI front desk for your website: read chats, bookings and analytics, and draft desks you approve.
1
EasyWeek BusinessOAuth
io.easyweek
Manage an EasyWeek business from AI: bookings, availability, customers, services, orders, messaging.
Calendar Management CRM
1

Related MCP Servers

Voice Logica MCP
AI & Machine Learning Communication App Automation
voicelogica
A
license
Not graded
quality
A
maintenance
Enables managing AI voice agents, phones, integrations, workflows, calls, and billing directly from chat, including editing agent settings, connecting CRMs, and reviewing call logs.
Updated 3 days ago (2026-10-11 22:22 UTC)
MIT
Floyd
App Automation Calendar Management Autonomous Agents
floyd-run
F
license
Not graded
quality
C
maintenance
Scheduling and booking engine for AI agents. Check availability, hold slots, and confirm appointments with two-phase booking and conflict-free resource management.
Updated a month ago (2026-09-16 12:23 UTC)
2
-
Bolna MCP Server
Communication AI & Machine Learning
abhinav7895
A
license
A
quality
D
maintenance
Manage voice AI agents, make calls, run campaigns, and control phone numbers through natural language.
Updated 4 months ago (2026-06-13 04:36 UTC)
58
15 npm
1
MIT
nexudus-mcp
Workplace & Productivity Calendar Management App Automation
jude-stiel
F
license
B
quality
D
maintenance
Enables natural language booking and management of rooms in Nexudus coworking spaces, including listing rooms, checking availability, booking, viewing/cancelling bookings, and schedules.
Updated 7 months ago (2026-03-25 20:59 UTC)
6
-

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?