get_my_service_bookingOpen an appointment that belongs to the connected customer. This is read-only. Historical appointments have no available management actions; a current manageable appointment can provide the protected card for exact reschedule or cancellation review.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | view | |
| booking_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
Output schema / properties / result / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "booking": {
- "additionalProperties": false,
- "properties": {
- "arrival_window": {
- "type": "string"
- },
- "available_actions": {
- "items": {
- "enum": [
- "reschedule",
- "cancel"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "booking_id": {
- "type": "string"
- },
- "provider_public_name": {
- "type": "string"
- },
- "public_booking_ref": {
- "type": "string"
- },
- "service_date": {
- "type": "string"
- },
- "status": {
- "type": "string"
- },
- "timezone": {
- "type": "string"
- }
- },
- "required": [
- "booking_id",
- "provider_public_name",
- "service_date",
- "arrival_window",
- "timezone",
- "status",
- "public_booking_ref",
- "available_actions"
- ],
- "type": "object"
- },
- "next_action": {
- "enum": [
- "view_complete",
- "choose_available_time",
- "review_cancellation"
- ],
- "type": "string"
- }
- },
- "required": [
- "booking",
- "next_action"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "error": {
- "additionalProperties": false,
- "properties": {
- "category": {
- "type": "string"
- },
- "code": {
- "type": "string"
- },
- "correlation_id": {
- "type": "string"
- },
- "details": {
- "additionalProperties": {},
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "message": {
- "type": "string"
- },
- "retryable": {
- "type": "boolean"
- }
- },
- "required": [
- "code",
- "category",
- "message",
- "retryable",
- "correlation_id",
- "details"
- ],
- "type": "object"
- }
- },
- "required": [
- "error"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "booking": {
+ "additionalProperties": false,
+ "properties": {
+ "arrival_window": {
+ "type": "string"
+ },
+ "available_actions": {
+ "items": {
+ "enum": [
+ "reschedule",
+ "cancel"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "booking_id": {
+ "type": "string"
+ },
+ "is_active": {
+ "type": "boolean"
+ },
+ "is_manageable": {
+ "type": "boolean"
+ },
+ "is_past": {
+ "type": "boolean"
+ },
+ "provider_public_name": {
+ "type": "string"
+ },
+ "public_booking_ref": {
+ "type": "string"
+ },
+ "service_date": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "timezone": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "booking_id",
+ "provider_public_name",
+ "service_date",
+ "arrival_window",
+ "timezone",
+ "status",
+ "public_booking_ref",
+ "is_active",
+ "is_manageable",
+ "is_past",
+ "available_actions"
+ ],
+ "type": "object"
+ },
+ "next_action": {
+ "enum": [
+ "view_complete",
+ "choose_available_time",
+ "review_cancellation"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "booking",
+ "next_action"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "code": {
+ "type": "string"
+ },
+ "correlation_id": {
+ "type": "string"
+ },
+ "details": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "retryable": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "code",
+ "category",
+ "message",
+ "retryable",
+ "correlation_id",
+ "details"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful context beyond those annotations: the appointment must belong to the connected customer, and behavior differs between historical and current manageable appointments. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the core purpose and read-only nature front-loaded. The second sentence adds important state-dependent behavior without fluff or 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?
For a simple read-only tool with an output schema and strong annotations, the description sufficiently covers purpose, ownership, and state-dependent behavior. The main omissions are explicit parameter semantics and explicit sibling routing, but those are partially recoverable from the schema and tool names.
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 0%, so the description must compensate for parameter meaning, but it does not mention booking_id or intent explicitly. The reschedule/cancellation wording hints at the intent enum, but an agent gets no direct guidance on what booking_id identifies or how intent changes the returned card. This is a meaningful gap.
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 concrete operation ('Open') and a clear resource ('an appointment that belongs to the connected customer'), and explicitly labels the tool as read-only. It also differentiates it from mutation-focused siblings by noting that historical appointments have no management actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use this tool: to open a connected customer's appointment, and for currently manageable appointments, to obtain the protected card for reschedule or cancellation review. It does not explicitly name sibling tools or state when to prefer cancel_service_booking or reschedule_service_booking directly, so a fully explicit exclusion is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.