Duplicate listing. This is the same server as SimpleDock (ai.simpledock/simple-dock) (https://simpledock.ai/api/v1/mcp). Please use that listing instead.
Warehouse dock appointment scheduling: find open slots, book, reschedule, approve, check in trucks.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 40 tools
Most tools target clearly distinct actions and resources, and the descriptions explicitly distinguish tricky pairs such as approve vs reject vs cancel, check_in vs mark_arrived, and set_up_location vs focused configuration tools. The main residual ambiguity is between the broad setup tool and several narrower setup tools, but the intended usage boundaries are well documented.
Tool names consistently use snake_case with an action-led verb_noun pattern (create_appointment, update_door, list_locations, set_weekly_hours). Minor outliers like mark_arrived and set_up_location still follow the same readable convention and do not create naming confusion.
With 40 tools, the surface is quite heavy for an agent to navigate, even for a rich scheduling domain. The server covers many subdomains, but the large number of focused configuration and lifecycle tools makes the set feel over-expanded.
Core appointment and location setup workflows are well covered, including approval, cancellation, rescheduling, arrival, completion, availability, closures, types, doors, and booking questions. However, several admin surfaces are intentionally incomplete: members can be invited but not listed or removed; webhooks and API keys can be created but not listed, updated, or revoked over MCP; and locations lack deletion.
Close the whole location on specific dates (holidays, shutdowns), in its local timezone. Existing appointments on those dates are not cancelled; the response counts them so you can follow up (cancel_appointment or reschedule_appointment). Dates already closed are skipped. Each date becomes its own closure; undo one with remove_closure. For a recurring weekly closed day use set_weekly_hours instead. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| dates | Yes | Whole days to close. | |
| reason | No | Shown to staff, e.g. "Christmas". | |
| locationId | Yes | Location id, from list_locations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false): it discloses that existing appointments are NOT cancelled, that the response counts them for follow-up, and that already-closed dates are skipped. It also surfaces the auth requirement (Admin role, locations:write), which annotations do not carry.
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?
Purpose is front-loaded in the first clause, and each subsequent sentence carries a distinct, non-redundant fact (side effects on appointments, idempotency, undo path, weekly alternative, auth scope). No filler or repetition of the schema.
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 still explains the return behavior (the count of affected appointments) and the side effects, idempotency, undo path, and permissions. Nothing an agent needs to invoke this mutation correctly is 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 coverage is 100%, so the per-parameter baseline is 3; the description earns a bump by clarifying that dates are interpreted in the location's local timezone and that each date becomes its own independent closure (which affects how removal works). It adds framing rather than new field-level detail, so it stays short of 5.
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 action and scope: closing the whole location on specific dates, in the location's local timezone, with concrete examples (holidays, shutdowns). It is clearly distinguished from the neighboring set_weekly_hours (recurring days), remove_closure (undo), and cancel_appointment (per-appointment), so an agent can pick it without opening any 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?
Explicit routing is provided for every adjacent case: use set_weekly_hours for a recurring weekly closed day, use remove_closure to undo a single closure, and use cancel_appointment/reschedule_appointment to handle the appointments left behind. It also states the precondition of locations:write (Admin role).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Accept a PENDING booking request (status PENDING, from a location that requires approval) so it becomes CONFIRMED, optionally at a different start time. Only for PENDING; otherwise conflict. To turn a request down use reject_appointment; to move an already confirmed appointment use reschedule_appointment. Emails the carrier that it's approved (with the new time if changed). Returns the updated appointment. Requires scope appointments:write (Scheduler role or above).
| Name | Required | Description | Default |
|---|---|---|---|
| startTime | No | Optional new start time, ISO 8601 datetime with offset, e.g. 2026-10-15T08:00:00-05:00. Omit to keep the requested time. | |
| appointmentId | Yes | Appointment id, from list_appointments, get_appointment, or create_appointment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (not read-only, destructive, idempotent, open-world), and the description still adds real behavioral context beyond them: the carrier email side effect, the conflict behavior on non-PENDING input, and the required scope/role (appointments:write, Scheduler+). Nothing material about side effects or authorization is left implicit.
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?
Front-loads the core action and precondition, then alternatives, then side effects and scope. Six tight clauses with no filler; every sentence carries distinct 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 2-parameter mutation with no output schema, the description covers everything needed: precondition, conflict behavior, side effects, authorization scope, and a pointer that the updated appointment is returned. No gaps an agent would need to guess at.
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 (appointmentId, startTime with ISO 8601 format) are already fully documented. The description only restates that the time is optional and 'at a different start time', adding no format or edge-case detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.
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 (Accept), the resource (PENDING booking request), and the resulting state transition (PENDING → CONFIRMED), plus the optional time change. It explicitly names the sibling tools it is not (reject_appointment, reschedule_appointment), so an agent can disambiguate without opening any 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?
Gives the exact precondition ('Only for PENDING; otherwise conflict') and routes to the correct alternatives for the two adjacent cases: turning a request down and moving an already confirmed appointment. This is explicit when-to-use plus when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call off a CONFIRMED appointment (carrier or facility can't make it); it becomes CANCELLED and its door time is freed. Final: a cancelled appointment can't be restored, so confirm with the user first. To decline a PENDING request use reject_appointment (it records a reason); to move the time use reschedule_appointment; for a truck that never showed use set_appointment_status NO_SHOW. Already COMPLETED or NO_SHOW appointments can't be cancelled (conflict); cancelling twice is a no-op. Emails the carrier a cancellation notice, stops pending reminders, and fires an appointment.cancelled webhook. Returns the updated appointment. Requires scope appointments:write (Scheduler role or above).
| Name | Required | Description | Default |
|---|---|---|---|
| appointmentId | Yes | Appointment id, from list_appointments, get_appointment, or create_appointment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive=true and idempotent=true, but the description goes well beyond them: irreversibility ('can't be restored'), double-cancel being a no-op, the conflict on COMPLETED/NO_SHOW, and the concrete side effects (carrier cancellation email, stops pending reminders, appointment.cancelled webhook). It also discloses the required scope and role, which annotations do not carry.
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?
Front-loaded with the action, the state transition, and the irreversibility warning before routing guidance and side effects. It is dense — several clauses per sentence — but nearly every clause carries distinct operational information, so little is wasted.
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 mutation with no output schema, the description covers everything an agent needs: preconditions, finality, idempotency behavior, sibling routing, side effects, return value, and authorization scope. No meaningful gap remains.
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 there is a single parameter, so the schema already fully documents appointmentId including its sources. The description adds no syntax or format detail beyond that, making the baseline 3 correct.
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 ('call off a CONFIRMED appointment') and immediately scopes it with the state it operates on and the resulting state (CANCELLED, door time freed). It explicitly names the sibling tools it is not (reject_appointment, reschedule_appointment, set_appointment_status NO_SHOW), so an agent can route correctly without opening any 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?
Gives explicit when-to-use and when-not-to-use: decline a PENDING request via reject_appointment, move time via reschedule_appointment, no-show via set_appointment_status NO_SHOW. It also states the precondition (must be CONFIRMED; COMPLETED/NO_SHOW conflict) and the user-confirmation requirement before acting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record the driver's own update before arrival on a CONFIRMED appointment: ON_TRACK, or RUNNING_LATE with estimatedDelay minutes (e.g. "the driver says he's 30 minutes out and late"). Sets arrivalStatus; the appointment status doesn't change. It never cancels: use cancel_appointment for that. It doesn't start dwell time: when the truck is physically at the dock, use mark_arrived. Fires a webhook; no carrier email. Returns the updated appointment. Requires scope appointments:write (Scheduler role or above).
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ON_TRACK = expected on time; RUNNING_LATE = needs estimatedDelay. | |
| appointmentId | Yes | Appointment id, from list_appointments, get_appointment, or create_appointment. | |
| estimatedDelay | No | Minutes late, e.g. 30. Use with RUNNING_LATE. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only cover readOnly/idempotent/destructive), the description discloses side effects the schema cannot: it fires a webhook, sends no carrier email, leaves appointment status unchanged, and requires scope appointments:write with Scheduler role or above. It also notes the return value. This is exactly the extra behavioral context annotations don't carry.
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?
Dense and front-loaded: the core action and its constraints come first, then exclusions, side effects, and auth in tight succession. Every sentence carries a distinct fact with no filler.
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 supplies the return value ('updated appointment'), the auth requirement, the side effects, and the boundary conditions versus siblings. Nothing an agent needs 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.
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 meaning by pairing RUNNING_LATE with estimatedDelay minutes and giving a natural-language example ('30 minutes out and late'). It reinforces the enum/parameter relationship beyond the schema's field-level text.
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 ('Record the driver's own update before arrival on a CONFIRMED appointment') and names the precise state transition (sets arrivalStatus). It explicitly distinguishes itself from cancel_appointment and mark_arrived, so an agent can disambiguate without opening any 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?
Gives explicit when-to-use (before arrival, on a CONFIRMED appointment) and when-not, routing to named alternatives: 'use cancel_appointment for that' and 'when the truck is physically at the dock, use mark_arrived'. The selection logic is fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a long-lived API key (sd_live_…) for scripts and clients that can't refresh OAuth tokens. The full key is returned only now; store it. It's listed under Settings → API, where it can be revoked (keys can't be listed or revoked over MCP). Needs the owner's email confirmed first. Returns { apiKey, id, name, scopes, usage }. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | What it's for, e.g. "Yard system" | |
| scopes | No | Scopes to grant, no wider than your own. Omit to copy your current scopes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: the key is returned only once and must be stored, revocation lives in Settings → API, and the operation has an auth prerequisite (email confirmed) and required scope/role. Annotations cover the safety profile, and the description adds lifecycle and irreversibility context.
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 paragraph, front-loaded with what the tool does, then return format, prerequisites, and permissions. Every sentence carries information 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?
With no output schema, the description explicitly gives the return shape ({ apiKey, id, name, scopes, usage }) plus lifecycle, auth, and permission constraints. Nothing needed 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions on both params, so the schema already carries the parameter meaning; baseline 3 applies. The description's 'Requires scope locations:write (Admin role)' concerns the caller's token, not the scopes argument, so it adds little param-specific detail.
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 ('Create a long-lived API key') plus the concrete key format (sd_live_…) and its audience (scripts/clients that can't refresh OAuth). No sibling tool manages keys, so it is trivially distinguishable.
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?
Gives explicit when-to-use ('scripts and clients that can't refresh OAuth tokens') and prerequisites ('Needs the owner's email confirmed first' and 'Requires scope locations:write (Admin role)'). It even closes off a plausible alternative path by noting keys can't be listed or revoked over MCP.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Book a confirmed appointment (staff bookings skip the approval queue). startTime must be one get_availability offers for that type and date; any other time is rejected with conflict. Inactive appointment types can't be booked (not_found). Answer each required field from list_appointment_types. Emails the carrier a confirmation at contactEmail. Returns the new appointment. Requires scope appointments:write (Scheduler role or above).
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Notes from the carrier or scheduler, visible to staff. | |
| doorId | No | Specific door to use. Only honored when the location assigns doors; omit to auto-pick. | |
| poNumbers | No | Every purchase order on this appointment, in order. Duplicates ignoring case are dropped. When set, this wins over poReference. | |
| startTime | Yes | A startTime returned by get_availability, unchanged. | |
| driverName | No | Driver's name. | |
| locationId | Yes | Location id, from list_locations. | |
| companyName | Yes | Carrier company name. | |
| contactName | No | Carrier contact person's name. | |
| driverNotes | No | Instructions for the driver. | |
| driverPhone | No | Driver's mobile; check-in texts go here when SMS check-in is on. | |
| poReference | No | One purchase order. Kept for older clients. Prefer poNumbers when the load has more than one. If both are sent, poNumbers wins. Sending only this replaces the list with this single value. | |
| contactEmail | Yes | Carrier contact email; confirmations and changes are emailed here. | |
| contactPhone | No | Carrier contact phone, e.g. +1 214 555 0100. | |
| customFields | No | Answers to the type's booking questions, keyed by fieldDefinitions[].key, e.g. { "sealNumber": "A123" }. A MULTI_TEXT question takes an array of strings, e.g. { "customerPo": ["4501", "4502"] }. | |
| trailerNumber | No | Trailer number. | |
| appointmentTypeId | Yes | Appointment type id, from list_appointment_types (get_location_setup also lists inactive types). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses side effects (emails the carrier a confirmation at contactEmail), validation behavior (non-offered startTime is rejected with conflict; inactive type returns not_found), the approval-queue bypass, return behavior, and required scope/role. This is substantially richer than the structured hints alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded: purpose first, then constraints, validation failures, side effects, return behavior, and auth. Every sentence contributes operational information, with no filler.
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 16-parameter mutation with nested customFields and no output schema, the description covers the critical workflow, error cases, side effects, permissions, and the fact that the new appointment is returned. Optional parameter details are already fully documented in the schema, so nothing essential is 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 coverage is 100%, so the baseline is 3, but the description adds useful cross-tool provenance for two critical parameters: startTime must be an unchanged value from get_availability, and required fields should come from list_appointment_types. It does not explain every optional parameter, but it meaningfully improves the two that most affect successful invocation.
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 starts with a specific verb and resource ('Book a confirmed appointment') and immediately distinguishes the staff-booking path from the approval queue. An agent can tell this apart from siblings like approve_appointment or reschedule_appointment without reading 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?
It gives explicit preconditions: startTime must come from get_availability for that type and date, required fields must be answered from list_appointment_types, and inactive types cannot be booked. It also explains that staff bookings skip approval, which is exactly the when/when-not context an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an appointment type (what a carrier picks when booking): its length, load, direction, minimum notice, and buffers. Every door takes it unless a door is limited to other types. To add several types and doors by name at once, use set_up_location. Returns the new type with its id. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | What carriers pick when booking, e.g. "Inbound FTL". | |
| loadType | Yes | FTL = full truckload, LTL = less than truckload, DROP_TRAILER = trailer left at the dock, OCEAN_CONTAINER = ocean/drayage container, INTERMODAL = rail container, FLATBED = open deck, PARCEL = small package. | |
| direction | Yes | INBOUND = receiving, OUTBOUND = shipping. | |
| locationId | Yes | Location id, from list_locations. | |
| durationMinutes | Yes | How long the door is held for one appointment, in minutes. | |
| bufferAfterMinutes | No | Minutes the door is kept free after each appointment of this type. | |
| bufferBeforeMinutes | No | Minutes the door is kept free before each appointment of this type. | |
| minimumNoticeMinutes | No | How far ahead a booking must be made, in minutes (1440 = one day). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses the required scope and Admin role, the default effect that every door accepts the type unless limited, and that the new type is returned with an id. It does not cover duplicate-name behavior or failure modes, but it adds substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose and scope come first, the bulk alternative follows, then return value and auth requirements. Every sentence carries useful information for invoking the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich schema documentation, clear annotations, and no output schema, the description supplies the missing operational pieces: scope requirement, default door behavior, return value, and the bulk alternative. Nothing essential for correct selection or invocation appears absent.
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 all eight parameters are documented directly in the schema, including enum meanings and numeric bounds. The description only groups the fields conceptually ("length, load, direction, minimum notice, and buffers") and adds no parameter-level detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ("Add an appointment type") and immediately explains what the resource is and which fields it covers. It also distinguishes this tool from the bulk sibling set_up_location, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly routes bulk creation of several types and doors to set_up_location, giving a clear alternative and condition. It does not explicitly say when to use update_appointment_type instead, but the create-vs-bulk distinction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a question to an appointment type's booking form (Pro). DROPDOWN needs options. key is how the answer is stored (customFields.{key} on appointments); it defaults to the camelCased label and can't change later. isReference makes the answer a reference number, searchable in the appointments list. Added to the end of the form. Returns the new question with its id. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Letters and numbers, starting with a letter. | |
| label | Yes | Question shown to carriers, e.g. "Seal number". | |
| options | No | Choices; required for DROPDOWN, ignored otherwise. | |
| helpText | No | Hint shown under the question. | |
| required | No | Must be answered to book. Default false. | |
| fieldType | Yes | Answer input type. MULTI_TEXT holds a list, such as several PO numbers. | |
| locationId | Yes | Location id, from list_locations. | |
| isReference | No | Treat the answer as a searchable reference number. | |
| appointmentTypeId | Yes | Appointment type id, from list_appointment_types (get_location_setup also lists inactive types). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real behavior beyond the annotations: key is immutable once set, defaults to the camelCased label, answers land at customFields.{key}, new questions append to the end of the form, and the call returns the new question with its id. The non-idempotent and administrative nature is clear. Missing only failure behavior (e.g. duplicate key handling, plan-limit errors).
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?
Dense and front-loaded — capability first, then parameter rules, then return and permissions. The telegraphic sentence fragments are efficient but a shade harder to parse than flowing prose.
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?
Nine parameters, four required, a mutation with no output schema — the description covers prerequisites, defaults, immutability, side effects, and the return value. Nothing an agent needs before calling it is 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 coverage is 100%, so baseline is 3; the description still adds meaning the schema lacks, notably how key is derived and stored, and what isReference actually enables in the appointments list. It restates a couple of schema points (DROPDOWN options) rather than extending them.
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 ('Add a question to an appointment type's booking form') and implicitly separates it from update_booking_question / delete_booking_question by describing creation only. An agent can tell exactly what gets created and where it lands.
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?
Gives concrete preconditions: Pro plan, scope locations:write with Admin role, and the DROPDOWN-needs-options rule. It does not explicitly route the agent to update_booking_question when the question already exists, so the alternative-selection guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a dock door. By default it takes every appointment type and follows the location's hours, so it can be created before any types exist. Optionally limit it to certain types or give it its own hours (see update_door); those limits apply only when the location assigns doors (assignDoors), not in capacity mode. To add types and doors together by name, use set_up_location. Returns the new door. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Door name, e.g. "Door 4". | |
| locationId | Yes | Location id, from list_locations. | |
| weeklyHours | No | The door's own full week, clipped to the location's. Omit to follow the location's hours. | |
| appointmentTypeIds | No | Ids of the types this door takes (from list_appointment_types or get_location_setup). Omit or [] = every type, including types added later. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: it documents the default behavior (accepts every appointment type, inherits location hours), that the resource can exist before types are created, that limits are conditional on the location's door-assignment mode, that it returns the new door, and that it requires scope locations:write with the Admin role. The annotations only flag it as a non-idempotent, non-destructive write; the description supplies the operational context they lack.
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?
Dense but front-loaded with the verb and resource, and every sentence carries useful information (defaults, modes, alternatives, auth, return). The long middle sentence stacks several distinct constraints with parenthetical asides, which costs a little scanability but nothing is filler.
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 output schema exists, and the description compensates by stating it returns the new door. Combined with the defaults, mode caveats, alternatives, and required scope, an agent has everything needed to invoke this correctly and understand its side effects.
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 already 100%, so the baseline is 3. The description adds cross-cutting meaning beyond the field docs: omitting appointmentTypeIds means "every type, including types added later," and weeklyHours is "clipped to the location's," plus the note that both only matter in assignDoors mode. That elevates it slightly above baseline.
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 ("Add a dock door") and immediately distinguishes itself from siblings by naming update_door for editing and set_up_location for the combined type+door flow. An agent can tell exactly where this tool sits in the create/update family without opening any 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?
Gives explicit when-to-use context (defaults mean it can be created before any appointment types exist) plus named alternatives and the condition selecting each (use update_door for limits, set_up_location to add types and doors together by name). It also states the mode-dependent caveat that limits only apply in assignDoors mode, not capacity mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new facility (location record only). It starts with no hours, appointment types, or doors, so it can't take bookings yet: follow up with set_up_location, which configures all of that on the new locationId and returns the booking-page checklist. To edit an existing location use update_location_details or set_up_location. The Free plan allows one location; more need Pro (payment_required). Returns the location with its id and bookingPageUrl. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | Postal code. | |
| city | No | City. | |
| name | Yes | Facility name, e.g. "Acme Dallas DC". | |
| state | No | State or region, e.g. TX. | |
| address | No | Street address. | |
| country | No | Two-letter ISO country code, e.g. "US" or "AU". | |
| timezone | Yes | IANA timezone, e.g. "America/Chicago". All hours and dates use it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare it is a non-read-only, non-destructive, non-idempotent write. The description adds what the created record lacks (no hours, appointment types, or doors, so no bookings yet), the auth requirement (locations:write, Admin role), the plan limit with the payment_required failure mode, and the return payload (id and bookingPageUrl). That is substantial context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense single paragraph, front-loaded with the primary action and its key limitation, then follow-up routing, alternatives, plan constraint, and return value. Slightly packed – the auth/plan clauses could be split – but nearly every clause carries distinct decision-relevant 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?
With no output schema, the description compensates by naming what is returned (the location with id and bookingPageUrl), and it covers the post-creation workflow and permission requirements. An agent has everything needed to call it and to anticipate the follow-up call.
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 all seven parameters (including the timezone note that hours and dates use it) are already documented in the schema. The description adds no parameter-level guidance such as address-format constraints or required-vs-optional emphasis, 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?
Specific verb+resource ('Create a new facility (location record only)') with an explicit scoping caveat that distinguishes it from set_up_location and update_location_details. An agent can tell from the first sentence that this is a bare record-creation step, not a configuration step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the follow-up path ('follow up with set_up_location, which configures all of that on the new locationId'), names the alternatives for editing an existing location, and flags the plan constraint with the payment_required condition. When-to-use, when-not-to-use, and sequencing are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send appointment events to a URL (Pro). SimpleDock posts a test event first and saves the webhook only if the URL answers 2xx. Non-Slack payloads are signed: verify the X-SimpleDock-Signature header with signingSecret, which is returned only now. ZAPIER and SLACK need hooks.zapier.com / hooks.slack.com URLs; every URL must be https://. eventTypes empty = every event; locationIds empty = every location. Listing, editing, and deleting webhooks happen in Settings → Integrations, not over MCP. Returns { webhookId, signingSecret, test }. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | https:// endpoint that receives POSTed JSON events. | |
| kind | No | Default CUSTOM. | |
| label | No | Name shown in Settings, e.g. "Yard system". | |
| eventTypes | No | Events to send, e.g. appointment.created. Empty or omitted = every event. | |
| locationIds | No | Location ids from list_locations. Empty or omitted = every location. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Rich disclosure well beyond the annotations: a test event is POSTed first and the webhook is saved only on a 2xx answer, non-Slack payloads are signed and verified via X-SimpleDock-Signature, signingSecret is returned only at creation, and locations:write/Admin is required. The annotations (openWorldHint=true, non-idempotent) are consistent with this and the description amplifies rather than repeats them.
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 dense, front-loaded paragraph: the mutation-and-test semantics come first, then payload signing, then constraints and auth. Every clause is load-bearing except the minor restatement of the empty-array defaults; nothing is 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 5-param mutation with no output schema, it covers what an agent needs: return shape ({ webhookId, signingSecret, test }), side effects, auth scope, and the fact that no lifecycle management exists over MCP. Nothing material is left open.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description clears that by adding a cross-parameter constraint the schema cannot express (ZAPIER/SLACK require hooks.zapier.com / hooks.slack.com URLs, all URLs must be https://). It does re-state the "empty = every event/location" defaults already present in the schema property descriptions, which caps it below 5.
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?
"Send appointment events to a URL" is a precise verb+resource, and the description immediately qualifies scope (Pro plan, https-only, per-kind URL requirements). No sibling tool in the list does webhook registration, so the agent can place it instantly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states explicit when-not guidance: "Listing, editing, and deleting webhooks happen in Settings → Integrations, not over MCP," which stops the agent hunting for read/update/delete siblings. It also spells out the prerequisite conditions (scope locations:write, Admin role, Pro) and the kind-specific host requirements that gate a valid call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a booking question for good. Answers already given stay on past appointments but are no longer labeled; to keep them, set isActive to false with update_booking_question instead. Can't be undone. Returns { deleted: true }. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| locationId | Yes | Location id, from list_locations. | |
| questionId | Yes | Booking question id, from list_booking_questions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds material context they cannot convey: existing answers are retained on past appointments but lose their label, the operation is irreversible, the required scope/role is locations:write (Admin), and the return payload is { deleted: true }. No contradiction with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, no filler, and the most decision-relevant fact (permanent removal) plus the alternative are front-loaded before the softer details about answer retention and auth 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?
Despite having no output schema, the description states the return value; it also covers prerequisites (scope/role), side effects on existing answers, and reversibility. Nothing an agent needs to invoke this destructive tool safely is 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 coverage is 100% and both parameters already document their source (list_locations, list_booking_questions), so the schema carries the load. The description adds no extra meaning about locationId or questionId beyond what the schema states, making the baseline 3 correct.
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?
"Remove a booking question for good" gives a specific verb (remove/delete), the exact resource, and permanence in the first clause. It is unmistakably distinct from create_booking_question, list_booking_questions, and update_booking_question in the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: if the goal is to keep existing answers, use update_booking_question with isActive=false instead. It also states the irreversible "can't be undone" condition, giving both when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether the account owner has confirmed their email, and what waits until they do (appointment emails and texts, search indexing, teammate invites, API keys). An account an agent created and nobody confirmed is deleted at deletesAt. Also lists each location's booking page URL. Check it before invite_member or create_api_key, which both need a confirmed owner email. Requires scope locations:read (any member).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description correctly spends its words on non-obvious behavior instead: unconfirmed agent-created accounts are deleted at deletesAt, and confirmation gates appointment emails/texts, search indexing, invites, and API keys. That is genuinely additive. It stops short of describing result freshness or what an empty/uninitialized account looks like, so not a 5.
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?
Front-loaded with the core answer (is the owner confirmed) and no wasted framing; the blocked-features list is a parenthetical enumeration that earns its space by explaining consequences. It is dense but tightly packed, with the dependency warning and scope at the end where they belong.
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?
There is no output schema, so the description must carry the return payload — and it does, enumerating confirmation status, blocked capabilities, deletesAt, and location booking page URLs. Combined with the scope note and cross-tool dependency, an agent has everything needed to call and interpret this correctly.
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 no parameter semantics to explain and the baseline of 4 applies. The description correctly avoids padding with irrelevant argument talk.
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 resource and the exact facts it returns: email-confirmation state, what is blocked until confirmation, deletion at deletesAt, and each location's booking page URL. This clearly separates it from siblings like verify_email, resend_verification_email, and get_location_setup, which an agent might otherwise confuse it with.
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?
Gives explicit when-to-use routing: 'Check it before invite_member or create_api_key, which both need a confirmed owner email' — naming two concrete siblings and the condition that triggers this call. It also names the scope (locations:read, any member), so prerequisites are settled before invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-location appointment summary (counts by status and type) over a date range, for reporting questions like "how many no-shows last month". Use list_appointments for the appointments themselves. Defaults to the last 30 days; the range may not exceed 366 days. Pro plan only (otherwise payment_required). Requires scope analytics:read (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Range end. ISO 8601 datetime with offset, e.g. 2026-10-15T08:00:00-05:00. Default: now. | |
| from | No | Range start. ISO 8601 datetime with offset, e.g. 2026-10-15T08:00:00-05:00. Default: 30 days before to. | |
| locationId | Yes | Location id, from list_locations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description layers on the behavior that matters: Pro-plan gating with the specific error (payment_required), the analytics:read scope and Admin role requirement, a 30-day default window, and a hard 366-day range cap. These are operational constraints not derivable from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each carrying distinct information: what it returns, when to use it versus the alternative, range defaults/limits, and access requirements. Front-loaded with the output shape so the agent knows what it gets before reading constraints.
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 output schema exists, and the description compensates by naming the returned aggregation (counts by status and type) plus the grouping dimension (per-location). Access, plan, and range constraints are all covered, so an agent has everything needed to call it correctly or predict a failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the per-parameter documentation is already handled, and the baseline would be 3. The description adds range semantics beyond the schema — the 30-day default and the 366-day maximum — which are genuine constraints the schema does not state.
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 ('Per-location appointment summary (counts by status and type) over a date range') and explicitly contrasts itself with the sibling list_appointments. An agent can distinguish this reporting tool from the appointment-listing tools without opening any 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?
Gives a concrete use case ('how many no-shows last month'), names the alternative tool and when to prefer it ('Use list_appointments for the appointments themselves'), and states both plan gating (Pro only, otherwise payment_required) and required scope (analytics:read, Admin role). Nothing about when to select this tool is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one appointment by id: status, start/end (ISO 8601 UTC), carrier and driver details, PO numbers (poNumbers, plus poReference as the first), custom field answers, driver check-in (arrivalStatus, estimatedDelay), recurring series (seriesId; needsDetails when required details are still blank), and approval, arrival, and completion timestamps. Use it to re-read an appointment before changing it; to search by date, status, or carrier, use list_appointments. Read-only. Requires scope appointments:read (any member).
| Name | Required | Description | Default |
|---|---|---|---|
| appointmentId | Yes | Appointment id, from list_appointments, get_appointment, or create_appointment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive, so 'Read-only' is partly redundant, but the description adds the required OAuth scope ('appointments:read, any member'), which no structured field carries. It also describes the returned data shape, useful given there is no output schema.
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?
Front-loaded with the core action, then the return-field enumeration and the routing note. The field list makes it a long run-on sentence, but every clause carries information an agent can act on.
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 no output schema, the description covers the action, the returned fields, the sibling alternative, the auth scope, and the safety profile. There is nothing an agent needs to call it correctly that is 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 coverage is 100% and the single appointmentId parameter is fully documented in the schema, including where to obtain it. The description only restates 'by id', so it adds no meaning beyond the schema — 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 ('Fetch one appointment by id') and then enumerates the payload it returns (status, timestamps, PO numbers, check-in, series). It is unambiguously distinguishable from list_appointments and the mutation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('re-read an appointment before changing it') and names the alternative plus the selection condition ('to search by date, status, or carrier, use list_appointments'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the start times a carrier can book for one appointment type on one day. Call it before create_appointment or reschedule_appointment: only these times are accepted. date is a calendar day in the location's own timezone. Returns [{ startTime, endTime, displayTime }]: startTime/endTime are ISO 8601 UTC (pass startTime unchanged to the booking tools), displayTime is local, e.g. "8:30 AM". An empty list means nothing is open that day (closed, full, or inside the type's minimum notice); get_location_setup explains why. Requires scope appointments:read (any member).
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | YYYY-MM-DD in the location's timezone, e.g. 2026-10-15. | |
| locationId | Yes | Location id, from list_locations. | |
| appointmentTypeId | Yes | Appointment type id, from list_appointment_types (get_location_setup also lists inactive types). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavior: the three causes of an empty list (closed, full, minimum notice), the required scope (appointments:read, any member), and the constraint that returned startTime values must be passed unchanged. That is substantial context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense paragraph front-loaded with the purpose and the call-order obligation, then the date semantics, return shape, empty-list meaning, and auth scope. Every sentence carries information an agent needs; nothing is redundant.
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?
There is no output schema, and the description compensates by describing the return shape ([{ startTime, endTime, displayTime }]) with formats and an example, plus the empty-list case. For a 3-required-param read tool, nothing needed to call it correctly is 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% and already documents that date is YYYY-MM-DD in the location's timezone and where locationId/appointmentTypeId come from. The description restates the timezone point for date but adds no format or constraint detail the schema lacks, so the 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 and resource with scope: "List the start times a carrier can book for one appointment type on one day." An agent can immediately distinguish this availability-query tool from siblings like create_appointment or list_appointments without opening any 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?
Explicitly says when to call it ("before create_appointment or reschedule_appointment: only these times are accepted") and routes the agent elsewhere for a related question ("get_location_setup explains why" an empty list occurs). Both the precondition and the fallback are stated, not implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The public booking link carriers use (/book/{slug}) and whether it can take bookings: acceptingBookings is false until the location has weekly hours, an active appointment type, and (when it assigns doors) an active door. problems says what to fix. Use it to share the link or check readiness; for the full configuration behind it, use get_location_setup. Read-only. Requires scope locations:read (any member).
| Name | Required | Description | Default |
|---|---|---|---|
| locationId | Yes | Location id, from list_locations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, but the description adds meaningfully more: the required scope (locations:read, any member), the precise gating logic for acceptingBookings (weekly hours, active appointment type, active door), and the semantics of the problems field. This is behavior an agent could not infer from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the resource and its return meaning, then use cases, then sibling routing. Dense with semicolons, but nearly every clause carries distinct information; only the parenthetical about doors is slightly tangential to invoking the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining returns, and it does: acceptingBookings and problems are named and their meaning given. Combined with the auth scope and readiness preconditions, an agent has everything needed for a correct call and interpretation.
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% for the single locationId parameter, and the schema already says it comes from list_locations. The description adds no format, syntax, or edge-case detail about locationId, 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?
States a specific verb+resource: retrieves the public booking link (/book/{slug}) and the readiness state of a location's booking page. It also names the sibling it is not (get_location_setup) and clarifies the scope of what it returns, so an agent can distinguish it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives two use cases (share the link, check readiness) and routes the agent to the alternative for full configuration: 'for the full configuration behind it, use get_location_setup.' Nothing is left to inference about when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything about how a location is set up, in one call: its name, address, and timezone; scheduling settings (start-time spacing, approval, door mode); weekly hours; appointment types (including inactive ones); doors with their type limits and own hours; and upcoming closures (with the closure ids remove_closure takes). Read this before changing setup or when diagnosing missing times. It is a superset of list_appointment_types (active types with booking fields, for booking), list_doors (just door ids and names), and get_booking_page (the public link and what blocks bookings): use those narrower reads when that's all you need, since they don't need an Admin role. Read-only. OAuth tokens need an Admin role. Requires scope locations:read (any member).
| Name | Required | Description | Default |
|---|---|---|---|
| locationId | Yes | Location id, from list_locations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, but the description adds the auth and scope requirements annotations cannot express: OAuth tokens need an Admin role while the scope locations:read needs any member. It also discloses that inactive appointment types are returned and that closure ids are compatible with remove_closure, which is real behavioral context rather than a restatement of the safety hints.
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?
Front-loaded with the one-call scope statement, and every sentence carries distinct information (contents, when to use, alternatives, auth). It is dense and semicolon-packed, which slows parsing slightly, but there is no filler to cut.
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 the return shape, and it does so field-group by field-group, including non-obvious items like inactive appointment types and upcoming closures. Auth, scope, and sibling relationships are all covered, so an agent has everything needed to call it correctly.
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 locationId parameter is already documented as originating from list_locations, so the schema does the heavy lifting. The description adds no format, syntax, or validation detail beyond what the schema provides; baseline 3 is correct.
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 (location setup) and then enumerates exactly what the payload contains: name/address/timezone, scheduling settings, weekly hours, appointment types, doors, and upcoming closures. It explicitly positions itself as a superset of list_appointment_types, list_doors, and get_booking_page, so an agent can distinguish it from siblings without opening any 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?
Gives explicit when-to-use ('Read this before changing setup or when diagnosing missing times') and names three alternatives with the condition that selects each ('use those narrower reads when that's all you need, since they don't need an Admin role'). The tradeoff between breadth and privilege is spelled out, 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.
Email someone an invitation to join the organization. Roles: ADMIN (full access, including members and billing), SCHEDULER (book and manage appointments), DOCK_STAFF (mark trucks arrived and done). Needs the owner's email confirmed first. The Free plan includes 3 teammates plus unlimited DOCK_STAFF; past that the invite is payment_required. Listing, changing, and removing members happen in Settings → Members, not over MCP. Returns { invited, role }. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | Access level once they accept; see the description for what each role can do. | |
| Yes | Invitee's email address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the mutation profile, and the description adds context beyond them: the confirmed-owner-email prerequisite, the plan/quota failure mode, the required scope (locations:write, Admin role), and the exact return shape. This is a mutation tool and the description covers consequences and prerequisites thoroughly.
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?
Purpose is front-loaded and every sentence carries load (roles, prerequisite, quota, exclusions, return, scope). Dense but slightly cluttered by embedded plan and scope details that could be ordered more cleanly.
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 mutation tool with no output schema, the description covers purpose, roles, prerequisites, quota behavior, sibling exclusions, return values, and required auth scope. Nothing an agent needs to call it correctly is 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 coverage is 100%, but the schema's role parameter description explicitly defers role meaning to the description, and the description defines ADMIN, SCHEDULER, and DOCK_STAFF capabilities. The email parameter is left to the schema, so it exceeds the baseline without fully documenting every parameter.
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?
Opens with a specific verb and resource ('Email someone an invitation to join the organization'), which is immediately distinguishable from every sibling tool in the list. No restating of the title or tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent away for the adjacent operations: 'Listing, changing, and removing members happen in Settings → Members, not over MCP.' It also states the precondition (owner's email must be confirmed) and the plan-limit consequence (payment_required past the Free tier).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search appointments across the organization, optionally filtered by location, status, and start-time range, sorted by start time. Use it to find an appointment (e.g. today's PENDING requests to approve); use get_appointment when you already have the id. Returns { data: [appointment], nextCursor }; pass nextCursor back as cursor for the next page (null = last page). Requires scope appointments:read (any member).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Latest start time, inclusive. ISO 8601 datetime with offset, e.g. 2026-10-15T08:00:00-05:00. | |
| from | No | Earliest start time, inclusive. ISO 8601 datetime with offset, e.g. 2026-10-15T08:00:00-05:00. | |
| limit | No | Page size, 1–100. Default 50. | |
| cursor | No | nextCursor from the previous page. | |
| status | No | Only this status. PENDING = awaiting approval. Omit for all. | |
| locationId | No | Only this location. Omit for every location. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description goes further with details annotations cannot express: the return shape '{ data: [appointment], nextCursor }', the pagination loop ('pass nextCursor back as cursor; null = last page'), and the required scope 'appointments:read (any member)'. That is exactly the behavioral context an agent needs beyond structured hints.
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 compact sentences with zero filler, ordered purpose → when-to-use/alternative → return-and-pagination → permission. The most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description's explicit return shape and cursor semantics fully cover what the agent would otherwise have to guess. With a 6-parameter, zero-required, fully documented schema and rich annotations, no call-critical information is 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 coverage is 100% with per-parameter descriptions and ISO-8601 examples, so the baseline is 3. The description adds meaning the schema lacks: the implicit result ordering ('sorted by start time') and the fact that the filters compose into a single filtered query. It does not, however, add syntax or edge-case detail beyond that.
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 ('Search appointments across the organization') plus the filter scope and the sort order. It explicitly distinguishes itself from the sibling get_appointment, so an agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete use case ('find an appointment, e.g. today's PENDING requests to approve') and names the alternative tool with the exact condition that selects it ('use get_appointment when you already have the id'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the appointment types a location offers (active ones) with their custom field definitions. Call this first: create_appointment and get_availability both need an appointmentTypeId, and bookings must satisfy each type's required fields. Inactive types are in get_location_setup; for the full booking-form layout use list_booking_questions. Requires scope locations:read (any member).
| Name | Required | Description | Default |
|---|---|---|---|
| locationId | Yes | Location id, from list_locations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe read-only, idempotent profile, but the description adds genuinely new behavioral facts: results are limited to active types, inactive ones live in get_location_setup, and the call requires the locations:read scope available to any member. It stops short of describing pagination or ordering, but the auth and filtering behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four compact sentences that front-load what the tool returns, then sequencing, then alternatives, then prerequisites. Every clause carries distinct information with no redundancy or filler.
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 correctly carries the return-shape burden ('active ones with their custom field definitions') and adds the prerequisite scope and the reasons a caller needs it. For a single-parameter read tool, an agent has everything required to call it correctly and interpret the result.
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 locationId parameter already documents its source (list_locations), so the schema does the heavy lifting. The description adds no format, validation, or sourcing detail beyond that, which is the expected baseline when coverage is complete.
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 appointment types) plus meaningful scope qualifiers: active-only, per-location, and including custom field definitions. It explicitly distinguishes itself from get_location_setup (inactive types) and list_booking_questions (form layout), so an agent can tell it apart from siblings without opening schemas.
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?
Explicit sequencing instruction ('Call this first'), the concrete downstream consumers (create_appointment, get_availability) and why they need it (appointmentTypeId, required-field validation), plus named alternatives with their respective conditions. Nothing about when to use this vs. alternatives is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The extra questions carriers answer when booking, per appointment type, in form order. Also lists which built-in fields (driverName, trailerNumber, poReference, …) each type hides or requires, and each question's id for update_booking_question and delete_booking_question. Includes inactive questions; list_appointment_types shows only the active ones a booking must answer. Requires scope locations:read (any member).
| Name | Required | Description | Default |
|---|---|---|---|
| locationId | Yes | Location id, from list_locations. | |
| appointmentTypeId | No | Only this type. Omit for every type. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds valuable context beyond annotations: it discloses that inactive questions are included, that built-in fields' hide/require status is returned, and that the operation requires the locations:read scope. It does not mention pagination or response size limits, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with what the tool returns and followed by scope and sibling contrast. Every sentence adds distinct information (return contents, sibling differentiation, required scope) with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining return values. It does so clearly: the questions, their form order, built-in field hide/require status, and question ids for update/delete tools. Combined with annotations covering safety and the schema covering inputs, the definition is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds only marginal meaning beyond the schema: it reinforces that questions are returned 'per appointment type' but does not explain syntax, defaults, or filtering nuances beyond what the schema already documents. Baseline 3 is appropriate when the schema carries the parameter documentation.
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 booking questions') and immediately details the exact contents: carrier questions per appointment type, form order, built-in field visibility, and question ids. It also contrasts with the sibling list_appointment_types, which returns only active questions, so an agent can distinguish the tools without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that inactive questions are included and directs the agent to list_appointment_types for only the active questions a booking must answer. It also names the required scope (locations:read, any member), giving clear conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a location's dock doors as { id, name, sortOrder, isActive }, including inactive ones, in display order. Use it to get a doorId for create_appointment, reschedule_appointment, or update_door. For each door's appointment-type limits and own hours, use get_location_setup instead. Requires scope locations:read (any member).
| Name | Required | Description | Default |
|---|---|---|---|
| locationId | Yes | Location id, from list_locations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, non-open-world, but the description adds value beyond them: inactive doors are returned, results come in display order, and access requires the locations:read scope for any member. Authorization and result-set breadth are exactly the behaviors annotations cannot express.
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 tight sentences: return shape first, then usage routing, then the alternative and the scope requirement. No filler, and the most load-bearing content (what it returns and why to call it) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by naming the returned fields and ordering, and it covers auth scope, inactive-record inclusion, and the sibling alternative. Nothing an agent needs to select or invoke this read tool correctly is 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?
Only one parameter, documented at 100% schema coverage ('Location id, from list_locations'), so the schema carries the semantics. The description adds no format or syntax detail about locationId, matching the baseline 3 for single-parameter tools whose schema is complete.
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 a location's dock doors') and even enumerates the returned fields ({ id, name, sortOrder, isActive }), including the non-obvious detail that inactive doors are included. It further narrows the scope against the adjacent sibling get_location_setup, so an agent can distinguish it immediately.
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?
Gives an explicit positive use case (obtain a doorId to feed create_appointment, reschedule_appointment, or update_door) and an explicit exclusion routing to get_location_setup for appointment-type limits and door hours. Both when-to-use and when-not-to-use are stated rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every dock location (facility) in the organization with its id, name, address, IANA timezone, and booking-page slug. Start here: almost every other tool needs a locationId. If there is only one location, use it as the default. Requires scope locations:read (any member).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the read-only, idempotent, non-destructive, closed-world profile, so the safety bar is low. The description goes beyond them by stating the required scope (locations:read, any member) and the single-location defaulting behavior, both of which are operationally useful.
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, each load-bearing: what is returned, when to call it first, and the one-location edge case. The most important routing hint ("Start here") is front-loaded after the resource statement.
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 compensates by listing the concrete fields returned and the id used as a foreign key elsewhere. Auth requirements and the degenerate single-location case are both covered, so an agent has everything needed to call and use the result.
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 the schema is trivially complete and the baseline is 4. The description correctly avoids inventing parameter semantics that do not exist.
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) plus resource (dock location / facility) and enumerates the returned fields (id, name, address, timezone, booking-page slug). This distinguishes it immediately from create_location, update_location_details, and list_doors in the sibling set.
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?
Explicit workflow positioning: "Start here: almost every other tool needs a locationId" tells the agent when to reach for this tool before others. It also handles the single-location edge case with a default rule, though it does not name a competing alternative to avoid, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record that a truck has physically arrived at the dock (e.g. "the Swift driver just pulled in"). Starts the dwell-time clock, which ends when the appointment is marked COMPLETED. Pass arrived: false to undo a mistaken arrival; repeating it keeps the first arrival time. Status stays as is: when the truck leaves, use set_appointment_status COMPLETED. Not the same as check_in_appointment, which records the driver's own on-track or running-late update before arrival. Fires an appointment.arrived webhook; no carrier email. Returns the updated appointment (checkedInAt is the arrival time). Requires scope appointments:receive (Dock Staff role or above).
| Name | Required | Description | Default |
|---|---|---|---|
| arrived | No | Defaults to true. false clears the arrival. | |
| appointmentId | Yes | Appointment id, from list_appointments, get_appointment, or create_appointment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety/idempotency profile; the description goes well beyond by disclosing the dwell-time clock lifecycle, idempotent repeat behavior (keeps first arrival time), the appointment.arrived webhook, the absence of a carrier email, the return payload, and the required appointments:receive scope with role prerequisite.
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?
Dense but front-loaded: the core action and dwell-clock effect come first, followed by undo, alternatives, side effects, and auth. Every sentence carries distinct information, though the single-paragraph density is slightly heavier than necessary.
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 output schema exists, yet the description explains the return value (updated appointment with checkedInAt as arrival time). Combined with webhook, auth scope, and sibling routing, an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantics beyond it: arrived:false undoes a mistaken arrival and repeated calls preserve the first arrival time. The appointmentId parameter is left to the schema, which is fine at full coverage.
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 ('Record that a truck has physically arrived at the dock') and immediately differentiates it from two siblings, check_in_appointment and set_appointment_status COMPLETED. An agent can select it correctly without opening any 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?
Gives explicit when-to-use ('truck has physically arrived'), when-not ('Not the same as check_in_appointment, which records the driver's own on-track or running-late update'), and the correct alternative for the departure event (set_appointment_status COMPLETED). Undo behavior is also spelled out via arrived: false.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn down a PENDING booking request; it becomes CANCELLED with rejectedAt and the reason recorded. Only for PENDING; otherwise conflict. Use this, not cancel_appointment, when declining a request; to call off an already CONFIRMED appointment use cancel_appointment. Emails the carrier that the request was declined. Final: can't be undone. Returns the updated appointment. Requires scope appointments:write (Scheduler role or above).
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Optional reason, stored as rejectionReason, e.g. "No doors free that morning". | |
| appointmentId | Yes | Appointment id, from list_appointments, get_appointment, or create_appointment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (destructive, not read-only), and the description layers on the concrete behaviors an agent actually needs: the PENDING→CANCELLED transition, the recorded rejectedAt/reason, a conflict on non-PENDING input, a side effect (emails the carrier), irreversibility ('Final: can't be undone'), and the required scope (appointments:write, Scheduler role or above). This goes well beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and state change, then routing, side effects, irreversibility, and auth in a tight sequence. Every sentence carries distinct operational information; nothing is padding.
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, it still tells the agent what comes back ('Returns the updated appointment') and covers preconditions, error behavior, side effects, reversibility, and required scope. An agent has everything needed to invoke it correctly.
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, including that reason is stored as rejectionReason. The description repeats the recording behavior but adds no format, length, or validation detail beyond the schema, 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?
States a precise verb (turn down), resource (a PENDING booking request) and the resulting state change (becomes CANCELLED with rejectedAt and reason recorded). It explicitly names the sibling it is not (cancel_appointment), so an agent can distinguish it from the adjacent cancellation tool 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit precondition ('Only for PENDING; otherwise conflict') and a direct routing rule: use this, not cancel_appointment, when declining a request; use cancel_appointment for an already CONFIRMED appointment. Both the when and the when-not are stated, with the alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reopen one closed date added by add_closed_dates, so its normal weekly hours apply again. Takes a closure id from get_location_setup's upcomingClosures (one per date). Returns { removed: true }; an unknown id is not_found. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| closureId | Yes | id from get_location_setup's upcomingClosures. | |
| locationId | Yes | Location id, from list_locations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: returns { removed: true }, unknown id yields not_found, and requires scope locations:write with Admin role. The description clarifies the idempotent semantics of reopening an already-open date and the authorization requirement.
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 tight sentences front-loading the action, followed by id source, return shape, and auth requirement in priority order. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a 2-param mutation with annotations and no output schema. The description covers the reversal semantics, return value, error case, and required scope, leaving no gap for an agent to call correctly.
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 locationId and closureId are documented in the schema with clear provenance descriptions. The description's mention of 'a closure id from get_location_setup's upcomingClosures' reinforces but does not extend what the schema provides, 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?
Specific verb (Reopen) + resource (closed date) with explicit scope (one date added by add_closed_dates) and names the sibling tool it depends on. Clearly distinguishable from siblings like add_closed_dates and set_weekly_hours.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the single-date granularity and the source of the id (get_location_setup's upcomingClosures). Names the prerequisite tool chain (add_closed_dates creates, get_location_setup provides the id), 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.
Move a CONFIRMED appointment to a new start time and optional door. The new time must be one get_availability offers (the appointment's own slot doesn't count against it); otherwise conflict. For a PENDING request, pass startTime to approve_appointment instead. Emails the carrier the new time and alerts the facility. Returns the updated appointment. Requires scope appointments:write (Scheduler role or above).
| Name | Required | Description | Default |
|---|---|---|---|
| doorId | No | Move to this door too. Omit to keep or auto-pick a door. | |
| startTime | Yes | New start: a startTime returned by get_availability, unchanged. | |
| appointmentId | Yes | Appointment id, from list_appointments, get_appointment, or create_appointment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing side effects (emails the carrier, alerts the facility), the required authorization scope (appointments:write, Scheduler role or above), and the return value. The conflict rule and the note that the appointment's own slot doesn't count against availability add operational context the annotations cannot express.
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?
Front-loaded with the action and its status precondition, and every clause carries information. The parenthetical about the appointment's own slot and the trailing authorization sentence make it slightly dense for a single paragraph, but nothing is wasted.
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 still states what is returned (the updated appointment). Authorization, side effects, failure mode, and the alternative tool are all covered, which is complete for a 3-parameter mutation.
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 already 100%, so the baseline is 3, but the description adds real meaning: startTime must be an unmodified value from get_availability, and doorId is optional with an auto-pick fallback. This is more than the schema restates.
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 ('Move a CONFIRMED appointment to a new start time and optional door') with an explicit precondition on status. It distinguishes itself from approve_appointment by routing PENDING requests elsewhere, so an agent can select it 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?
Explicit when-to-use and when-not-to-use: CONFIRMED goes here, PENDING goes to approve_appointment. It further constrains the valid input to a startTime that get_availability offered, and states the failure mode (conflict) if not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send the owner a new confirmation email (link and code). Earlier links and codes stop working. Limited to a few per hour (rate_limited). Use only when the user hasn't received a code or verify_email says codes are locked. Requires scope locations:read (any member).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations flag destructiveHint/openWorldHint but not the specifics; the description supplies them: previous links and codes are invalidated (i.e., what actually gets destroyed), a rate limit of a few per hour with the rate_limited signal, and the required auth scope. That is real behavioral context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with the action, then consequences, then limits, then guidance. Every sentence carries unique operational information with no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers action, side effects, rate limit, prerequisites and routing to verify_email, which is more than enough for a no-argument action tool. The only omission is what the response looks like (no output schema exists), a minor 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a no-parameter tool applies. No wasted effort restating nonexistent inputs.
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 (send a new confirmation email to the owner) plus the payload (link and code). It is clearly distinguishable from the sibling verify_email, which is the validation counterpart rather than the re-issuing one.
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?
Gives an explicit trigger ('use only when the user hasn't received a code or verify_email says codes are locked') and implicitly excludes routine verification by naming the condition. It also states the required scope (locations:read, any member), which is a genuine prerequisite for calling it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record how a truck turned out: COMPLETED (unloaded/loaded and gone; ends dwell time) or NO_SHOW (never came). Both are final and can't be undone here. CONFIRMED also works on a PENDING request but silently, with no carrier email; use approve_appointment to approve and notify. Don't use it to cancel (cancel_appointment), reject (reject_appointment), log arrival (mark_arrived), or log a driver update (check_in_appointment). Setting the current status is a no-op. Fires a webhook; no carrier email. CONFIRMED additionally needs appointments:write (Scheduler role). Requires scope appointments:receive (Dock Staff role or above).
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | COMPLETED or NO_SHOW for dock outcomes; CONFIRMED to confirm without emailing. | |
| appointmentId | Yes | Appointment id, from list_appointments, get_appointment, or create_appointment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring destructive=false/write/idempotent, the description adds substantial context: COMPLETED and NO_SHOW are final and irreversible, a webhook fires but no carrier email, and CONFIRMED is silent. It also discloses the required OAuth scopes and roles (appointments:receive, appointments:write). Nothing here contradicts the annotations, and it aligns with destructiveHint=true and idempotentHint=true.
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?
Front-loaded with the outcome semantics, then exclusions, then side effects and auth. Very information-dense with little waste, though it reads as a somewhat long run-on string of clauses.
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 2-param tool with no output schema, the description covers enum meanings, irreversibility, webhook/email side effects, no-op behavior, sibling routing, and auth requirements. Nothing an agent needs to call it correctly is 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 coverage is 100%, so the baseline is 3, but the description goes beyond the brief enum text by explaining COMPLETED ends dwell time, NO_SHOW means the truck never came, and CONFIRMED confirms without emailing. This adds real meaning over the schema's one-line enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Record how a truck turned out') and enumerates the exact statuses (COMPLETED, NO_SHOW, CONFIRMED) with their meanings. It clearly distinguishes itself from the several sibling status-changing tools by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: use approve_appointment to approve and notify, and don't use this for cancel (cancel_appointment), reject (reject_appointment), arrival (mark_arrived), or driver updates (check_in_appointment). It also names the no-op case. When/when-not/alternatives are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure an existing location in one call: scheduling settings, weekly hours, appointment types, and doors, applied together (a bad entry changes nothing). Every part is optional. Types and doors are matched by name: a name that already exists at the location is updated (and reactivated if it was inactive), a new one is created, and anything you leave out is untouched, so repeating the call is safe. Doors refer to types by name, so you don't need ids. It doesn't create the location itself (use create_location first). Prefer it for first-time setup or several changes at once; for a single change the focused tools are simpler: update_location_settings, set_weekly_hours, create_/update_appointment_type, create_/update_door. Returns the full setup and the booking-page checklist (bookingPage.problems is empty when carriers can book). Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| doors | No | Doors to create, or to update when the name already exists at the location. | |
| settings | No | Same fields as update_location_settings. Omitted fields are unchanged. | |
| locationId | Yes | Location id, from list_locations. | |
| weeklyHours | No | Days you leave out keep their hours; an empty windows list closes that day. | |
| appointmentTypes | No | Types to create, or to update when the name already exists at the location. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: transactional atomicity ('a bad entry changes nothing'), upsert-by-name semantics with reactivation of inactive items, the rule that omitted items are untouched so the call is safe to repeat, and the scope requirement locations:write (Admin role). It also describes the return payload (full setup plus bookingPage.problems checklist), which the annotations cannot convey.
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?
Front-loaded with the core action and scope, then prerequisites, then alternatives, then return and auth — a sensible ordering. Some sentences are slightly redundant with structured data ('repeating the call is safe' overlaps idempotentHint=true), keeping it just short of maximally tight.
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 5-parameter nested-object tool with no output schema, the description covers prerequisite, alternatives, atomicity, merge semantics, authorization scope, and the shape of the return value. Nothing material an agent needs in order to call it correctly is 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 the baseline is 3; the description still adds real value the schema does not state, namely that types and doors are matched by name, that existing names are updated and reactivated, and that doors reference types by name so ids are unnecessary. It does not detail the settings or weekly-hours parameters, but those are already well documented in-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?
States a specific verb and resource ('Configure an existing location') and enumerates exactly what the single call bundles: scheduling settings, weekly hours, appointment types, and doors. It explicitly separates itself from create_location and from the focused update tools, so an agent can identify it without opening a 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?
Gives explicit routing rules in both directions: 'Prefer it for first-time setup or several changes at once; for a single change the focused tools are simpler: update_location_settings, set_weekly_hours, create_/update_appointment_type, create_/update_door.' It also states the prerequisite ('doesn't create the location itself (use create_location first)') and the required scope/role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace a location's hours for the listed days (days you leave out are unchanged; an empty windows list closes that day). A booking must fit entirely inside one window, so to offer fixed slots, make each window exactly one appointment long: 08:00–10:00 and 10:30–12:30 with a 2-hour type offer only 8:00 and 10:30. For one-off closures (holidays) use add_closed_dates instead. Returns the full location setup. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes | One entry per day to replace; at least one. | |
| locationId | Yes | Location id, from list_locations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (destructive/idempotent/not read-only), and the description adds context annotations cannot express: partial-replace semantics, the invariant that a booking must fit inside a single window, the return value ('full location setup'), and the required scope/role (locations:write, Admin).
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?
Front-loads the core replace behavior, then usage guidance, the alternative tool, return value, and auth requirement in a logical order with no filler. The fixed-slot example is dense but earns its place by clarifying a non-obvious window-sizing rule.
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 mutation tool with nested params, no output schema, and annotations covering safety, the description supplies everything else an agent needs: replace scope, window invariants, alternative tool, return value, and auth requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes further by interpreting the windows/day semantics (empty list closes the day, window length constrains bookable slots) in a way the schema field descriptions alone do not convey. It does not add syntax details beyond what the schema already specifies.
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 ('Replace a location's hours for the listed days') and immediately clarifies replace semantics (omitted days unchanged, empty windows closes a day). It also distinguishes itself from the sibling add_closed_dates, so an agent can separate these 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes one-off closures to add_closed_dates, and gives a concrete pattern for producing fixed slots via one-appointment-long windows. Both the when-to-use and the when-to-use-something-else conditions are stated, not inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an appointment's carrier, driver, and reference fields (company, contact, driver, trailer, PO, notes), in any status. Omitted or empty string fields are left unchanged; those fields can't be cleared. poNumbers, when sent, replaces the whole PO list (send [] to clear it) and wins over poReference. Doesn't change time, door, or status: use reschedule_appointment to move it and the status tools to approve, cancel, or complete it. Doesn't email the carrier; fires an appointment.updated webhook. Returns the updated appointment. Requires scope appointments:write (Scheduler role or above).
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Notes from the carrier or scheduler, visible to staff. | |
| poNumbers | No | Replaces every PO on the appointment. Send [] to clear them. Omit to leave the list alone. Wins over poReference when both are sent. | |
| driverName | No | Driver's name. | |
| companyName | No | Carrier company name. | |
| contactName | No | Carrier contact person's name. | |
| driverNotes | No | Instructions for the driver. | |
| driverPhone | No | Driver's mobile; check-in texts go here when SMS check-in is on. | |
| poReference | No | One purchase order. Kept for older clients. Prefer poNumbers when the load has more than one. If both are sent, poNumbers wins. Sending only this replaces the list with this single value. | |
| contactEmail | No | Carrier contact email; confirmations and changes are emailed here. | |
| contactPhone | No | Carrier contact phone, e.g. +1 214 555 0100. | |
| appointmentId | Yes | Appointment id, from list_appointments, get_appointment, or create_appointment. | |
| trailerNumber | No | Trailer number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that omitted or empty fields are left unchanged, that most fields cannot be cleared, that poNumbers replaces the whole PO list and overrides poReference, that a webhook fires, that the carrier is not emailed, that the updated appointment is returned, and that appointments:write scope is required. This is rich behavioral context for a destructive 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?
The description is dense but front-loaded: it starts with what is edited, then gives constraints, then alternatives, side effects, return value, and permissions. Every sentence adds actionable 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 12-parameter mutation with no output schema, the description covers purpose, field behavior, alternatives, side effects, return value, and required scope. It gives an agent everything needed to invoke the tool correctly.
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 schema already explains each parameter. The description adds meaningful semantics beyond the schema, especially around omission behavior, empty strings, poNumbers clearing and precedence over poReference.
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 — editing an appointment's carrier, driver, and reference fields — and enumerates the fields affected. It clearly distinguishes this tool from siblings like reschedule_appointment and the status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool versus alternatives: use reschedule_appointment to move the appointment, and the status tools to approve, cancel, or complete it. It also notes that time, door, and status are not changed here, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an appointment type. Omitted fields are left unchanged. Set isActive to false to stop offering it without deleting it or its history; existing appointments keep their times. Returns the updated type. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | What carriers pick when booking, e.g. "Inbound FTL". | |
| isActive | No | false = no longer bookable; true = offer it again. | |
| loadType | No | FTL = full truckload, LTL = less than truckload, DROP_TRAILER = trailer left at the dock, OCEAN_CONTAINER = ocean/drayage container, INTERMODAL = rail container, FLATBED = open deck, PARCEL = small package. | |
| direction | No | INBOUND = receiving, OUTBOUND = shipping. | |
| locationId | Yes | Location id, from list_locations. | |
| durationMinutes | No | How long the door is held for one appointment, in minutes. | |
| appointmentTypeId | Yes | Appointment type id, from list_appointment_types (get_location_setup also lists inactive types). | |
| bufferAfterMinutes | No | Minutes the door is kept free after each appointment of this type. | |
| bufferBeforeMinutes | No | Minutes the door is kept free before each appointment of this type. | |
| minimumNoticeMinutes | No | How far ahead a booking must be made, in minutes (1440 = one day). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the annotations: partial-update semantics, that deactivation preserves history and does not move existing appointments, the returned value, and the required scope/Admin role. The annotations already carry readOnly=false, destructiveHint=true, and idempotentHint=true, so the description's job is largely to explain consequences, which it does for the deactivation path. It does not spell out what happens when loadType, direction, or duration changes affect already-booked appointments, which is the remaining side-effect question.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the action, then the update contract, then the highest-risk consequence, then auth. Every sentence carries decision-relevant information with no filler.
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 10-parameter mutation with full schema coverage and no output schema, the description supplies the pieces the schema cannot: partial-update behavior, the non-destructive deactivation path, the return value, and the auth requirement. An agent has enough to invoke it correctly without guessing.
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 schema already documents enums, ranges, and ID provenance, so that baseline applies. The description's only parameter-level addition is the omitted-fields-are-unchanged convention and the isActive=false meaning, both already partly covered by the schema's own field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Edit an appointment type" states a specific verb and resource, and the ID fields make the target scope unambiguous. It is clearly distinguished from create_appointment_type, delete-type siblings, and update_appointment_details by operating on the type's configuration rather than an individual appointment.
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?
Gives a concrete when-to-use rule that matters operationally: use isActive=false to retire a type rather than deleting it. It also states the partial-update contract (omitted fields unchanged), so agents know they need not resend the whole object. It doesn't explicitly name a sibling to prefer for deletion, but no sibling is named because no delete_type tool exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit a booking question (Pro). Omitted fields are left unchanged; the key never changes. isActive: false hides it from the form but keeps past answers (prefer this to delete_booking_question). Returns the updated question. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Question shown to carriers. | |
| options | No | Choices for DROPDOWN; replaces the whole list. | |
| helpText | No | Hint shown under the question. | |
| isActive | No | false = hidden from the form, answers kept. | |
| required | No | Must be answered to book. | |
| fieldType | No | Answer input type. MULTI_TEXT holds a list, such as several PO numbers. | |
| locationId | Yes | Location id, from list_locations. | |
| questionId | Yes | Booking question id, from list_booking_questions. | |
| isReference | No | Treat the answer as a searchable reference number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true) by disclosing partial-update semantics ("Omitted fields are left unchanged"), immutability of the identifier, the soft-disable behaviour versus deletion, the return value, and the auth scope required. That is exactly the extra context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the verb and resource, then the update contract, then the isActive-versus-delete guidance, then the return and auth requirements. No sentence is redundant.
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 nine-parameter mutation with no output schema, it covers the mutation contract, the destructive-alternative decision, the return shape ("Returns the updated question"), and the permission requirement. An agent has everything needed to decide and call correctly.
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 per-parameter meaning is already documented and the baseline is 3. The description adds genuine semantics beyond the schema by clarifying the PATCH contract for all nine parameters and stating questionId is immutable, which the schema does not say.
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 ("Edit a booking question") and flags the Pro tier constraint, which lets an agent separate it from create_booking_question and delete_booking_question in the sibling list. The added note that the key never changes pins down the exact scope of the edit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent away from a sibling: "prefer this to delete_booking_question" with the condition (isActive: false keeps past answers). It also names the prerequisite (scope locations:write, Admin role), so the agent knows before calling whether it is eligible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit a dock door. Omitted fields are left unchanged. appointmentTypeIds limits which types it takes ([] = every type). weeklyHours gives the door its own full week of hours, always clipped to the location's (days you leave out are closed for this door); pass null to go back to the location's hours. Type limits and door hours apply only when the location assigns doors. isActive: false takes it out of service (there is no delete). Returns the updated door. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New door name. | |
| doorId | Yes | Door id, from list_doors or get_location_setup. | |
| isActive | No | false = out of service; true = back in service. | |
| locationId | Yes | Location id, from list_locations. | |
| weeklyHours | No | The door's own full week, clipped to the location's. null = follow the location's hours. | |
| appointmentTypeIds | No | Ids of the types this door takes. [] = every type, including types added later. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotent and destructive, and the description earns credit by explaining why: partial-update semantics ("omitted fields are left unchanged"), the take-out-of-service path that stands in for deletion, the auth requirement ("scope locations:write (Admin role)"), and the return value. This is well beyond what the annotations convey.
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 dense paragraph with the core action front-loaded and zero filler sentences. It is information-rich rather than padded, though the parenthetical asides stacked mid-sentence make it slightly harder to scan than a short bulleted form would be.
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 output schema exists, and the description covers the return value ("Returns the updated door"), auth scope, partial-update behavior, and the semantics of every non-obvious parameter. Nothing an agent needs to call this mutation correctly is 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: the clipping rule for weeklyHours, that omitted days are closed for that door specifically, that null reverts to the location's hours, and that an empty appointmentTypeIds array includes future types. Only the name/maxLength constraint is left to 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?
Opens with a specific verb+resource pair ("Edit a dock door") and immediately enumerates the mutable facets (appointment type limits, weekly hours, isActive). An agent can separate this from list_doors, create_door, update_location_settings, and set_weekly_hours without opening any 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?
Strong conditional guidance: "Type limits and door hours apply only when the location assigns doors," and "isActive: false takes it out of service (there is no delete)" tells the agent to use this tool instead of a nonexistent delete path. No sibling tool is named as an explicit alternative, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit a location's name, address, timezone, or booking-page URL. Omitted fields are left unchanged. slug sets the public link /book/{slug}: 3+ lowercase letters, numbers, and hyphens; a slug another facility uses is a conflict. Changing it breaks links already sent to carriers. For scheduling rules use update_location_settings. Returns the location with its bookingPageUrl. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | Postal code. | |
| city | No | City. | |
| name | No | Facility name. | |
| slug | No | Booking-page path segment, e.g. acme-dallas. | |
| state | No | State or region, e.g. TX. | |
| address | No | Street address. | |
| country | No | Two-letter ISO country code, e.g. "US" or "AU". | |
| timezone | No | IANA timezone, e.g. "America/Chicago". | |
| locationId | Yes | Location id, from list_locations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as destructive and idempotent, but the description adds material context beyond them: omitted fields are unchanged, a duplicate slug is a conflict, changing the slug breaks already-sent carrier links, and the call requires locations:write (Admin). It even documents the return value ('the location with its bookingPageUrl').
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 dense and front-loaded: purpose first, then omission semantics, then slug rules and the destructive consequence, then the alternative tool, return value, and scope. Every sentence adds information; there is no filler.
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 mutation tool with annotations but no output schema, the description covers the missing pieces an agent needs: auth scope, idempotency behavior (omitted fields unchanged), destructive consequence of slug changes, conflict rule, return value, and a routing alternative. Nothing material is left out.
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 most parameter documentation is already carried by the schema; a baseline of 3 would apply. The description adds meaningful semantics for the trickiest field, 'slug' (format, uniqueness conflict, and link-breaking consequence), but does not elaborate the other eight fields beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Edit a location's...') and enumerates the editable fields. It also explicitly distinguishes itself from the sibling tool update_location_settings, so an agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-to-use guidance and an explicit alternative: 'For scheduling rules use update_location_settings.' It also states the omitted-fields behavior, slug constraints, conflict condition, and required scope, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change only a location's scheduling rules: start-time spacing (slotsPerHour), whether public bookings need approval, door mode (assignDoors vs doorCapacity), and dwell tracking. Omitted fields are left unchanged. For hours use set_weekly_hours; for name, address, or timezone use update_location_details; to change settings together with hours, types, and doors use set_up_location. Applies to future availability; existing appointments are kept and no one is notified. Returns the full location setup (same shape as get_location_setup). Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| locationId | Yes | Location id, from list_locations. | |
| assignDoors | No | true = each booking gets a specific door. false = only cap how many trucks overlap (doorCapacity). | |
| doorCapacity | No | Trucks allowed at once when assignDoors is false. | |
| slotsPerHour | No | How often start times are offered: 1 = on the hour, 2 = every 30 minutes, 4 = every 15 minutes. Start times count from each hours window's open time. | |
| dwellTrackingEnabled | No | Track dwell time: minutes from mark_arrived until the appointment is COMPLETED. | |
| appointmentApprovalRequired | No | When true, bookings from the public link wait for staff approval. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: 'Omitted fields are left unchanged', 'Applies to future availability; existing appointments are kept and no one is notified', required scope locations:write (Admin role), and the return shape. These disclose mutation semantics, blast radius, and auth requirements that the destructiveHint/idempotentHint flags alone cannot convey.
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?
Dense but every clause earns its place: scope first, then field-level semantics, then alternatives, then side effects, then return value, then auth. Front-loaded and waste-free despite covering a lot of ground.
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?
Though there is no output schema, the description states the return shape ('full location setup, same shape as get_location_setup'), covers side effects, reversibility of existing appointments, and permissions. Nothing an agent needs to invoke this mutation safely is 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 the schema already fully documents all six parameters including the slotsPerHour enum and door semantics. The description restates the field names parenthetically but adds no syntax or format detail beyond the schema, 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?
States a precise verb+resource ('Change only a location's scheduling rules') and enumerates the exact fields governed, immediately bounding scope. It explicitly names the sibling tools that own the fields it does NOT handle, so an agent can distinguish it from set_weekly_hours, update_location_details, and set_up_location without opening a 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?
Names three alternatives with the exact condition that selects each ('For hours use set_weekly_hours; for name, address, or timezone use update_location_details; to change settings together with hours... use set_up_location'). This is explicit when-to-use/when-not guidance with routing, exactly the top of the scale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change who hears about bookings at a location. notifyEmail is one extra address that gets booking alerts besides the team (empty string clears it). emailNotificationsEnabled turns carrier confirmation emails on or off; smsCheckInEnabled texts drivers a check-in link before their appointment. detailsReminderDays (1, 2, 3, 5, 7; 0 turns it off) is how many days before a recurring appointment the booker is emailed for load details still missing; detailsFinalReminder adds a last nudge 24 hours before. Omitted fields are left unchanged. Returns the location's notification settings. Requires scope locations:write (Admin role).
| Name | Required | Description | Default |
|---|---|---|---|
| locationId | Yes | Location id, from list_locations. | |
| notifyEmail | No | Extra alert address, e.g. dock@acme.com. "" clears it. | |
| smsCheckInEnabled | No | Text drivers a check-in link before arrival. | |
| detailsReminderDays | No | Days before a recurring appointment to ask the booker for missing load details. 0 = off. | |
| detailsFinalReminder | No | Also remind 24 hours before if details are still missing. | |
| emailNotificationsEnabled | No | Carrier confirmation and change emails on/off. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations: discloses partial-update semantics, the auth scope and role required, that it returns the location's settings, and the real-world side effects (texting drivers, emailing bookers, carrier confirmations). This is substantive context the destructiveHint/idempotentHint annotations cannot convey.
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?
Front-loaded with the purpose, then field semantics sentence-by-sentence. Dense and slightly run-on, but nearly every clause carries information an agent needs, so it earns its length.
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 6-parameter mutation tool with no output schema, the description covers what changes, partial-update behavior, permissions, and the return value. Nothing essential for correct invocation is 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 coverage is 100%, so baseline is 3, but the description adds genuine meaning: 0 turns detailsReminderDays off, the final reminder fires 24 hours before, and empty string clears notifyEmail. Adds value beyond the schema's per-field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Change who hears about bookings at a location', and enumerates the exact settings it governs. An agent can distinguish it from update_location_settings by the notification-specific field list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that omitted fields are left unchanged and that an empty string clears notifyEmail, plus the required scope (locations:write, Admin role). It doesn't name a sibling alternative for location-level vs notification-level settings, but the context is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm the owner's email with the six-digit code SimpleDock emailed them. Ask the user for the code they received; never guess one. After five wrong codes the email stops accepting codes (use resend_verification_email). Returns the updated account status. Requires scope locations:read (any member).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Six digits, e.g. 042917 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations by disclosing the lockout threshold, the required scope (locations:read, any member), and the fact that the call returns updated account status. The one gap is a mild tension with idempotentHint=true, since repeated wrong codes escalate state (attempt counter) rather than being a pure no-op; the description does not reconcile this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each load-bearing: purpose, sourcing rule, failure/fallback, return value, plus scope. The core action and the sourcing instruction are front-loaded, and nothing is redundant with the schema.
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 a fully documented schema and an output schema absent, the description covers the return value, the authorization scope, the failure mode, and the alternative tool. An agent has everything needed to select and invoke it correctly.
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 already documents the six-digit format with an example, so the schema carries the syntax burden. The description still adds value the schema cannot: the code must come from the user and must not be guessed, which is provenance guidance rather than format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (confirm/verify) and resource (the owner's email) and names the exact mechanism (six-digit code SimpleDock emailed). It also implicitly separates itself from resend_verification_email by referencing it as the fallback path, so an agent can distinguish the two 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to ask the user for the received code and never guess one, states the when-not condition (five wrong codes triggers lockout), and routes the agent to the named alternative resend_verification_email in that case. This is full when/when-not/alternative coverage.
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.
create_appointment_type2 fields changedInput schema / properties / loadType / descriptionPrevious value: -"FTL = full truckload, LTL = less than truckload."New value: +"FTL = full truckload, LTL = less than truckload, DROP_TRAILER = trailer left at the dock, OCEAN_CONTAINER = ocean/drayage container, INTERMODAL = rail container, FLATBED = open deck, PARCEL = small package."Input schema / properties / loadType / enumPrevious value: -[
- "FTL",
- "LTL"
-]New value: +[
+ "FTL",
+ "LTL",
+ "DROP_TRAILER",
+ "OCEAN_CONTAINER",
+ "INTERMODAL",
+ "FLATBED",
+ "PARCEL"
+]set_up_location2 fields changedInput schema / properties / appointmentTypes / items / properties / loadType / descriptionPrevious value: -"FTL = full truckload, LTL = less than truckload."New value: +"FTL = full truckload, LTL = less than truckload, DROP_TRAILER = trailer left at the dock, OCEAN_CONTAINER = ocean/drayage container, INTERMODAL = rail container, FLATBED = open deck, PARCEL = small package."Input schema / properties / appointmentTypes / items / properties / loadType / enumPrevious value: -[
- "FTL",
- "LTL"
-]New value: +[
+ "FTL",
+ "LTL",
+ "DROP_TRAILER",
+ "OCEAN_CONTAINER",
+ "INTERMODAL",
+ "FLATBED",
+ "PARCEL"
+]update_appointment_type2 fields changedInput schema / properties / loadType / descriptionPrevious value: -"FTL = full truckload, LTL = less than truckload."New value: +"FTL = full truckload, LTL = less than truckload, DROP_TRAILER = trailer left at the dock, OCEAN_CONTAINER = ocean/drayage container, INTERMODAL = rail container, FLATBED = open deck, PARCEL = small package."Input schema / properties / loadType / enumPrevious value: -[
- "FTL",
- "LTL"
-]New value: +[
+ "FTL",
+ "LTL",
+ "DROP_TRAILER",
+ "OCEAN_CONTAINER",
+ "INTERMODAL",
+ "FLATBED",
+ "PARCEL"
+]update_notification_settings2 fields changedInput schema / properties / detailsFinalReminderAdded value: +{
+ "description": "Also remind 24 hours before if details are still missing.",
+ "type": "boolean"
+}Input schema / properties / detailsReminderDaysAdded value: +{
+ "description": "Days before a recurring appointment to ask the booker for missing load details. 0 = off.",
+ "enum": [
+ 0,
+ 1,
+ 2,
+ 3,
+ 5,
+ 7
+ ],
+ "type": "integer"
+}create_appointment3 fields changedInput schema / properties / companyName / maxLengthAdded value: +200Input schema / properties / contactName / maxLengthAdded value: +120Input schema / properties / contactPhone / maxLengthAdded value: +40create_appointment_type1 field changedInput schema / properties / name / maxLengthAdded value: +120set_up_location1 field changedInput schema / properties / appointmentTypes / items / properties / name / maxLengthAdded value: +120update_appointment_details3 fields changedInput schema / properties / companyName / maxLengthAdded value: +200Input schema / properties / contactName / maxLengthAdded value: +120Input schema / properties / contactPhone / maxLengthAdded value: +40update_appointment_type1 field changedInput schema / properties / name / maxLengthAdded value: +120create_appointment1 field changedInput schema / properties / customFields / descriptionPrevious value: -"Answers to the type's booking questions, keyed by fieldDefinitions[].key, e.g. { \"sealNumber\": \"A123\" }."New value: +"Answers to the type's booking questions, keyed by fieldDefinitions[].key, e.g. { \"sealNumber\": \"A123\" }. A MULTI_TEXT question takes an array of strings, e.g. { \"customerPo\": [\"4501\", \"4502\"] }."create_booking_question2 fields changedInput schema / properties / fieldType / descriptionPrevious value: -"Answer input type."New value: +"Answer input type. MULTI_TEXT holds a list, such as several PO numbers."Input schema / properties / fieldType / enumPrevious value: -[
- "SHORT_TEXT",
- "LONG_TEXT",
- "NUMBER",
- "DROPDOWN",
- "BOOLEAN",
- "DATE"
-]New value: +[
+ "SHORT_TEXT",
+ "LONG_TEXT",
+ "NUMBER",
+ "DROPDOWN",
+ "BOOLEAN",
+ "DATE",
+ "MULTI_TEXT"
+]create_location1 field changedInput schema / properties / countryAdded value: +{
+ "description": "Two-letter ISO country code, e.g. \"US\" or \"AU\".",
+ "type": "string"
+}update_booking_question2 fields changedInput schema / properties / fieldType / descriptionPrevious value: -"Answer input type."New value: +"Answer input type. MULTI_TEXT holds a list, such as several PO numbers."Input schema / properties / fieldType / enumPrevious value: -[
- "SHORT_TEXT",
- "LONG_TEXT",
- "NUMBER",
- "DROPDOWN",
- "BOOLEAN",
- "DATE"
-]New value: +[
+ "SHORT_TEXT",
+ "LONG_TEXT",
+ "NUMBER",
+ "DROPDOWN",
+ "BOOLEAN",
+ "DATE",
+ "MULTI_TEXT"
+]update_location_details1 field changedInput schema / properties / countryAdded value: +{
+ "description": "Two-letter ISO country code, e.g. \"US\" or \"AU\".",
+ "type": "string"
+}create_appointment2 fields changedInput schema / properties / poNumbersAdded value: +{
+ "description": "Every purchase order on this appointment, in order. Duplicates ignoring case are dropped. When set, this wins over poReference.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / poReference / descriptionPrevious value: -"Purchase order or load reference number."New value: +"One purchase order. Kept for older clients. Prefer poNumbers when the load has more than one. If both are sent, poNumbers wins. Sending only this replaces the list with this single value."update_appointment_details2 fields changedInput schema / properties / poNumbersAdded value: +{
+ "description": "Replaces every PO on the appointment. Send [] to clear them. Omit to leave the list alone. Wins over poReference when both are sent.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / poReference / descriptionPrevious value: -"Purchase order or load reference number."New value: +"One purchase order. Kept for older clients. Prefer poNumbers when the load has more than one. If both are sent, poNumbers wins. Sending only this replaces the list with this single value."create_appointment1 field changedInput schema / properties / contactNameAdded value: +{
+ "description": "Carrier contact person's name.",
+ "type": "string"
+}update_appointment_details1 field changedInput schema / properties / contactNameAdded value: +{
+ "description": "Carrier contact person's name.",
+ "type": "string"
+}add_closed_dates4 fields changedInput schema / properties / dates / descriptionAdded value: +"Whole days to close."Input schema / properties / dates / items / descriptionPrevious value: -"YYYY-MM-DD"New value: +"YYYY-MM-DD in the location's timezone, e.g. 2026-12-25."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."Input schema / properties / reason / descriptionAdded value: +"Shown to staff, e.g. \"Christmas\"."approve_appointment2 fields changedInput schema / properties / appointmentId / descriptionAdded value: +"Appointment id, from list_appointments, get_appointment, or create_appointment."Input schema / properties / startTime / descriptionPrevious value: -"ISO 8601 datetime (optional)"New value: +"Optional new start time, ISO 8601 datetime with offset, e.g. 2026-10-15T08:00:00-05:00. Omit to keep the requested time."cancel_appointment1 field changedInput schema / properties / appointmentId / descriptionAdded value: +"Appointment id, from list_appointments, get_appointment, or create_appointment."check_in_appointment3 fields changedInput schema / properties / appointmentId / descriptionAdded value: +"Appointment id, from list_appointments, get_appointment, or create_appointment."Input schema / properties / estimatedDelay / descriptionPrevious value: -"Minutes late (for RUNNING_LATE)"New value: +"Minutes late, e.g. 30. Use with RUNNING_LATE."Input schema / properties / status / descriptionAdded value: +"ON_TRACK = expected on time; RUNNING_LATE = needs estimatedDelay."create_api_key1 field changedInput schema / properties / scopes / descriptionAdded value: +"Scopes to grant, no wider than your own. Omit to copy your current scopes."create_appointment14 fields changedInput schema / properties / appointmentTypeId / descriptionAdded value: +"Appointment type id, from list_appointment_types (get_location_setup also lists inactive types)."Input schema / properties / companyName / descriptionAdded value: +"Carrier company name."Input schema / properties / contactEmail / descriptionAdded value: +"Carrier contact email; confirmations and changes are emailed here."Input schema / properties / contactPhone / descriptionAdded value: +"Carrier contact phone, e.g. +1 214 555 0100."Input schema / properties / customFields / descriptionAdded value: +"Answers to the type's booking questions, keyed by fieldDefinitions[].key, e.g. { \"sealNumber\": \"A123\" }."Input schema / properties / doorId / descriptionAdded value: +"Specific door to use. Only honored when the location assigns doors; omit to auto-pick."Input schema / properties / driverName / descriptionAdded value: +"Driver's name."Input schema / properties / driverNotes / descriptionAdded value: +"Instructions for the driver."Input schema / properties / driverPhone / descriptionAdded value: +"Driver's mobile; check-in texts go here when SMS check-in is on."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."Input schema / properties / notes / descriptionAdded value: +"Notes from the carrier or scheduler, visible to staff."Input schema / properties / poReference / descriptionAdded value: +"Purchase order or load reference number."Input schema / properties / startTime / descriptionPrevious value: -"ISO 8601 datetime"New value: +"A startTime returned by get_availability, unchanged."Input schema / properties / trailerNumber / descriptionAdded value: +"Trailer number."create_appointment_type8 fields changedInput schema / properties / bufferAfterMinutes / descriptionPrevious value: -"Door kept free after each appointment of this type."New value: +"Minutes the door is kept free after each appointment of this type."Input schema / properties / bufferBeforeMinutes / descriptionPrevious value: -"Door kept free before each appointment of this type."New value: +"Minutes the door is kept free before each appointment of this type."Input schema / properties / direction / descriptionAdded value: +"INBOUND = receiving, OUTBOUND = shipping."Input schema / properties / durationMinutes / descriptionAdded value: +"How long the door is held for one appointment, in minutes."Input schema / properties / loadType / descriptionAdded value: +"FTL = full truckload, LTL = less than truckload."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."Input schema / properties / minimumNoticeMinutes / descriptionPrevious value: -"How far ahead a booking must be made."New value: +"How far ahead a booking must be made, in minutes (1440 = one day)."Input schema / properties / name / descriptionAdded value: +"What carriers pick when booking, e.g. \"Inbound FTL\"."create_booking_question8 fields changedInput schema / properties / appointmentTypeId / descriptionAdded value: +"Appointment type id, from list_appointment_types (get_location_setup also lists inactive types)."Input schema / properties / fieldType / descriptionAdded value: +"Answer input type."Input schema / properties / helpText / descriptionAdded value: +"Hint shown under the question."Input schema / properties / isReference / descriptionAdded value: +"Treat the answer as a searchable reference number."Input schema / properties / label / descriptionAdded value: +"Question shown to carriers, e.g. \"Seal number\"."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."Input schema / properties / options / descriptionAdded value: +"Choices; required for DROPDOWN, ignored otherwise."Input schema / properties / required / descriptionAdded value: +"Must be answered to book. Default false."create_door3 fields changedInput schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."Input schema / properties / name / descriptionAdded value: +"Door name, e.g. \"Door 4\"."Input schema / properties / weeklyHours / descriptionAdded value: +"The door's own full week, clipped to the location's. Omit to follow the location's hours."create_location6 fields changedInput schema / properties / address / descriptionAdded value: +"Street address."Input schema / properties / city / descriptionAdded value: +"City."Input schema / properties / name / descriptionAdded value: +"Facility name, e.g. \"Acme Dallas DC\"."Input schema / properties / state / descriptionAdded value: +"State or region, e.g. TX."Input schema / properties / timezone / descriptionPrevious value: -"IANA timezone, e.g. \"America/Chicago\"."New value: +"IANA timezone, e.g. \"America/Chicago\". All hours and dates use it."Input schema / properties / zip / descriptionAdded value: +"Postal code."create_webhook4 fields changedInput schema / properties / eventTypes / descriptionAdded value: +"Events to send, e.g. appointment.created. Empty or omitted = every event."Input schema / properties / label / descriptionAdded value: +"Name shown in Settings, e.g. \"Yard system\"."Input schema / properties / locationIds / descriptionAdded value: +"Location ids from list_locations. Empty or omitted = every location."Input schema / properties / url / descriptionAdded value: +"https:// endpoint that receives POSTed JSON events."delete_booking_question2 fields changedInput schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."Input schema / properties / questionId / descriptionAdded value: +"Booking question id, from list_booking_questions."get_analytics3 fields changedInput schema / properties / from / descriptionPrevious value: -"ISO 8601 datetime"New value: +"Range start. ISO 8601 datetime with offset, e.g. 2026-10-15T08:00:00-05:00. Default: 30 days before to."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."Input schema / properties / to / descriptionPrevious value: -"ISO 8601 datetime"New value: +"Range end. ISO 8601 datetime with offset, e.g. 2026-10-15T08:00:00-05:00. Default: now."get_appointment1 field changedInput schema / properties / appointmentId / descriptionAdded value: +"Appointment id, from list_appointments, get_appointment, or create_appointment."get_availability3 fields changedInput schema / properties / appointmentTypeId / descriptionAdded value: +"Appointment type id, from list_appointment_types (get_location_setup also lists inactive types)."Input schema / properties / date / descriptionPrevious value: -"YYYY-MM-DD"New value: +"YYYY-MM-DD in the location's timezone, e.g. 2026-10-15."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."get_booking_page1 field changedInput schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."get_location_setup1 field changedInput schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."invite_member2 fields changedInput schema / properties / email / descriptionAdded value: +"Invitee's email address."Input schema / properties / role / descriptionAdded value: +"Access level once they accept; see the description for what each role can do."list_appointment_types1 field changedInput schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."list_appointments6 fields changedInput schema / properties / cursor / descriptionPrevious value: -"nextCursor from a previous page"New value: +"nextCursor from the previous page."Input schema / properties / from / descriptionPrevious value: -"ISO 8601 datetime"New value: +"Earliest start time, inclusive. ISO 8601 datetime with offset, e.g. 2026-10-15T08:00:00-05:00."Input schema / properties / limit / descriptionAdded value: +"Page size, 1–100. Default 50."Input schema / properties / locationId / descriptionAdded value: +"Only this location. Omit for every location."Input schema / properties / status / descriptionAdded value: +"Only this status. PENDING = awaiting approval. Omit for all."Input schema / properties / to / descriptionPrevious value: -"ISO 8601 datetime"New value: +"Latest start time, inclusive. ISO 8601 datetime with offset, e.g. 2026-10-15T08:00:00-05:00."list_booking_questions2 fields changedInput schema / properties / appointmentTypeId / descriptionAdded value: +"Only this type. Omit for every type."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."list_doors1 field changedInput schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."mark_arrived1 field changedInput schema / properties / appointmentId / descriptionAdded value: +"Appointment id, from list_appointments, get_appointment, or create_appointment."reject_appointment2 fields changedInput schema / properties / appointmentId / descriptionAdded value: +"Appointment id, from list_appointments, get_appointment, or create_appointment."Input schema / properties / reason / descriptionAdded value: +"Optional reason, stored as rejectionReason, e.g. \"No doors free that morning\"."remove_closure2 fields changedInput schema / properties / closureId / descriptionAdded value: +"id from get_location_setup's upcomingClosures."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."reschedule_appointment3 fields changedInput schema / properties / appointmentId / descriptionAdded value: +"Appointment id, from list_appointments, get_appointment, or create_appointment."Input schema / properties / doorId / descriptionAdded value: +"Move to this door too. Omit to keep or auto-pick a door."Input schema / properties / startTime / descriptionPrevious value: -"ISO 8601 datetime"New value: +"New start: a startTime returned by get_availability, unchanged."set_appointment_status2 fields changedInput schema / properties / appointmentId / descriptionAdded value: +"Appointment id, from list_appointments, get_appointment, or create_appointment."Input schema / properties / status / descriptionAdded value: +"COMPLETED or NO_SHOW for dock outcomes; CONFIRMED to confirm without emailing."set_up_location13 fields changedInput schema / properties / appointmentTypes / descriptionAdded value: +"Types to create, or to update when the name already exists at the location."Input schema / properties / appointmentTypes / items / properties / bufferAfterMinutes / descriptionPrevious value: -"Door kept free after each appointment of this type."New value: +"Minutes the door is kept free after each appointment of this type."Input schema / properties / appointmentTypes / items / properties / bufferBeforeMinutes / descriptionPrevious value: -"Door kept free before each appointment of this type."New value: +"Minutes the door is kept free before each appointment of this type."Input schema / properties / appointmentTypes / items / properties / direction / descriptionAdded value: +"INBOUND = receiving, OUTBOUND = shipping."Input schema / properties / appointmentTypes / items / properties / durationMinutes / descriptionAdded value: +"How long the door is held for one appointment, in minutes."Input schema / properties / appointmentTypes / items / properties / loadType / descriptionAdded value: +"FTL = full truckload, LTL = less than truckload."Input schema / properties / appointmentTypes / items / properties / minimumNoticeMinutes / descriptionPrevious value: -"How far ahead a booking must be made."New value: +"How far ahead a booking must be made, in minutes (1440 = one day)."Input schema / properties / appointmentTypes / items / properties / name / descriptionAdded value: +"What carriers pick when booking, e.g. \"Inbound FTL\"."Input schema / properties / doors / descriptionAdded value: +"Doors to create, or to update when the name already exists at the location."Input schema / properties / doors / items / properties / name / descriptionAdded value: +"Door name, e.g. \"Door 1\". Matches existing doors."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."Input schema / properties / settings / descriptionAdded value: +"Same fields as update_location_settings. Omitted fields are unchanged."Input schema / properties / settings / properties / dwellTrackingEnabled / descriptionPrevious value: -"Adds \"Mark arrived\" and dwell time."New value: +"Track dwell time: minutes from mark_arrived until the appointment is COMPLETED."set_weekly_hours2 fields changedInput schema / properties / days / descriptionAdded value: +"One entry per day to replace; at least one."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."update_appointment_details10 fields changedInput schema / properties / appointmentId / descriptionAdded value: +"Appointment id, from list_appointments, get_appointment, or create_appointment."Input schema / properties / companyName / descriptionAdded value: +"Carrier company name."Input schema / properties / contactEmail / descriptionAdded value: +"Carrier contact email; confirmations and changes are emailed here."Input schema / properties / contactPhone / descriptionAdded value: +"Carrier contact phone, e.g. +1 214 555 0100."Input schema / properties / driverName / descriptionAdded value: +"Driver's name."Input schema / properties / driverNotes / descriptionAdded value: +"Instructions for the driver."Input schema / properties / driverPhone / descriptionAdded value: +"Driver's mobile; check-in texts go here when SMS check-in is on."Input schema / properties / notes / descriptionAdded value: +"Notes from the carrier or scheduler, visible to staff."Input schema / properties / poReference / descriptionAdded value: +"Purchase order or load reference number."Input schema / properties / trailerNumber / descriptionAdded value: +"Trailer number."update_appointment_type10 fields changedInput schema / properties / appointmentTypeId / descriptionAdded value: +"Appointment type id, from list_appointment_types (get_location_setup also lists inactive types)."Input schema / properties / bufferAfterMinutes / descriptionPrevious value: -"Door kept free after each appointment of this type."New value: +"Minutes the door is kept free after each appointment of this type."Input schema / properties / bufferBeforeMinutes / descriptionPrevious value: -"Door kept free before each appointment of this type."New value: +"Minutes the door is kept free before each appointment of this type."Input schema / properties / direction / descriptionAdded value: +"INBOUND = receiving, OUTBOUND = shipping."Input schema / properties / durationMinutes / descriptionAdded value: +"How long the door is held for one appointment, in minutes."Input schema / properties / isActive / descriptionAdded value: +"false = no longer bookable; true = offer it again."Input schema / properties / loadType / descriptionAdded value: +"FTL = full truckload, LTL = less than truckload."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."Input schema / properties / minimumNoticeMinutes / descriptionPrevious value: -"How far ahead a booking must be made."New value: +"How far ahead a booking must be made, in minutes (1440 = one day)."Input schema / properties / name / descriptionAdded value: +"What carriers pick when booking, e.g. \"Inbound FTL\"."update_booking_question9 fields changedInput schema / properties / fieldType / descriptionAdded value: +"Answer input type."Input schema / properties / helpText / descriptionAdded value: +"Hint shown under the question."Input schema / properties / isActive / descriptionAdded value: +"false = hidden from the form, answers kept."Input schema / properties / isReference / descriptionAdded value: +"Treat the answer as a searchable reference number."Input schema / properties / label / descriptionAdded value: +"Question shown to carriers."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."Input schema / properties / options / descriptionAdded value: +"Choices for DROPDOWN; replaces the whole list."Input schema / properties / questionId / descriptionAdded value: +"Booking question id, from list_booking_questions."Input schema / properties / required / descriptionAdded value: +"Must be answered to book."update_door5 fields changedInput schema / properties / doorId / descriptionAdded value: +"Door id, from list_doors or get_location_setup."Input schema / properties / isActive / descriptionAdded value: +"false = out of service; true = back in service."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."Input schema / properties / name / descriptionAdded value: +"New door name."Input schema / properties / weeklyHours / descriptionAdded value: +"The door's own full week, clipped to the location's. null = follow the location's hours."update_location_details7 fields changedInput schema / properties / address / descriptionAdded value: +"Street address."Input schema / properties / city / descriptionAdded value: +"City."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."Input schema / properties / name / descriptionAdded value: +"Facility name."Input schema / properties / slug / descriptionPrevious value: -"e.g. acme-dallas"New value: +"Booking-page path segment, e.g. acme-dallas."Input schema / properties / state / descriptionAdded value: +"State or region, e.g. TX."Input schema / properties / zip / descriptionAdded value: +"Postal code."update_location_settings2 fields changedInput schema / properties / dwellTrackingEnabled / descriptionPrevious value: -"Adds \"Mark arrived\" and dwell time."New value: +"Track dwell time: minutes from mark_arrived until the appointment is COMPLETED."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."update_notification_settings4 fields changedInput schema / properties / emailNotificationsEnabled / descriptionAdded value: +"Carrier confirmation and change emails on/off."Input schema / properties / locationId / descriptionAdded value: +"Location id, from list_locations."Input schema / properties / notifyEmail / descriptionAdded value: +"Extra alert address, e.g. dock@acme.com. \"\" clears it."Input schema / properties / smsCheckInEnabled / descriptionAdded value: +"Text drivers a check-in link before arrival."add_closed_datesapprove_appointmentcancel_appointmentcheck_in_appointmentcreate_api_keycreate_appointmentcreate_appointment_typecreate_booking_questioncreate_doorcreate_locationcreate_webhookdelete_booking_questionget_account_statusget_analyticsget_appointmentget_availabilityget_booking_pageget_location_setupinvite_memberlist_appointment_typeslist_appointmentslist_booking_questionslist_doorslist_locationsmark_arrivedreject_appointmentremove_closurereschedule_appointmentresend_verification_emailset_appointment_statusset_up_locationset_weekly_hoursupdate_appointment_detailsupdate_appointment_typeupdate_booking_questionupdate_doorupdate_location_detailsupdate_location_settingsupdate_notification_settingsverify_emailSupply chain operations: dock scheduling, check-in, doors, inventory, orders and freight.
Appointment scheduling: check availability, book, reschedule and cancel meetings, manage events.
Freight: brokers post loads and pick carrier offers; carriers post trucks, find loads and bid.
Plan optimal container & truck loads: 3D layouts, utilization, centre of gravity, crush checks.
Add one secure layer between your agents and this server.
