Skip to main content
Glama
aqeelshamz

wixzel-phone-mcp

by aqeelshamz

Create an appointment

create_appointment

Book an appointment for a lead with a specific agent by providing phone number, date/time, agent and lead IDs. Add client name, notes, or duration to capture scheduling details.

Instructions

Book an appointment against a lead and agent.

Requires scope appointments:write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNo
lead_idYes
agent_idYes
date_timeYesStart time, ISO 8601 UTC.
client_nameNo
phone_numberYesPhone number in E.164 form, e.g. "+14155551234".
duration_minutesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

The annotations already signal that this is a write operation (readOnlyHint=false) and not idempotent. The description adds a useful authorization requirement ('Requires scope appointments:write') but does not disclose other behavioral traits, such as duplicate handling, return value, or what resources are affected beyond creating the appointment.

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 only two sentences: one for the core action and one for the required scope. Every sentence earns its place, and the most important information is front-loaded.

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

Completeness2/5

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

For a creation tool with no output schema and seven parameters, the description leaves significant gaps: no field-level guidance for most parameters, no mention of required preconditions, and no indication of what the response contains. The description is too sparse to fully support correct invocation beyond the action itself.

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

Parameters2/5

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

The input schema documents only 29% of parameters, and the description adds little to fill the gap. 'Against a lead and agent' clarifies that lead_id and agent_id are involved, but notes, client_name, duration_minutes, and other fields remain unexplained in both the schema and description.

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

Purpose5/5

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

The description uses a specific verb ('Book') and names the resource and its key relationships ('against a lead and agent'), making the operation clear. It clearly distinguishes this creation tool from sibling update/get/delete/list appointment tools.

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

Usage Guidelines2/5

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

The description gives no guidance on when to use this tool versus alternatives such as update_appointment, nor does it state prerequisites like whether the lead and agent must already exist. The only usage signal is the phrase 'Book an appointment', which is implied rather than explicit.

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