Why company-specific MCP endpoints matter for booking

A generic assistant can read a website. Booking an appointment is different. It needs scoped authority, current business rules, idempotent writes, and a confirmation gate before anything changes.

Updated July 2026 · BookBridge private beta

Company-specific hosted MCP is tenant-bound

A company-specific hosted MCP configuration gives one approved business its own HTTPS endpoint, such as /mcp/your-business. It exposes only the tools that company can safely support: profile reads, service lookup, availability, booking requests, reschedules, cancellations, consent, and booking status. Those tools are scoped to the tenant and the token, not handed out as one broad integration secret.

Platform/local MCP examples are different

BookBridge can also demonstrate broader platform tools such as find_local_business, book_local_appointment, and check_fulfillment. Those examples resolve a business across the directory before routing through the API. They are useful for agent demos and local/platform clients, but they are not the default tool list for every company-specific hosted endpoint.

Confirmation gates are the difference between helpful and risky

AI-initiated booking actions should not silently create or change appointments. BookBridge returns a confirmation-required step before write actions proceed, so the customer remains in control.

Audit trails make agent actions reviewable

When a booking assistant acts, operators need to know what happened: which token was used, which organization was touched, which booking attempt was created, whether a webhook was accepted, and whether a human operator had to step in.

Company-specific configuration improves discovery

For search engines and generative engines, a clear company endpoint creates a stable answer to “how do I book this business through an assistant?” For operators, it creates a stable place to rotate credentials, review usage, and disable access.