docs: drop the 'Next:' course framing from the page-bottom hand-offs

Ten pages closed with a 'Next: ...' / '... is next' hand-off to the page
that used to follow them in the retired linear read-through. The pointer
and the link are worth keeping -- the word 'Next' is not: it tells a
reader who arrived at one page from a search engine that they are on a
course, which is exactly the tutorial framing this series of changes
removes. Each hand-off keeps its full sentence and its link and loses
only the sequencing word:

  Next: telling connected clients that something changed ... with
  [Subscriptions].
  -> Telling connected clients that something changed ... is
  [Subscriptions].

The one 'Next:' inside Get started (first-steps.md) is deliberately
untouched: that section IS a guided sequence, and there the word is
correct.

Author: maxisbey

docs/client/callbacks.md

@@ -144,4 +144,4 @@ Two more. Neither declares anything.
 * `sampling_callback` and `list_roots_callback` work the same way but serve deprecated features; modern servers use multi-round-trip requests instead.
 * `logging_callback` and `message_handler` receive notifications. They declare nothing.
 
-Next: the first argument you've been passing to `Client(...)` all along, **[Client transports](transports.md)**.
+The first argument to `Client(...)` is a transport object — **[Client transports](transports.md)** covers every kind.

docs/client/index.md

@@ -209,4 +209,4 @@ There is one constructor flag built for that: `Client(mcp, raise_exceptions=True
 * `list_resources` / `list_resource_templates` / `read_resource`, `list_prompts` / `get_prompt`, and `complete` round out the verbs.
 * Every `list_*` takes `cursor=`; loop until `next_cursor` is `None`.
 
-Next: the things a server can ask the *client* for, and how you answer, in **[Client callbacks](callbacks.md)**.
+The things a server can ask the *client* for, and how you answer them, are **[Client callbacks](callbacks.md)**.

docs/handlers/context.md

@@ -126,4 +126,4 @@ On a 2026-07-28 connection, clients receive change notifications only on a `subs
 * `ctx.session` is the channel back to the client: `send_tool_list_changed()` and its siblings tell it to re-fetch a list you changed.
 * Progress reporting and elicitation also start at `Context`; each has its own page.
 
-Next: parameters the model never sees, filled by your own functions, in **[Dependencies](dependencies.md)**.
+Parameters the model never sees, filled by your own functions, are **[Dependencies](dependencies.md)**.

docs/handlers/dependencies.md

@@ -142,4 +142,4 @@ That's the right default for a precondition: no answer, no order. When declining
 * Bad graphs fail at registration with `InvalidSignature`, not mid-call.
 * Return `Elicit(message, Model)` to ask the user, only when you have to. Unwrapped annotations abort on decline; `ElicitationResult[T]` lets the tool branch.
 
-Next: state your server builds once at startup, and how a handler reaches it, in the **[Lifespan](lifespan.md)**.
+State your server builds once at startup, and how a handler reaches it, is the **[Lifespan](lifespan.md)**.

docs/handlers/lifespan.md

@@ -99,4 +99,4 @@ Strip the server down to the lifecycle: give `Database` a `connected` flag, flip
 * `ctx: Context[AppContext]` makes that access fully typed in tools. Resources and prompts take the bare `Context`.
 * No `lifespan=` means an empty `dict`, never `None`.
 
-Next: a handler that stops mid-call to ask the user for something only they know, in **[Elicitation](elicitation.md)**.
+A handler that stops mid-call to ask the user for something only they know is **[Elicitation](elicitation.md)**.

docs/handlers/logging.md

@@ -75,4 +75,4 @@ went to standard error: the terminal, not the wire.
 * Standard error is yours; stdout belongs to the protocol. Never `print()` in a stdio server.
 * `MCPServer(..., log_level="DEBUG")` sets the level, and a logging configuration you made first is left alone.
 
-Next: telling connected clients that something on your server changed — the tool list, a resource — with **[Subscriptions](subscriptions.md)**.
+Telling connected clients that something on your server changed — the tool list, a resource — is **[Subscriptions](subscriptions.md)**.

docs/handlers/progress.md

@@ -114,4 +114,4 @@ The callback receives `total=None`. A client can still show *activity* ("3 impor
 * No callback on the call means `report_progress` does nothing. Report unconditionally.
 * Omit `total` when you don't know it; the callback gets `None`.
 
-Progress is what a running tool shows the *user*. The lines it logs for *you*, the person operating the server, are a different channel: **[Logging](logging.md)** is next.
+Progress is what a running tool shows the *user*. The lines it logs for *you*, the person operating the server, are a different channel: **[Logging](logging.md)**.

docs/servers/completions.md

@@ -122,4 +122,4 @@ Drop `context_arguments=` and the same call returns `[]`. The handler can't know
 * `context.arguments` holds the already-resolved values; the client supplies them as `context_arguments=`.
 * The `completions` capability appears the moment you register the handler. Without it, the request is `Method not found`.
 
-Suggestions help while the user is still *filling in* a prompt or template; to ask them a question in the *middle* of a tool call, you want **[Elicitation](../handlers/elicitation.md)**. Next: everything a tool can return besides text, in **[Images, audio & icons](media.md)**.
+Suggestions help while the user is still *filling in* a prompt or template; to ask them a question in the *middle* of a tool call, you want **[Elicitation](../handlers/elicitation.md)**. Everything a tool can return besides text is **[Images, audio & icons](media.md)**.

docs/servers/prompts.md

@@ -147,4 +147,4 @@ The `prompts/list` entry now carries everything a client needs to draw a good fo
 * `title=` and `Field(description=...)` are what a client puts in its UI.
 * A missing required argument fails the whole request. There is no per-prompt error result.
 
-Next up: server-side autocomplete for a prompt's (or a resource template's) arguments, in **[Completions](completions.md)**.
+Server-side autocomplete for a prompt's (or a resource template's) arguments is **[Completions](completions.md)**.

docs/servers/tools.md

@@ -169,4 +169,4 @@ A well-behaved client uses them to decide things like *"do I need to ask the use
 * Bad arguments are rejected for you, with an error the model can read and recover from.
 * `async def` for I/O, plain `def` for everything else.
 
-Next up, **[Structured Output](structured-output.md)**: what happens to the value you `return`.
+**[Structured Output](structured-output.md)** is what happens to the value you `return`.