Client features, multi round-trip requests and extensions

0:00 Client features and extensions

Sometimes a tool can't finish without the human. It needs a missing detail, a confirmation, a payment or a sign in. MCP has features for exactly this, and they changed a lot in twenty twenty six. In this lesson you'll learn elicitation, the new multi round trip requests, what's been deprecated, and the extensions that add tasks and interactive apps.

0:26 Why it matters

Why does this matter? Because the best tools don't fail when information is missing; they ask. Imagine ordering at a café. If the barista just guesses your milk preference, you get the wrong drink. If they ask, oat or regular, it takes three seconds and everyone's happy. But if they ask for your bank PIN at the counter, something is very wrong. Elicitation is the polite question, URL mode is paying on the card machine instead of saying your PIN out loud, and the new round trip design makes asking work at scale.

1:06 Elicitation

Elicitation lets a server ask the user for input through the host. In form mode, the server sends a message and a simple schema, the host shows a form, and the user can accept with data, decline or cancel. In URL mode, added in late twenty twenty five, the server sends a link for something that must not pass through the client at all, like an OAuth consent screen, a payment page, or entering an API key on the provider's own site. That keeps secrets out of the model's context and the host's logs.

1:47 Elicitation rules

Two firm rules. Never use form elicitation to collect passwords, API keys or card numbers. Use URL mode for anything sensitive. And hosts must make it clear which server is asking, and let users refuse. If a server can't say which company it belongs to, or pushes users to hurry, treat that as a red flag.

2:11 Multi Round-Trip Requests

Now the big change. In older versions, elicitation worked by the server sending a request back to the client over a stream held open for the purpose. That fights against stateless, load balanced servers. The twenty twenty six spec introduces multi round trip requests. Instead of calling the client, the server returns an interim result that says input required, listing what it needs, plus an opaque state token. The client gathers the answers and retries the original request with them attached. Every round trip is an ordinary request, so any server instance can handle it.

2:52 Simple example: create_invoice

A simple example of multi round trip requests. A tool called create invoice gets a client name but no currency. Old style: the server sends a request back to the client over an open stream and waits. New style: the server immediately returns a result that says input required, with one question, which currency, and a small state token. The host shows a dropdown, the user picks dirhams, and the client simply calls create invoice again with the answer attached. The second call might land on a different server instance, and that's fine.

3:32 Deprecated in 2026-07-28

The good news: SDKs hide most of this. In the Python SDK version two, you still write await context elicit inside your tool, and the SDK handles the protocol differences. Meanwhile, three older features are deprecated. Sampling, where servers borrowed the client's model: instead, call an LLM provider directly. Roots, where clients told servers which folders were in scope: instead, pass paths as tool parameters or configuration. And MCP logging: instead, log to standard error or use OpenTelemetry. They still work for at least twelve months, but don't build new things on them.

4:12 Utilities and extensions

There are handy utilities too. Progress notifications for long operations, cancellation of in flight requests, completions for autocompleting arguments, and cursor based pagination for long lists. And then there are extensions, which are optional capabilities both sides must declare. Tasks handle long running work: the tool returns a handle, and the client polls for status and results. MCP Apps let servers show interactive interfaces like charts, forms and dashboards inside the conversation, in a sandbox. And authorization extensions cover machine to machine access and enterprise controlled sign in.

4:50 Example: Riyadh venue booking

A worked example. An events company in Riyadh exposes a book venue tool. If the date is taken, form elicitation asks whether to try another date, with a sensible default. If a deposit is needed, URL elicitation opens the payment provider's hosted page, so the card never touches the model. Contract generation takes minutes, so the tool returns a task handle and the host shows progress. And a review summary feature that used sampling now calls an LLM API directly, with its own key and cost controls.

5:28 Hands-on: form elicitation

The hands on code shows form elicitation in Python. If the requested date is booked, the tool asks whether to try another date, with a date field and a default. If the user accepts, it retries the booking. Test it in the Inspector, and remember: not every host supports elicitation, or MCP Apps, so design a fallback, like returning a clear message asking the user to pick another date.

5:58 Deeper: the Riyadh booking flow (illustrative)

Let's deepen the Riyadh events company example. On a busy December weekend, illustrative again, many booking requests hit fully booked dates. With form elicitation, the assistant offered an alternative date inline, and a good share of those customers accepted instead of abandoning. Deposits moved to URL mode, so card details went straight to the payment provider, which also satisfied the company's payment security requirements. Contract generation became a task, so the chat stayed responsive while documents rendered. And removing sampling meant the server's own LLM calls were logged and budgeted like any other API usage, which the finance team appreciated.

6:41 Watch me do it: book_venue()

Watch me do it. Let's walk through the book venue tool. The alternative date model has two fields: accept alternative, a yes or no question, and a date with a sensible default. The tool takes a date, a number of guests and the context. If the date isn't booked, it returns a provisional booking straight away. If it is booked, it calls context elicit with a friendly message and the schema. The host renders a small form. The result has an action: accept, decline or cancel. If the user accepted and wants an alternative, the tool calls itself again with the new date. Otherwise it returns, no booking made. In the Inspector, I book December seventeenth, the form appears with December eighteenth prefilled, I accept, and the result says provisionally booked for the eighteenth. On a twenty twenty six connection, the SDK turns this into an input required result and a retry, but my code doesn't change.

7:49 Try this now

Try this now. Find one tool in your planned server that sometimes can't finish without the human. Decide whether it needs form mode, for simple, non sensitive answers, or URL mode, for anything involving credentials, payments or consent. Write the schema or the URL flow. Then write the fallback message for hosts that don't support elicitation, like, please choose a date between these options and ask again. Finally, list any older features you rely on, like sampling or roots, and plan their replacements.

8:25 Recap

To recap: elicitation gets input from users, with URL mode for anything sensitive. Multi round trip requests make it work statelessly. Sampling, roots and MCP logging are deprecated. And extensions like Tasks and MCP Apps are opt in, so always have a fallback. Your next step: find one tool that needs user input mid call, choose form or URL mode, write the schema or flow, and describe the fallback.