An MCP server can sit inside the company, where employees search records, summarize tickets, or draft updates from internal systems. A customer-facing server points outward, at the customer who wants their own AI assistant to book an appointment, check an order, or start a reorder with the business.
A customer-facing MCP server is the piece the business operates for that. MCP, the Model Context Protocol, lets an AI client discover tools from a server and call them. For customers, the server runs as a hosted HTTP service behind customer sign-in, and it only helps customers whose assistant supports connecting to remote MCP servers. It differs from WebMCP, where an agent works with a website inside the user's browser; here the assistant calls the business's server directly.
A Booking, Followed Through
Take an illustrative appointment business with a real booking system behind its website. A returning customer asks their assistant for a massage appointment on a weekday evening. The server exposes business actions, not the scheduling database: find_available_appointments, hold_appointment_slot, and book_appointment. Each one applies the rules the booking system already enforces, including provider availability, service duration, deposit requirements, and cancellation windows.
Availability is not a reservation. Between the search and the booking, another customer can take the slot. A hold can expire while the customer is deciding, and a deposit charge can fail after the hold is placed. The server should return the state it actually reached, such as held until a stated time, booked, or payment failed with the hold released, so the assistant does not tell the customer something the booking system never recorded.
The hold itself needs care. The MCP tools specification has no protocol-level session, and its guidance on stateful tools says that for authenticated servers a handle such as a hold ID "is a name, not a capability": the server should validate the caller's authorization against the handle on every call, and state its retention in the creation tool's description. Here, book_appointment accepts a hold ID only from the customer account that created it, and the tool description says how long a hold lasts.
A reorder follows the same shape with different records: order history in place of availability, a draft order in place of a hold, and the order system deciding what is in stock.
What the Server Enforces on Each Call
Customer sign-in at the hosting boundary establishes who is calling. It does not decide whether that customer may book this provider, see this order, or charge this card. The same specification allows the tool list itself to vary by the authorization on the request, so a server can hide tools a caller's granted scopes do not permit. It also requires servers to validate all tool inputs, implement access controls, and rate limit tool invocations. Filtering discovery does not replace any of that: the permission check still runs when the tool is called.
Confirmation needs the same precision. The specification says clients should prompt the user before sensitive operations, and that is client behavior the server cannot observe. A live hold created by the same account for the exact time, service, and price shows that the booking still matches what was proposed; it does not show that the customer approved it. That takes a separate approved state on the hold, recorded by the business when approval arrives through a path it trusts, such as a confirmation step in the customer's signed-in session, and bound to the hold ID, the account, the material details and the hold's expiry. A confirmed: true argument, or an assistant's statement that it showed the customer the details, is a claim made by the client, not a recorded approval. book_appointment commits only when the hold is live, approved and unchanged, after checking the customer's authorization again; anything else is rejected and the assistant has to start again.
The 2026-07-28 specification adds multi-round-trip requests: a tool call can return input_required, and the client retries with the requested inputResponses and an opaque requestState. Where that state influences authorization, resource access or business logic, the server must protect its integrity and reject state that fails verification. The specification recommends binding it to the authenticated principal, a short expiry and the originating request, and requires server-side enforcement where a state must be consumed only once. Those are protocol requirements for state the server issued. An answer collected this way still arrives through the client, so whether it counts as the customer's approval of one exact booking is an application design decision, and the approved state still belongs in the booking system.
Retries can create duplicates, and an approved state does nothing to prevent them. An idempotency key on book_appointment helps only if the server stores the key with the outcome and returns that stored outcome on a repeat. If the payment call timed out and the server does not know whether the charge succeeded, the honest state is unknown. That booking goes to a support queue for reconciliation, and the server does not attempt a second charge on its own.
Check hosting features separately from the SDK version: the official C# SDK has stable releases, while Azure App Service's built-in MCP protected resource metadata support is documented as preview.
What Support Sees After a Failed Booking
When a customer says the assistant booked the wrong time, support needs a record per tool call: the customer account, the calling client, the tool, the validated arguments, the hold or order ID, the state returned, and the downstream result from the booking or payment system. Keep that record access-controlled and on a stated retention period, and leave out payment details and free-text the task does not need.
The same records, counted in aggregate, show which requests the server could not complete. Repeated requests for evening slots that do not exist, or for a reorder the catalog cannot express, are service questions the business can act on without keeping more personal data than the booking already requires.
Scope of a First Build
One customer action is enough for a first version: availability search plus booking against an approved hold, or order status plus a reorder draft. One acceptance test for the booking path uses a timed-out payment call: the booking is left in an unknown state, placed in the reconciliation queue with the hold ID, account and payment reference, and no second charge is attempted until support has checked the payment system. The authorization, hold, approval and idempotency checks above need tests of their own before customers use the booking path.