1. Introduction: From the Result to the Process

The first part of this series dealt with the main view — the juxtaposition of two answers as a didactic stage. It answers a yes-or-no question, and it answers it convincingly: the attached server makes a visible difference. Yet it is silent about how that difference comes about. Which tools the model chooses and in what order, with which arguments it calls them, how their results flow back into the ongoing dialogue, and at which point several runs finally become a coherent recommendation — all of this runs hidden in automatic operation. The running timeline of the main view hints at the traffic but does not halt it.

It is precisely here that the present second part begins. It deals with the step-by-step view, a view of its own under the routemcp-walkthrough with the title “MCP Server — Step by Step”. Where the main view sets the result of two requests side by side and thereby conceals the mechanism, the step-by-step view reverses the relationship. It halts the pipeline, makes each phase individually triggerable, and turns the otherwise fleeting course into a legible, temporally ordered object. The didactic gain lies in slowing down: what the main view reels off in one go, the walkthrough view decomposes into comprehensible steps that the viewer can walk through at his own pace.

The tour of this part therefore no longer follows the constituents of an interface, but the hurdles that halting and making visible an inherently automatic process brings with it. The first and load-bearing chapter treats the architectural precondition: the decomposition of the automatic tool loop into individual, resumable phases that both views share. There follow the processing track as a timeline, the individual triggering of the phases, the data panel beside the track, the presentation of parallel tool calls, and the streaming and rendering within a single phase card. A concluding chapter brings both parts of the series together.

As in the first part, general familiarity with Vaadin is assumed; particular elements are presented in detail as to their effect. The technical basis matches that of the first part: JDK 26, Vaadin Flow 25.1.6 with embedded Jetty 12.1.10 and Jackson for JSON processing, without Spring and without Jakarta EE. Both views rest on the same protocol logic and differ solely in their drive and in their presentation — a fact that the following chapter takes as its point of departure.

2. From the Automatic Loop to the Halted Pipeline

The step-by-step view and the main view show the same process. This is not an assertion but an architectural fact, and it is the precondition for everything else this part treats. The main view drives the tool loop automatically: it calls the model, executes the requested tools, adds their results to the dialogue and calls the model again, until no further tools are requested. The walkthrough view must halt precisely this loop and decompose it into individually triggerable steps — without the protocol logic being duplicated. Were it duplicated, the two views might show two different courses; yet the didactic value of the walkthrough rests on its showing the same course, merely slowed down.

The solution lies in a dedicated bearer of the protocol logic, theWalkthroughEngine. Each of its methods runs exactly one phase, mutates the supplied state and returns the result as a phase record that the interface can render.

/** Phase 1. Build a fresh state seeded with the system + user message. */publicWalkthroughStatestartRun(StringsystemPrompt,StringuserMessage){returnnewWalkthroughState(systemPrompt,userMessage);}/** Phase 2. Fetch the MCP tool catalogue and attach it to the state. */publicWalkthroughPhase.ToolCatalogfetchToolCatalogue(WalkthroughStatestate){ArrayNodetools=toolBridge.toolsForOllama();state.setToolsArray(tools);List<String>names=newArrayList<>(tools.size());for(JsonNodetool:tools){Stringname=tool.path("function").path("name").asText(null);if(name!=null)names.add(name);}WalkthroughPhase.ToolCatalogphase=newWalkthroughPhase.ToolCatalog(names,tools);state.setCurrentPhase(phase);returnphase;}

The decisive thought stands in the engine’s class comment: the protocol logic resides in a single place, and only the drive differs. The class comment puts it thus: “The engine is shared by the comparison view (driving the phases in an auto loop) and the walkthrough view (driving them one user click at a time); the protocol logic therefore lives in a single place.” The five phases are realised as methods —startRun,fetchToolCatalogue,runModelQuery,executeTools andfinalise — and each is callable on its own. It is precisely because each phase is a method that the walkthrough view can call them individually on a button press, while the main view reels them off in a single loop on one virtual thread.

So that the interface can render each phase uniformly, the phase results are modelled as a sealed interface. Each record carries the partial result the walkthrough view is to show and at the same time names the action that advances to the following phase.

publicsealedinterfaceWalkthroughPhasepermitsWalkthroughPhase.Initial,WalkthroughPhase.ToolCatalog,WalkthroughPhase.ModelQuery,WalkthroughPhase.ToolExecution,WalkthroughPhase.FinalAnswer{/** Short title of the phase, shown as the card heading. */Stringtitle();/** Plain-English description of what just happened. */Stringdescription();/** Label of the button that advances to the next phase. */StringnextActionLabel();/** True when this phase is the last one; the run is complete. */defaultbooleanterminal(){returnfalse;}

The sealed interface finally names its five permitted forms. Each is realised as arecord and knows three pieces of information: a title for the card heading, a description of what has just happened, and the label of the button that leads to the next phase. Each phase thus carries its own rendering instruction with it; the interface need not know which phase it is in, but asks the record for title, description and next action. The last phase reports throughterminal that the run is complete.

The course of the phases can be read as a state machine. The first two phases occur once each; between the model query and the tool execution runs a loop that is repeated until the model requests no further tools; then the run issues into the final answer.

It is on this very state machine that both views rest. The main view traverses it of its own accord, without pause; the walkthrough view pauses at each transition and leaves the next step to the viewer. Which drive is at work is a property of the view, not of the engine.

The decomposition into resumable phases is thus far more than a structural convenience. It is the guarantee that the slowed-down presentation of the walkthrough view does not show a reconstructed imitation of the course, but the course itself — the same one that the main view reels off in a single go. On this foundation the following chapter can show how the individual phases become a growing track.

3. The Processing Track as a Timeline

Where the main view shows only the final result, the walkthrough view preserves the entire path to it. The central visual element in which this path becomes visible is the processing track: a vertical sequence of cards that grows by one card with every completed phase. The track is thus not merely a display element but the actual record of the process — a record the viewer can read in retrospect, because it persists rather than flowing away like the stream of the main view.

The bearer of the track is a plain container that takes up a card for each phase. It arises when the view is assembled, beside the data panel.

javaCopy

publicWalkthroughView(){addClassName("recipe-shell");addClassName("recipe-walkthrough");setSizeFull();Divbody=newDiv(buildTrack(),dataPanel);body.addClassName("recipe-body");body.setSizeFull();add(body);configureControls();}

The left half of the body forms the track, the right half the data panel, to which a chapter of its own is devoted. Within the track atrackContainer collects the cards. Each phase has its own build method that creates a card and appends it to the container. The first phase, the initial situation, shows the pattern in its purest form.

javaCopy

privatevoidrenderInitialCard(WalkthroughPhase.Initialphase,RunnableonNext){Divcard=newCard(null,"recipe-card--initial");Spanchip=makeChip("recipe-chip--initial",VaadinIcon.FLAG_O,phase.title());Divheader=headerRow(chip);Spansubtitle=makeSubtitle("Conversation context, ready to be sent. Nothing has hit the model yet.");Divresult=newDiv();result.addClassName("recipe-card__result");result.add(makeSection("System prompt",phase.systemPrompt()));result.add(makeSection("User message",phase.userMessage()));Divdescription=makeDescriptionBlock(phase.description());card.add(header,subtitle,result,description);trackContainer.add(card);addNextButton(card,phase.nextActionLabel(),onNext);}

Every card follows the same construction: a header row with an icon belonging to the phase and the title, a subtitle, a result area with the respective content of the phase, and a description of what has happened. Title, description and the label of the next action come directly from the phase record — those very pieces of information that the previous chapter showed on the sealed interface. The card therefore need not know which phase it renders; it asks the record. Finally,trackContainer.add appends the card to the track, andaddNextButton furnishes it with a button that leads to the next phase.

The order of the cards is not arbitrary but carries meaning. Cards stacked one above another denote a sequential dependency: one phase follows from the previous. Between consecutive cards a connector drawn purely via CSS is therefore shown — a line with an arrowhead that makes the flow visible at a glance. These connectors are not part of the Java source but are drawn in the stylesheet through the pseudo-elements::before and::after; the cards themselves thereby remain plain.

The numbering of the phases reflects this temporal order. The initial situation bears the one, the tool catalogue the two; the model queries bear the three with a sub-number per run (3.1, 3.2 …), the tool executions the four with the same sub-number (4.1, 4.2 …), and the concluding summary the five. Thus from the label of each card one can read at which point of the run it stands and how often the loop between model and tools has already been traversed.

The last card falls outside the pattern, for it shows no further phase of the protocol but a summary of the run: a few figures — the total time, the number of model runs, the number of tool calls and an estimated number of output tokens — and a small bar chart that sets the duration of the individual phases in proportion. The actual answer is not repeated by this card, for it was already rendered in the last model-query card — a circumstance the seventh chapter pursues. With the processing track the stage is thus set; the following chapter shows how the viewer brings the individual cards into being.

4. Triggering Phases Individually

The processing track does not grow of its own accord. The viewer sets the pace by triggering each phase individually — and this very interaction model is the heart of the walkthrough view. The previous chapter showed that each card receives, at its end, a button whose label names the next phase: “Fetch tool catalogue from MCP”, “Send initial model query”, “Execute the tool”, “Send follow-up model query”. A press on this button calls the corresponding method of the engine, whose result appears as a new card, which in turn carries the button to the phase after next. Thus the run proceeds step by step, each step a deliberate action.

The question of what “resumable” means in a server-side interface can be answered precisely here. The state of the run rests, between two steps, in a field of the view — theWalkthroughState, which the engine mutates and returns on every call. A step takes up this state, runs its phase and deposits the result back into the state. Between the steps nothing happens; the view remains in a clearly recognisable, resting state and waits for the viewer’s next action.

Since the individual phases contain blocking calls to the model and to the tools, the update model familiar from the first part applies here too: execution takes place on a background thread, and the result is channelled into the component tree by way of@Push andUI.access. Two flags secure the orderly course:phaseInFlight indicates that a phase is currently running, andautoRunning whether the viewer has chosen the automatic run.

For besides stepping forward, the view offers a second way: the “Run to End” button, which traverses the remaining phases of its own accord. During such an automatic run the buttons of the individual cards are suppressed; the cards still appear as soon as their phase is resolved, but a brief pause is inserted between the phases so that the progression remains legible. This pause amounts to 350 milliseconds and is inserted by way of a dedicated virtual thread.

javaCopy

privatevoidscheduleAutoContinue(){UIui=UI.getCurrent();Thread.startVirtualThread(()->{try{Thread.sleep(AUTO_RUN_PAUSE_MS);}catch(InterruptedExceptionie){Thread.currentThread().interrupt();return;}try{ui.access(this::continueAuto);}catch(UIDetachedExceptionignored){}});}

The background thread sleeps the fixed pause and then triggers the next step by way ofUI.access. Thetry block aroundui.access catches theUIDetachedException — the case in which the viewer has meanwhile left the view; the automatic run then runs quietly into the void instead of throwing an error. Where the automatic and the step-by-step drives part ways is shown by the conclusion of a phase. After the tool execution, for instance, a single branch decides whether things continue automatically or whether the next button is offered to the viewer.

javaCopy

phaseInFlight=false;if(autoRunning){scheduleAutoContinue();}else{addNextButton(card,exec.nextActionLabel(),this::advanceToModelQuery);updateRunToEndAvailability();}

If the automatic run is chosen, the phase schedules its own continuation; otherwise the card receives a button whose label again stems from the phase record and whose activation leads to the next phase. The difference from the automatic loop of the main view is thus named precisely: it is not the mechanics of the transmission that change — they are the same in both views — but solely the trigger. In place of the self-acting continuation steps the viewer’s deliberate action.

A “Reset” button next to the input field clears the track and the recorded figures again, so that a new prompt can be entered. The viewer thus has three operating actions at his disposal: to begin a run, to carry it through step by step or of its own accord, and to reset it. Which way is chosen changes nothing about the course shown, only its pace — and precisely therein lies the didactic value: the viewer can study the same process once at leisure and once let it run in context. The following chapter turns to the second major constituent of the view, the data panel.

5. The Data Panel

Beside the processing track stands a second area to which this chapter is devoted: the data panel. While the track records the temporal succession of the phases, the data panel shows the current state of the data the model accesses — the pantry and the dietary profile. The relationship of the two areas is that of course and state: the track answers the question of how the present state came about; the data panel answers the question of what this state looks like at this moment.

Notable is what the data panel is built with. It is not a component of its own but the same sidebar that the main view already uses — here merely carried under a different name.

javaCopy

privatefinalSidebardataPanel=newSidebar(services.pantry(),services.profile());

The reuse is no accident but the expression of the same principle that ran through the first part: the business state is maintained in exactly one place, and both views access it through the same REST clients. What was said in the first part about the writing and reloading of the sidebar holds here unchanged. The only difference lies in the role: in the main view the sidebar is the operator’s instrument; in the walkthrough view it additionally appears as an object of illustration showing what the model can read.

In the assembly of the view the data panel appears as the right half of the body, set opposite the track.

javaCopy

Divbody=newDiv(buildTrack(),dataPanel);body.addClassName("recipe-body");body.setSizeFull();add(body);

The subtitle line of the view names the panel’s task expressly: “The data panel on the right reflects what the model can read; the track below grows one card per step.” With that, the interplay of the two areas is brought to the point. On the left the track grows card by card and shows the process; on the right stands the data panel and shows the object to which the process refers.

The data panel is not rigid but is refreshed in the course of the run — and indeed at the point at which the model may actually have changed the state. After the tool execution, when a state-mutating tool such as consuming an ingredient or adjusting the profile has run, the view reloads the panel.

javaCopy

dataPanel.refreshGrid();dataPanel.refreshProfileForm();

It is here that the didactic gain of juxtaposing course and state shows itself. The viewer sees in the track that a tool was called which changes the pantry; and he sees, at the same moment, in the data panel how the pantry has thereby changed. The one explains the other: the tool execution in the track is the cause, the changed display in the data panel the effect. Where the main view performs the refresh only at the end of a whole run, here it happens after each individual tool execution — fitting to the slowed-down pace of the walkthrough, which wishes to make each effect visible on its own.

Thus track and data panel come together as two perspectives on the same process. The one shows the sequence of actions, the other their precipitation in the state. The following chapter returns to the track and considers a case that demands a presentation of its own: the simultaneous execution of several tools.

6. Presenting Parallel Tool Calls

If the model requests several tools at once in a single reply, a twofold task arises: the calls are to be executed concurrently, and their simultaneity is at the same time to be presented as such. The walkthrough view solves both sides of this task in a way that directly reflects the technical reality of the engine.

The execution is taken on by the engine in its fourth phase. It opens an executor with one virtual thread per task, submits aCompletableFuture for each tool call, waits withallOf for their completion, and collects the results in the original order of the request.

javaCopy

try(ExecutorServiceexecutor=Executors.newVirtualThreadPerTaskExecutor()){List<CompletableFuture<WalkthroughPhase.ToolOutcome>>futures=newArrayList<>(calls.size());for(WalkthroughPhase.PendingToolCallcall:calls){futures.add(CompletableFuture.supplyAsync(()->invokeSafely(call),executor));}CompletableFuture.allOf(futures.toArray(newCompletableFuture[0])).join();List<WalkthroughPhase.ToolOutcome>outcomes=newArrayList<>(calls.size());for(CompletableFuture<WalkthroughPhase.ToolOutcome>f:futures){outcomes.add(f.join());}

Three properties of this execution deserve attention. First, the calls are genuinely conducted simultaneously, each on a virtual thread of its own. Second, the results are collected in the order of the request, not in the order of their arrival; the presentation thereby remains stable, whichever call answers first. Third, a failed call throws no exception but is returned throughinvokeSafely as an error outcome, so that the model can react to it on the next run.

The presentation of this simultaneity rests on a deliberate decision: several calls requested at once are not shown as separate, vertically stacked cards, but as side-by-side lanes within a single tool-execution card, furnished with a parallel marker that names how many concurrent virtual threads are running. Vertically stacked cards denote, as the third chapter showed, a sequential dependency; side-by-side lanes denote simultaneity. The form of the presentation thus itself carries a statement about the concurrency.

While a call is still running, its lane shows the name of the tool, the arguments and a hint at the pending result.

javaCopy

privateDivbuildLaneRunning(WalkthroughPhase.PendingToolCallc){Divlane=newDiv();lane.addClassName("recipe-walkthrough__lane");lane.addClassName("recipe-walkthrough__lane--running");Spanname=newSpan(c.name()+"(...)");name.addClassName("recipe-walkthrough__tool-name");Preargs=newPre(prettyJson(c.argumentsJson()));args.addClassName("recipe-walkthrough__json");Spanpending=newSpan("Awaiting MCP response...");pending.addClassName("recipe-walkthrough__pending");lane.add(name,args,pending);returnlane;}

Once the execution is complete, the card replaces the running lanes with the resolved ones and at the same time refreshes the data panel.

javaCopy

privatevoidfinishToolExecutionCard(Divcard,Divdescription,Divresult,Divlanes,DivprogressWrap,WalkthroughPhase.ToolExecutionexec){result.remove(progressWrap);card.removeClassName("running");lanes.removeAll();for(WalkthroughPhase.ToolOutcomeoc:exec.outcomes()){lanes.add(buildLaneResolved(oc));}description.removeAll();description.add(makeDescriptionLabel("Description"));description.add(newDiv(newSpan(exec.description())));dataPanel.refreshGrid();dataPanel.refreshProfileForm();

Each resolved lane shows the name of the tool, the arguments and the neatly formatted result JSON; an erroneous call paints its lane red. Notably, the refresh of the data panel happens precisely here — after the execution, when the tools may have changed the state — which closes the arc to the previous chapter.

The statement of the presentation — sequential below one another, parallel beside one another — corresponds to the reality of the engine. The description of the phase record brings this to the point: “The MCP server executed all N tools concurrently (parallel virtual threads). Each lane shows arguments and result independently.”

Thus the walkthrough view makes the concurrency both effective and visible. It conducts the calls genuinely simultaneously, and it shows them in a form that does not veil this simultaneity but displays it — without thereby losing the temporal placement of the calls within the overall course, for all lanes dwell in one and the same card at its place in the track.

The following chapter returns to a detail that dwells in the model-query card and closes the arc to the first part: the streaming of the text and its final presentation as Markdown within a single card.

7. Streaming and Markdown in the Phase Card

The fifth chapter of the first part ended with a forward reference. There it was shown that the main view renders the stream directly as Markdown, and at the same time it was announced that the step-by-step view takes the opposite path: raw text first, then rendered. This counter-design the present chapter makes good on. It dwells in the model-query card, that card which represents a single call to the model.

While the stream runs, the text grows in a plain area. On assembly the card is furnished with such astreamDiv, an indeterminate progress bar and — as a particularity of the walkthrough view — a presentation of the request that was sent. Then, on a virtual thread, the call to the engine runs, whose callback appends each fragment to the raw-text area.

javaCopy

StringBuilderbuffer=newStringBuilder();Divheader=headerRow(chip);Divdescription=makeDescription();Divresult=newDiv(requestSection,replyLabel,progressWrap,streamDiv);result.addClassName("recipe-card__result");card.add(header,subtitle,result,description);trackContainer.add(card);java.time.Instantt0=java.time.Instant.now();intiterationLabel=nextIter;Thread.startVirtualThread(()->{try{WalkthroughPhase.ModelQueryquery=engine.runModelQuery(state,chunk->ui.access(()->{buffer.append(chunk);streamDiv.setText(buffer.toString());}));

The callback appends each fragment to the buffer and sets its content as plain text on thestreamDiv. It issetText, not the setting of Markdown content: during the stream the answer deliberately appears as raw text. With that, the two-stage approach announced in the first part is visible in its first stage. Notable, too, is the presentation of the request that precedes the card: it shows exactly the messages that were sent to the model — system and user message and, in later runs, the preceding replies and tool results — so that the viewer recognises precisely what the model received.

The second stage sets in as soon as the stream is complete. The card then decides, on the basis of the requested tools, how it presents itself finally.

javaCopy

if(query.toolCalls().isEmpty()){result.remove(streamDiv);Markdownrendered=newMarkdown(streamedText.isBlank()?"_(no text)_":streamedText);rendered.addClassName("recipe-walkthrough__rendered");result.add(rendered);phaseInFlight=false;// The streamed text is already rendered as Markdown here, so the// dedicated "final answer" card would be redundant. Skip straight// into the run-summary card with timing + token stats.if(autoRunning){scheduleAutoContinue();}else{scheduleAutoSummaryAdvance();}}else{if(streamedText.isBlank()){streamDiv.setText("(no text emitted; the model went straight to tool calls)");streamDiv.addClassName("recipe-walkthrough__stream--empty");}

If the model requests no tools, this is the final answer. The card removes the raw-text area and replaces it with a freshly createdMarkdown component — the second stage of the announced two-stage approach. It is precisely because the final answer is already rendered here that a dedicated card for the “final answer” would be superfluous; the comment in the source says so expressly. The view therefore proceeds directly to the summary card that the third chapter described as the last card of the track. If, on the other hand, the model requests tools, the raw text remains — with a hint, where applicable, should the model have gone straight to the tool calls — and beneath it appears a listing of the requested calls.

The reason for this different choice from the main view lies, as already set out in the first part, in the different purpose. The teaching view prefers a calm, stable picture of each phase. During the stream it shows the raw text, which grows calmly without incomplete markup rearranging itself beneath the viewer’s gaze; only after completion does the rendered document take its place. The phase description confirms it: “Streaming is complete and the text is rendered as Markdown.”

With that, the arc that the first part spanned is closed. The two views answer the same design question in two well-founded ways: the main view renders progressively, to show the vividness of the emergence; the walkthrough view shows raw text first and renders after completion, to preserve the calm of study. Both ways follow the same principle, that an interface should honestly reflect the state of its content. The following chapter returns to a card that the run passed through early and that rewards a closer look: the tool-catalogue card.

8. The Tool-Catalogue Card

At its beginning the run passes through a card that the preceding narrative left behind quickly: the tool-catalogue card, the second phase. It deserves a closer look, for it is more than a mere list. It makes visible which tools the attached server offers the model at all, and it does so in a form that surpasses mere enumeration: with clickable badges and full JSON descriptors, between which a smooth scroll mediates.

The card carries two areas: a row of badges and a sequence of entries. Each entry presents a tool in detail — with name, description and the full JSON descriptor — while the badges serve as concise, clickable jump marks. The construction of the entries arises from the tool array that the engine procured in the second phase.

javaCopy

java.util.Map<String,Div>entryByName=newjava.util.LinkedHashMap<>();for(JsonNodetool:phase.toolsArray()){StringtoolName=tool.path("function").path("name").asText();if(toolName==null||toolName.isBlank())continue;Diventry=newDiv();entry.addClassName("recipe-walkthrough__tool-entry");entry.getElement().setAttribute("data-tool-name",toolName);SpanentryTitle=newSpan(newIcon(VaadinIcon.CODE),newSpan(toolName));entryTitle.addClassName("recipe-walkthrough__tool-entry-title");Stringdescription=tool.path("function").path("description").asText("");if(!description.isBlank()){SpanentryDesc=newSpan(description);entryDesc.addClassName("recipe-walkthrough__tool-entry-desc");entry.add(entryTitle,entryDesc);}else{entry.add(entryTitle);}Prejson=newPre(prettyJson(tool.toString()));json.addClassName("recipe-walkthrough__json");entry.add(json);entries.add(entry);entryByName.put(toolName,entry);}

Two things deserve attention. First, name and description are read directly from the tool’s JSON node — viapath andasText — so that the card shows exactly what the server actually offers, not a maintained second version. Second, aLinkedHashMap holds the mapping of tool names to entryDiv and thereby preserves the order; it is this very mapping that allows the badges to jump to their entry. The full descriptor is attached as a monospacedPre block.

The badges arise in a second pass, this time over the phase’s list of names. If an entry is found for a name, the badge is made clickable and furnished with the features necessary for operability and accessibility.

javaCopy

for(Stringname:phase.toolNames()){Spantag=newSpan(name);tag.addClassName("recipe-walkthrough__tool-tag");Divtarget=entryByName.get(name);if(target!=null){tag.addClassName("recipe-walkthrough__tool-tag--clickable");tag.getElement().setAttribute("title","Jump to "+name+" descriptor");tag.getElement().setAttribute("role","button");tag.getElement().setAttribute("tabindex","0");tag.getElement().addEventListener("click",ev->scrollToToolEntry(target));tag.getElement().addEventListener("keydown",ev->scrollToToolEntry(target)).setFilter("event.key === 'Enter' || event.key === ' '");}tags.add(tag);}

Here it shows how much can be regulated on the element itself with the platform’s own means in Vaadin Flow. The badge receives, throughsetAttribute, the role of a button, a tooltip and a tab index, so that it is reachable not only with the mouse but also with the keyboard. Two listeners are attached to the element — one for the mouse click, one for the keyboard — whereby the keyboard listener is restricted throughsetFilter to the Enter and the space key. This filter is notable: it is a client-side expression that decides already in the browser whether the event is reported to the server at all; needless server round trips are thereby avoided.

The actual jumping is taken on by a small method that triggers client-side behaviour throughexecuteJs.

javaCopy

privatevoidscrollToToolEntry(Divtarget){target.getElement().executeJs("this.scrollIntoView({behavior:'smooth', block:'start'});"+"this.classList.add('recipe-walkthrough__tool-entry--flash');"+"setTimeout(() => "+"this.classList.remove('recipe-walkthrough__tool-entry--flash'),"+" 1500);");}

The passed JavaScript expression lets the target entry scroll smoothly into the visible area and then adds to it, for a second and a half, a style class that makes it flash briefly before it is removed again. Thus, after a click on a badge, the viewer not only finds the corresponding descriptor again, but his gaze is led directly to it by the flash. Thatthis within the expression refers to the target element is the bridge between the server-side component and its client-side counterpart.

The catalogue card thus comes together from three simple means: the reading of the real tool array, the linking of badge and entry through an ordered mapping, and a slim piece of client-side behaviour for the jumping and flashing. A charting library or an additional framework is not needed for this; the element and its methods suffice.

The following chapter turns to the last card of the run, which is likewise built by hand and uses no bought-in chart: the summary card.

9. The Summary Card

The last card of the run shows no further phase of the protocol but a balance: a few figures and a bar chart that sets the duration of the individual phases in proportion. The third chapter already mentioned it as the conclusion of the track; here let it be considered in detail, for it is pure, hand-assembled Vaadin composition — without a charting library, solely from elementary components and proportionally set widths.

The card itself is plainly built. It strings together a row of stat tiles and a bar chart; the actual answer it does not repeat, since that was already rendered in the last model-query card.

javaCopy

privatevoidrenderFinalAnswerCard(WalkthroughPhase.FinalAnswerphase){Divcard=newCard(null,"recipe-card--final");Spanchip=makeChip("recipe-chip--final",VaadinIcon.CHART_LINE,"5. Run summary");Divheader=headerRow(chip);Spansubtitle=makeSubtitle("Timing and approximate token usage per phase. Token counts are "+"estimated as streamed-chars / 4.");Divresult=newDiv();result.addClassName("recipe-card__result");result.add(buildSummaryTiles(phase));result.add(buildPhaseChart());Divdescription=makeDescriptionBlock(phase.description());card.add(header,subtitle,result,description);trackContainer.add(card);}

The figures arise from the statistics captured phase by phase during the run. Each completed phase has left behind aPhaseStat record — with label, colour class, duration and a size figure together with a unit, for instance the number of tools or the character count of the stream. From these values the card sums the total duration, the number of tool calls and the total of streamed characters.

javaCopy

privateDivbuildSummaryTiles(WalkthroughPhase.FinalAnswerphase){longtotalChars=0;longtotalDurationMs=0;inttoolCalls=0;for(PhaseStats:phaseStats){totalDurationMs+=s.duration().toMillis();if("chars".equals(s.sizeLabel()))totalChars+=s.sizeValue();if("tool".equals(s.sizeLabel())||"tools".equals(s.sizeLabel())){toolCalls+=(int)s.sizeValue();}}longwallClockMs=runStartedAt==null?totalDurationMs:java.time.Duration.between(runStartedAt,java.time.Instant.now()).toMillis();longapproxTokens=totalChars/4;Divtiles=newDiv();tiles.addClassName("recipe-walkthrough__summary-tiles");tiles.add(buildTile(VaadinIcon.CLOCK,formatMillis(wallClockMs),"Total time"));tiles.add(buildTile(VaadinIcon.REFRESH,Integer.toString(phase.iterations()),"Model iterations"));tiles.add(buildTile(VaadinIcon.COGS,Integer.toString(toolCalls),"Tool calls"));tiles.add(buildTile(VaadinIcon.FILE_TEXT_O,"≈ "+approxTokens,"Output tokens (~chars/4)"));returntiles;}

Two subtleties deserve attention. The total duration, when the start instant is known, is measured as the actually elapsed wall-clock time between beginning and present, not as a mere sum of the phase durations; pauses between the steps thus enter the reported total time. And the number of output tokens is not measured but estimated from the character count — as character count divided by four — which is why the tile carries the approximately sign. It is a deliberately coarse approximation that gives the viewer an order of magnitude without promising more than it can hold.

Each individual tile is a small, ever-identical building block of icon, value and label.

javaCopy

privateDivbuildTile(VaadinIconicon,Stringvalue,Stringlabel){Divtile=newDiv();tile.addClassName("recipe-walkthrough__tile");Iconi=newIcon(icon);i.addClassName("recipe-walkthrough__tile-icon");SpanvalueSpan=newSpan(value);valueSpan.addClassName("recipe-walkthrough__tile-value");SpanlabelSpan=newSpan(label);labelSpan.addClassName("recipe-walkthrough__tile-label");tile.add(i,valueSpan,labelSpan);returntile;}

The bar chart is the most instructive part of the card, for it shows how a usable chart can be drawn without any charting library, solely with the means of the platform. First the largest duration value is determined, which serves as the reference magnitude for the scaling; then each phase receives a row.

javaCopy

privateDivbuildPhaseChart(){Divchart=newDiv();chart.addClassName("recipe-walkthrough__chart");SpanchartTitle=makeSectionLabel(VaadinIcon.BAR_CHART_H,"Per-phase duration");chart.add(chartTitle);longmaxMs=1;for(PhaseStats:phaseStats){maxMs=Math.max(maxMs,s.duration().toMillis());}for(PhaseStats:phaseStats){chart.add(buildChartRow(s,maxMs));}returnchart;}

The core lies in the individual row. From the duration of the phase and the previously determined maximum a percentage is calculated which is set directly as the width of the bar. A lower bound of two per cent ensures that even very short phases appear as a visible bar and do not vanish entirely.

javaCopy

privateDivbuildChartRow(PhaseStats,longmaxMs){Divrow=newDiv();row.addClassName("recipe-walkthrough__chart-row");Spanlabel=newSpan(s.label());label.addClassName("recipe-walkthrough__chart-label");longms=s.duration().toMillis();doublepct=Math.max(2.0,(ms*100.0)/maxMs);DivbarTrack=newDiv();barTrack.addClassName("recipe-walkthrough__chart-track");Divbar=newDiv();bar.addClassName("recipe-walkthrough__chart-bar");bar.addClassName("recipe-walkthrough__chart-bar--"+s.colorClass());bar.getStyle().set("width",String.format(java.util.Locale.ROOT,"%.1f%%",pct));barTrack.add(bar);Spanduration=newSpan(formatMillis(ms));duration.addClassName("recipe-walkthrough__chart-duration");Spansize=newSpan(s.sizeValue()+" "+s.sizeLabel());size.addClassName("recipe-walkthrough__chart-size");row.add(label,barTrack,duration,size);returnrow;}

The width of the bar is set directly on the element throughgetStyle().set("width", …) as a percentage; the colour stems from a style class whose name is formed from the colour class of the phase, so that the bars match the badges of the phases by colour. Beside the bar the row shows the duration and the size figure. The duration is formatted legibly: below a second in milliseconds, above it in seconds with two decimal places.

javaCopy

privatestaticStringformatMillis(longms){if(ms<1000)returnms+" ms";returnString.format(java.util.Locale.ROOT,"%.2f s",ms/1000.0);}

Thus from a few building blocks a complete little chart arises: a reference magnitude, a row per phase, a bar set proportionally in its width and a readable label. Notable is all that was not needed here — no charting library, no drawing on a canvas, no additional framework. ADiv given a percentage width is already a bar; no more is required.

With that, the two cards that the run passed through quickly or reached last have also been considered. The following and final chapter draws the sum and brings both parts of the series together.

10. Conclusion

The first part of this series showed that the attached server makes a difference; the second has shown how that difference comes about. With that, the arc spanned by the introduction to the first part is closed — the passage from the what to the how. The step-by-step view halts what the main view reels off in one go and turns the fleeting course into a legible object.

The load-bearing insight of this part was architectural in nature: both views rest on the same engine. The protocol logic lives in a single place, in theWalkthroughEngine, whose five phases are realised as individually callable methods. It is precisely this decomposition into resumable phases that guarantees the slowed-down walkthrough shows not an imitation but the same course that the main view traverses of its own accord. On this foundation stood the remaining chapters: the processing track, which preserves the process card by card as a timeline; the individual triggering of the phases, which leaves the pace to the viewer; the data panel, which sets the state beside the course; the presentation of parallel tool calls, whose form itself displays the concurrency; the streaming with a final Markdown rendering in the phase card, which made good on the counter-design announced in the first part; the tool-catalogue card, which assigns clickable badges and full JSON descriptors to the tools offered to the model; and finally the summary card, which concludes the run in figures and a hand-drawn bar chart.

However different the two views are in their effect, they are connected by the same principle that already ran through the first part. An interface for model-driven tool use must not merely display results; it must keep the process of their emergence comprehensible. The main view fulfils this principle through juxtaposition and simultaneity; the walkthrough view fulfils it through halting and decomposition. Both are different answers to the same demand, and precisely their difference shows that the demand admits of more than one realisation.

There remains the retrospect on the series as a whole. It began with an MCP server built using nothing but the platform’s own means, without Spring and without Jakarta EE. It continued with an interface that preserved the same renunciation of heavyweight frameworks and confined itself to Vaadin Flow with embedded Jetty. And it concluded with two views on the same process, which show that the value of an attached server cannot merely be asserted but can be demonstrated — once as a result, once as a process. Whoever has followed the series from beginning to end thus possesses not only a runnable demonstrator but an understanding of why a carefully conducted interface is indispensable for conveying model-driven tool use.

]]>JavaVaadinMCPhttps://svenruppert.com/posts/recipe-assistant-vaadin-ui-part-1-the-main-view/Fri, 26 Jun 2026 12:00:00 +0200sven.ruppert@gmail.com (Sven Ruppert)Sven Rupperthttps://svenruppert.com/posts/recipe-assistant-vaadin-ui-part-1-the-main-view/Building a Vaadin Flow interface that puts two model answers side by side — with and without an MCP server attached — to make the value of the protocol immediately perceivable. A tour through six concrete challenges, from running Vaadin without a starter to keeping state consistent under two writers.<![CDATA[

1. Introduction: The Interface as Proof

The preceding article in this series built an MCP server using nothing but the facilities of the JDK and placed the Model Context Protocol in its conceptual context. Its outcome, however, was not the server itself but a single image: two answers from the same language model, set side by side, on the left without an attached server and on the right with one. The left-hand answer draws solely on the model’s general knowledge of the world and proposes recipes that bear no relation to the user’s actual circumstances. The right-hand answer reaches, by way of the MCP server, into the actual pantry and the stored dietary profile, and recommends what can be prepared from the available ingredients while respecting the diet and the medical constraints.

This image is more than an illustration. It is the actual argument of the entire project. The value of a protocol for tool integration may be disputed at length so long as it is merely asserted; yet once two visibly different answers come into being before the viewer’s eyes at the very same moment, the dispute dissolves. The juxtaposition replaces assertion with immediate perception. For precisely this reason, it is not only the server but also the interface that produces this image which merits an examination of its own. Where the first article dealt with the mechanics of the protocol, the present part descends to the question of its perceptibility.

However plain the two-column arrangement may appear to the viewer, its production is anything but self-evident. For the compelling image to arise, two requests to the same model must be conducted concurrently, the one without and the other with an attached tool catalogue. Their answers arrive character by character and at differing speeds, and they must flow simultaneously into two separate areas without intermingling. The protocol traffic that makes the right-hand answer possible in the first place runs hidden during normal operation and must be rendered legible by deliberate design. And all of this has to happen without the interface stalling or losing the impression of simultaneity on which its effect depends.

From this follows the guiding observation of this part: the persuasive force of the juxtaposition rests less on the logic of the answers than on the discipline of their presentation. An interface for model-driven tool use must not merely display results; it must keep the process of their emergence comprehensible.

The present part is therefore conceived as a tour through the concrete challenges rather than as an exhaustive catalogue of every constituent of the interface. Each of the following chapters takes up a challenge of its own: running Vaadin without the comfort of a framework, conducting two requests concurrently, channelling a character-by-character stream into a server-side component tree, drawing an honest distinction between an unfinished and a completed answer, making the protocol visible, and finally preserving a consistent state. The beginning is made by the question of how the application comes to run at all — and that without Spring, without Jakarta EE, and with as few dependencies as possible.

2. Running Vaadin Without a Starter

Anyone setting up a Vaadin application usually reaches for a starter. A single dependency entry, an annotation, and the interface is up and running; the servlet is registered, the initialisers are discovered, the static resources are mounted, and the WebSocket channel stands ready. All of this happens behind a façade that the developer neither sees nor needs to understand. For a project that has made a deliberate point of forgoing Spring and Jakarta EE, however, this very façade is the object of interest. The present chapter opens it and shows the few, clearly nameable steps of which the start-up in fact consists.

The entry point could hardly be plainer. The module’sMain class first sets the default locale of the virtual machine to English and then starts the embedded server on the centrally held port.

javaCopy

packagecom.svenruppert.mcp.ui;importcom.svenruppert.dependencies.core.logger.HasLogger;importcom.svenruppert.mcp.common.Ports;importjava.util.Locale;publicfinalclassMainimplementsHasLogger{publicstaticvoidmain(String[]args)throwsException{Locale.setDefault(Locale.ENGLISH);newMain().run();}privatevoidrun()throwsException{logger().info("vaadin-ui starting on port {}",Ports.VAADIN_UI);newUiServer(Ports.VAADIN_UI).start();}}

Setting the locale is no incidental detail. The entire application presents itself in English, right down to thelang attribute that Vaadin writes into the delivered HTML. Without this fixing, the application would adopt the locale of the host machine and would unexpectedly speak German on a German system. The actual work is carried out byUiServer, whose start-up routine structures the remainder of the chapter.

The first step erects the server and the servlet context. Here the first non-obvious decision already arises.

javaCopy

publicvoidstart()throwsException{server=newServer(port);ServletContextHandlercontext=newServletContextHandler();context.setContextPath("/");context.setSessionHandler(newSessionHandler());// Sharing the parent classloader avoids the server/system class isolation// that a WebAppContext would impose.context.setClassLoader(Thread.currentThread().getContextClassLoader());// Expose every META-INF/resources/ directory from the classpath as a// virtual webapp root. Servlet 3.0 lets JARs ship static assets there// (Vaadin's flow-push delivers vaadinPush-min.js under// META-INF/resources/VAADIN/static/push/), but ServletContextHandler// does not auto-mount them the way WebAppContext does.context.setBaseResource(metaInfResources(context));

A plainServletContextHandler is used, not the more obviousWebAppContext. The difference is decisive here. AWebAppContext installs a class loader of its own whose separation between server and application classes hides the classes fromorg.eclipse.jetty.* from the application. Vaadin, however, requires these classes during its own initialisation, which is why aWebAppContext would cause the Vaadin initialisers to fail. TheServletContextHandler instead shares the class loader of the calling thread, and the isolation falls away. This very plainness, however, buys extra effort elsewhere: static resources that aWebAppContext would mount of its own accord must now be provided explicitly. The helper method responsible for this is examined further below.

In the second step, theVaadinServlet is registered.

javaCopy

// Register VaadinServlet at "/*". Async + WebSocket support is needed for @Push.ServletHoldervaadinHolder=newServletHolder("vaadin",newVaadinServlet());vaadinHolder.setInitParameter("productionMode","true");vaadinHolder.setAsyncSupported(true);vaadinHolder.setInitOrder(1);context.addServlet(vaadinHolder,"/*");// ServletDeployer is a context listener. With VaadinServlet already registered,// it logs and skips creation.context.addEventListener(newServletDeployer());

The servlet is registered under the path pattern/* and thus answers every request. Three settings deserve attention. Production mode switches off the development regime with its continuous frontend build and presupposes the previously produced production bundle. Enabling asynchronous processing is the precondition for@Push to work at all later on. The init order, finally, ensures that the servlet comes up early in the initialisation of the context. TheServletDeployer registered afterwards is a context listener that would otherwise create the servlet itself; since the servlet has already been registered by hand, it confines itself to a log entry.

The third and most extensive step constitutes the heart of the framework-free start-up. Since Vaadin 25, the framework no longer registers its initialisers of its own accord; they must therefore be registered by hand, and in the correct order.

javaCopy

// Vaadin SCIs in correct order. LookupServletContainerInitializer must run first.context.addServletContainerInitializer(newServletContainerInitializerHolder(LookupServletContainerInitializer.class,LookupInitializer.class,loadVaadinClass("com.vaadin.flow.di.LookupInitializer$ResourceProviderImpl"),loadVaadinClass("com.vaadin.flow.di.LookupInitializer$StaticFileHandlerFactoryImpl"),loadVaadinClass("com.vaadin.flow.di.LookupInitializer$AppShellPredicateImpl"),DefaultApplicationConfigurationFactory.class,DefaultRoutePathProvider.class));context.addServletContainerInitializer(newServletContainerInitializerHolder(RouteRegistryInitializer.class,MainView.class,WalkthroughView.class,MainLayout.class));context.addServletContainerInitializer(newServletContainerInitializerHolder(VaadinAppShellInitializer.class,AppShell.class));context.addServletContainerInitializer(newServletContainerInitializerHolder(AnnotationValidator.class,AppShell.class));context.addServletContainerInitializer(newServletContainerInitializerHolder(ErrorNavigationTargetInitializer.class));context.addServletContainerInitializer(newServletContainerInitializerHolder(WebComponentExporterAwareValidator.class));context.addServletContainerInitializer(newServletContainerInitializerHolder(WebComponentConfigurationRegistryInitializer.class));

Each of these seven calls registers aServletContainerInitializer and at the same time names the classes for which it is responsible. These classes correspond to the@HandlesTypes that a servlet container would otherwise determine by scanning the classpath; since registration is done by hand here, they are passed explicitly. The first initialiser is the service lookup and must run first, as all the others build upon it. The second sets up the route registry and is given the three navigable classesMainView,WalkthroughView andMainLayout; only thus does the route registry find the two views and the shared layout. The remaining five set up the application shell, validate annotations, determine the error targets, and validate or register any web components.

Striking are the three classes loaded vialoadVaadinClass in the first call. These are internal, non-exported Vaadin classes that cannot be written directly as a class literal. The helper method therefore loads them by name and fails with a clear message should Vaadin’s internal structure ever change.

javaCopy

privatestaticClass<?>loadVaadinClass(Stringname){try{returnClass.forName(name,false,Thread.currentThread().getContextClassLoader());}catch(ClassNotFoundExceptione){thrownewIllegalStateException("Vaadin runtime class not found: "+name,e);}}

The fourth step completes the wiring and starts the server. Beforehand, Jakarta WebSocket support is configured, without which the server push over the WebSocket channel would not come about.

javaCopy

// Jakarta WebSocket support so @Push can use the websocket transport.JakartaWebSocketServletContainerInitializer.configure(context,null);server.setHandler(context);Runtime.getRuntime().addShutdownHook(newThread(this::safeStop,"ui-shutdown"));server.start();logger().info("Vaadin UI listening on http://localhost:{}/",port);CountDownLatchlatch=newCountDownLatch(1);Runtime.getRuntime().addShutdownHook(newThread(latch::countDown,"ui-latch"));latch.await();}

After the context has been set as the handler, a shutdown hook is installed that brings the server to an orderly halt on interruption. The actual start then reports the reachable address. Since the main thread would otherwise end and the virtual machine would terminate the application, aCountDownLatch keeps the thread open until a second shutdown hook releases it. The server thus runs until it is explicitly stopped.

There remains the helper method that provides the static resources — the very work that aWebAppContext would take on of its own accord.

javaCopy

privatestaticResourcemetaInfResources(ServletContextHandlercontext)throwsException{ClassLoadercl=Thread.currentThread().getContextClassLoader();ResourceFactoryfactory=ResourceFactory.of(context);// Servlet 3 convention: each JAR may carry static files under META-INF/resources/.// flow-push delivers vaadinPush-min.js under META-INF/resources/VAADIN/static/push/,// and Vaadin's prebuilt production bundle ships under// META-INF/resources/VAADIN/build/ in vaadin-prod-bundle.jar — both are// exposed by combining every classpath entry's META-INF/resources tree.List<Resource>resources=newArrayList<>();for(URLu:Collections.list(cl.getResources("META-INF/resources"))){resources.add(factory.newResource(u));}if(resources.isEmpty()){returnfactory.newResource(".");}returnresources.size()==1?resources.get(0):ResourceFactory.combine(resources);}

By the Servlet 3 convention, every archive on the classpath may carry static files underMETA-INF/resources. Vaadin makes use of this in several places, for instance for the push script and for the prebuilt production bundle. The method gathers all such directories from the classpath and combines them into a single virtual root, so that the server delivers them as one resource collection.

The entire sequence can be grasped at a glance.

With that, the framework-free start-up is complete. It consists of erecting the context, providing the static resources, registering the servlet, explicitly registering the seven initialisers, configuring the WebSocket, and the actual start. Each of these steps is visible and traceable in the source. What a starter conceals as a convenience lies open here — and this very openness is the reward of forgoing it. The price is a handful of additional lines; the return is a start-up that can be understood entirely with the platform’s own means, without the detour through a further layer of abstraction. It is on this foundation that the next chapter builds, turning to the construction of the main view itself.

3. Conducting Two Requests Side by Side

The persuasive force of the juxtaposition, of which the introductory chapter spoke, rests on two conditions. The first is simultaneity: the viewer should see both answers come into being at the very same moment. The second is equality of conditions: both answers must be given to the same question and under the same premises, so that the visible difference is attributable solely to the attachment of the server and not to some incidental unequal treatment in the construction. Neither condition is self-evident; both are worked into the source. This chapter shows how.

Equality of conditions begins with the layout of the view. For each of the two columns there is a field of the same kind; what exists on the left exists on the right in the same shape.

javaCopy

privatefinalTextAreaquestionInput=newTextArea();privatefinalCheckboxmcpToggle=newCheckbox("Enable MCP");privatefinalButtonsendButton=newButton("Ask");privatestaticfinalStringPLACEHOLDER_PLAIN="_Generic answers will appear here..._";privatestaticfinalStringPLACEHOLDER_MCP="_Answers using your pantry will appear here..._";privatefinalMarkdownleftBody=newMarkdown(PLACEHOLDER_PLAIN);privatefinalMarkdownrightBody=newMarkdown(PLACEHOLDER_MCP);privatefinalStringBuilderleftBuffer=newStringBuilder();privatefinalStringBuilderrightBuffer=newStringBuilder();privatefinalChatProgressViewleftProgress=newChatProgressView();privatefinalChatProgressViewrightProgress=newChatProgressView();

Each column is assigned its ownMarkdown component for the finished answer, its own buffer for the incoming text, and its own progress view. This paired layout is the structural basis of the symmetry; it ensures that the left and right columns are cut from the same cloth.

The symmetry shows itself more emphatically still in the fact that both columns issue from a single method. A boolean parameter decides whether the plain or the MCP-enabled variant arises.

javaCopy

privateDivbuildAnswerColumn(booleanmcp){Divcol=newDiv();col.addClassNames("recipe-answer",mcp?"recipe-answer--mcp":"recipe-answer--plain");Spanchip=newSpan();chip.addClassNames("recipe-chip",mcp?"recipe-chip--mcp":"recipe-chip--plain");if(mcp){chip.add(newIcon(VaadinIcon.MAGIC),newSpan("With MCP"));}else{chip.add(newIcon(VaadinIcon.COMMENT_O),newSpan("Without MCP"));}Divheader=newDiv(chip);header.addClassName("recipe-answer__header");Spansubtitle=newSpan(mcp?"Has access to your pantry & profile":"Generic recipe knowledge only");subtitle.addClassName("recipe-card__subtitle");ChatProgressViewprogress=mcp?rightProgress:leftProgress;Markdownbody=mcp?rightBody:leftBody;body.addClassName("recipe-answer__body");col.add(header,subtitle,progress,body);returncol;}

The two columns are produced in one place by two calls with the valuesfalse andtrue; the left, accordingly, is the plain one, the right the MCP-enabled one. Apart from the labelling, the colouring and the choice of the associated field pair, the construction is identical. Anyone searching the code for a difference between the columns finds it solely in that one boolean value — and this is precisely the assurance, visible in the source, that the juxtaposition is honest.

Simultaneity, in turn, arises on triggering via the button. The methodhandleSend prepares the interface and then sets the concurrent processing in motion.

javaCopy

privatevoidhandleSend(){Stringquestion=questionInput.getValue();if(question==null||question.isBlank())return;leftBuffer.setLength(0);rightBuffer.setLength(0);leftBody.setContent("");rightBody.setContent("");leftProgress.clear();rightProgress.clear();sendButton.setEnabled(false);UIui=UI.getCurrent();booleanwithMcp=mcpToggle.getValue();AtomicReference<Boolean>leftDone=newAtomicReference<>(Boolean.FALSE);AtomicReference<Boolean>rightDone=newAtomicReference<>(!withMcp);Thread.startVirtualThread(()->runPlain(ui,question,leftDone,rightDone));if(withMcp){Thread.startVirtualThread(()->runWithMcp(ui,question,leftDone,rightDone));}else{ui.access(()->rightBody.setContent("_(MCP disabled - check the box to enable.)_"));}}

After resetting both panels and disabling the button, two mutually independent virtual threads are started — one for the plain request, one for the MCP-enabled one. Virtual threads are the fitting means here: they are so lightweight that one may be created for each request without hesitation, and they may block while waiting for the answer to arrive without tying up a platform resource. The plain request is always made; the MCP-enabled one only when the toggle is active. Otherwise the right column receives a plain note.

The division of labour behind the two threads deserves a remark of its own. The plain request drives the methodrunPlain, the MCP-enabled one the methodrunWithMcp; the latter makes use of the sameWalkthroughEngine that also drives the step-by-step view of the second part — here merely as an automatic loop with no pauses between the phases. The actual protocol logic thus resides in exactly one place, and only the drive differs. The bodies of both methods contain the streaming callback that conveys the incoming text fragments into the interface; the following chapter is devoted to it, which is why it is omitted here.

There remains the joining of the two strands. Each thread notes at its end that it has finished, and then calls a plain coordination method.

javaCopy

privatevoidmaybeReenable(UIui,AtomicReference<Boolean>leftDone,AtomicReference<Boolean>rightDone){if(leftDone.get()&&rightDone.get()){ui.access(()->sendButton.setEnabled(true));}}

Only once both flags are set is the button re-enabled. Since the two flags are set and read in separate threads, they are realised asAtomicReference, whose value is safely visible across thread boundaries. Here the initial assignment mentioned earlier pays off: the right-hand flag is pre-set with!withMcp and therefore counts as done at once when the toggle is inactive. Thus, in plain operation, the single thread of the left column suffices to re-enable the button, whereas in MCP operation both threads are awaited. No separate synchronisation is needed; the logic carries itself.

The whole sequence can be read as a fork and a join.

Whereas the diagram shows the structure of the fork, the following figure makes the temporal side visible: both strands genuinely run within the same span of time, and the MCP-enabled lane lasts longer because it calls tools along the way.

With that, the two conditions on which the juxtaposition rests are met. The symmetry of construction ensures that both answers arise under equal premises; the concurrent conduct over two virtual threads ensures that they do so at the same moment. What has remained open so far is the question of how the text fragments arriving in the background threads find their way into the server-side interface at all. It is to this very question that the following chapter turns.

4. Channelling a Character Stream into the Component Tree

The preceding chapter left a question open: how the text fragments arriving in the two background threads find their way into the interface at all. Three obstacles stand in the way. First, Vaadin keeps the component tree on the server; the model’s answer, however, does not arise there but arrives over the network. Second, the component tree may not be altered from an arbitrary thread, but only within the locked context of the associated session. Third, the browser does not poll for updates of its own accord; without further intervention the picture would stand still until the user reloads the page. This chapter shows how these three obstacles are overcome together — along the path that a single fragment travels.

At the beginning of this path stands the stream itself. TheOllamaClient requests the model’s answer with streaming enabled and reads it as Server-Sent Events. The plain request of the left column runs through the methodchatPlain, which joins the system prompt and the question into a message list and then calls the inner streaming method. The third parameter is noteworthy: aConsumer<String> to which every incoming text fragment is handed.

javaCopy

publicvoidchatPlain(StringsystemPrompt,StringuserMessage,Consumer<String>textChunk,Consumer<ChatProgress>progress){Instantstart=Instant.now();progress.accept(ChatProgress.info("Sending request to Ollama","model: "+model));List<ObjectNode>messages=newArrayList<>();messages.add(message("system",systemPrompt));messages.add(message("user",userMessage));try{progress.accept(ChatProgress.stream("Streaming reply..."));StreamResultoutcome=streamOnce(messages,null,textChunk);progress.accept(ChatProgress.success("Reply complete ("+outcome.assistantText.length()+" chars)",Duration.between(start,Instant.now())));}catch(RuntimeExceptione){progress.accept(ChatProgress.error(e.getMessage()));throwe;}}

The method is given two callbacks: one for the text fragments, the other for structured progress events. The actual streamchatPlain leaves to the inner methodstreamOnce, to which it passes the text callback unchanged; thenull supplied in place of the tool list marks the plain request.

The actual decomposition of the stream takes place in this inner method. It reads the answer line by line; empty lines and lines not belonging to the stream are skipped, and the sentinel line[DONE] ends the loop.

javaCopy

try(BufferedReaderreader=newBufferedReader(newInputStreamReader(response.body(),StandardCharsets.UTF_8))){Stringline;while((line=reader.readLine())!=null){if(line.isEmpty())continue;if(!line.startsWith("data:"))continue;Stringdata=line.substring(5).trim();if("[DONE]".equals(data))break;JsonNodeevent;try{event=MAPPER.readTree(data);}catch(ExceptionparseError){logger().warn("Skipping malformed SSE chunk: {}",data);continue;}JsonNodechoice=event.path("choices").path(0);JsonNodedelta=choice.path("delta");if(delta.hasNonNull("content")){Stringpiece=delta.get("content").asText();if(!piece.isEmpty()){assistantText.append(piece);if(textChunk!=null)textChunk.accept(piece);}}if(delta.hasNonNull("tool_calls")){for(JsonNodetc:delta.get("tool_calls")){intidx=tc.path("index").asInt(0);ToolCallAccumulatoracc=calls.computeIfAbsent(idx,k->newToolCallAccumulator());if(tc.hasNonNull("id"))acc.id=tc.get("id").asText();JsonNodefn=tc.path("function");if(fn.hasNonNull("name"))acc.name=fn.get("name").asText();if(fn.hasNonNull("arguments")){acc.argumentsBuffer.append(fn.get("arguments").asText());}}}Stringfinish=choice.path("finish_reason").asText(null);if(finish!=null&&!finish.isBlank()){break;}}}

For the text path, only the middle section matters: if the delta carries content, that portion is appended to the gathered answer text and at the same time handed to the callback. In this way every fragment leaves the method at the very moment it arrives. The section that follows gathers the components of any tool calls; it is left undiscussed here and is the subject of the sixth chapter. The appearance of a finish reason ends the loop.

With that, the source is clarified: theConsumer<String> receives the fragment. Before it can appear in the browser, however, the first of the named obstacles must be taken — the browser must be allowed to be supplied unsolicited. This is what the annotation@Push does, which hangs not on an individual view but on the centralAppShell and therefore applies to the whole application.

javaCopy

packagecom.svenruppert.mcp.ui;importcom.vaadin.flow.component.page.AppShellConfigurator;importcom.vaadin.flow.component.page.Push;importcom.vaadin.flow.theme.Theme;importcom.vaadin.flow.theme.lumo.Lumo;@Push@Theme(value="recipe",variant=Lumo.LIGHT)publicclassAppShellimplementsAppShellConfigurator{}

The annotation permits the server to send changes to the browser of its own accord — over the WebSocket channel that was configured expressly in the second chapter. Because it sits on theAppShell, it applies to both views alike; the second annotation merely determines the appearance.

There remains the second obstacle: the change in the correct context. The receiving end in the main view is the methodrunPlain. It passeschatPlain a callback that processes every fragment by way ofUI.access.

javaCopy

privatevoidrunPlain(UIui,Stringquestion,AtomicReference<Boolean>leftDone,AtomicReference<Boolean>rightDone){try{services.ollama().chatPlain(Prompts.SYSTEM_PLAIN,question,chunk->ui.access(()->{leftBuffer.append(chunk);leftBody.setContent(leftBuffer.toString());}),ev->ui.access(()->leftProgress.append(ev)));}catch(Exceptione){logger().warn("Plain chat failed",e);ui.access(()->leftBody.setContent("**Error:** "+e.getMessage()));}finally{leftDone.set(Boolean.TRUE);maybeReenable(ui,leftDone,rightDone);}}

Here the threads come together. The reference to theUI was captured earlier in the triggering thread and handed along into the background thread. Every incoming fragment is not processed directly but wrapped in aUI.access call. This is precisely the key: altering the component tree from a foreign thread would be impermissible, since it would bypass the session’s lock and lead to race conditions.UI.access instead enqueues the change into the locked context of the session and, since@Push is active, at the same time sets its transmission to the browser in motion. Thus a single call overcomes the second and the third obstacle in one.

Within the callback, finally, the buffer pattern shows itself. Every fragment is appended to aStringBuilder, and the entire accumulated content is set as the new content of theMarkdown component. That the whole text is set anew on every fragment rather than appended to the existing content is deliberate: the approach is plain, self-contained, and matches the interface of the component, which takes a complete text. The progress callback proceeds in the same way. At the end the method notes in thefinally block that the left column is finished and calls the coordination method considered in the previous chapter; the error path sets an error message, likewise by way ofUI.access.

The whole path of a fragment can be read as a sequence of a few steps.

With that, the three obstacles named at the outset are taken together: the stream is decomposed in the client,@Push permits the unsolicited supply of the browser, andUI.access runs every fragment in the correct context and brings about its transmission. One detail remains conspicuous: on every fragment the entire accumulated text is set anew on theMarkdown component, so that the component displays an ever-growing, still-incomplete document. What the viewer perceives while the document is incomplete — and whether this is the right thing — is the question to which the following chapter turns.

5. Rendering the Stream as Markdown

The fourth chapter traced the path of a fragment into the component tree and, at the end, singled out one detail: on every fragment the entire accumulated text is set on theMarkdown component. What stood there as an incidental observation is the actual subject of this chapter. Where the previous chapter asked how a fragment reaches the interface, this one asks what the interface visibly does with it. The heart of the callback reads:

javaCopy

chunk->ui.access(()->{leftBuffer.append(chunk);leftBody.setContent(leftBuffer.toString());}),

The fieldleftBody is acom.vaadin.flow.component.markdown.Markdown, not a plain text component. ItssetContent call replaces the previous content entirely; the component discards its existing rendering and re-renders the whole accumulated text. Since this happens on every fragment, the answer appears to the viewer not as growing raw text but as a continuously rendered Markdown document.

For the viewer, this means that the answer builds itself up as a structured document. A heading appears as a heading as soon as its line is complete; a list appears as a list as soon as its entries arrive; an emphasis takes effect as soon as it is closed. The document thus comes into being not as a draft to be put into shape at the end, but already in its final form, step by step.

This approach has a price. As long as a piece of markup is still incomplete — an emphasis opened but not yet closed, a list begun but not yet finished, a code block that has arrived only halfway — the component renders that intermediate state just as it currently stands. If the missing part arrives shortly afterwards, the affected section rearranges itself. The viewer perceives this as a brief reordering that resolves itself as the remainder arrives.

The main view accepts this occasional reordering deliberately, and the reason lies in its purpose. It is the comparison view, and its entire persuasive force rests, as the introductory chapter set out, on the immediacy of the juxtaposition. The viewer should see both answers come into being vividly and at the very same moment; the progressive rendering serves precisely this vividness. The answers are, moreover, manageable recipe texts in which the reordering is rare and slight. The small price thus stands in a reasonable proportion to the impression of simultaneity that is gained.

It should not be passed over that the same matter can be solved differently — and is solved differently in the same project. The step-by-step view takes the opposite path: it shows the stream first as raw text and renders it as Markdown only after it has completed.

javaCopy

if(query.toolCalls().isEmpty()){result.remove(streamDiv);Markdownrendered=newMarkdown(streamedText.isBlank()?"_(no text)_":streamedText);rendered.addClassName("recipe-walkthrough__rendered");result.add(rendered);

During the stream the text grows there in a plain area; only after completion is that area removed and replaced by a freshly createdMarkdown component. The corresponding phase description states it expressly: “Streaming is complete and the text is rendered as Markdown.” The reason for this different choice lies in the different purpose: a teaching view prefers a calm, stable picture of each phase that the viewer can study at his own pace, without the rendered output rearranging itself beneath his gaze. The closer examination of this counter-design belongs in the second part; here the note suffices that these are two well-founded answers to the same question.

The two strategies can be set side by side in brief.

Both paths follow the same principle, that an interface should honestly reflect the state of its content — they merely draw different conclusions from it. The comparison view shows the document as it forms, because it cares about the simultaneity of its emergence. The teaching view shows each phase as it stands once complete, because it cares about the calm of study. What neither view has so far disclosed is the traffic that makes the right-hand answer possible in the first place — the calls to the tools and their results. It is to this very traffic, and to making it visible, that the following chapter turns.

6. Making the Protocol Visible

The previous chapter closed with an observation: what neither view had so far disclosed is the traffic that makes the right-hand answer possible in the first place. This traffic is precisely what MCP achieves — and at the same time what remains hidden in normal operation. The fetching of the tool list, the individual tool calls, their results and the repeated model runs all happen behind the scenes. Without making them visible, the right column would be a mere black box that delivers a better answer but does not show why. A comparison view meant to instruct cannot leave it at that. The main view therefore makes the traffic legible — by way of a vertical timeline that runs alongside each answer.

At the beginning stands a plain event model. Every step of the processing is recorded as aChatProgress, arecord with a small, closed enumeration of event kinds and a factory method for each.

javaCopy

publicrecordChatProgress(Kindkind,Stringlabel,Stringdetail,Instantat){publicenumKind{INFO,STREAM,TOOL_CALL,TOOL_RESULT,SUCCESS,ERROR}publicstaticChatProgressinfo(Stringlabel){returnnewChatProgress(Kind.INFO,label,null,Instant.now());}publicstaticChatProgressinfo(Stringlabel,Stringdetail){returnnewChatProgress(Kind.INFO,label,detail,Instant.now());}publicstaticChatProgressstream(Stringlabel){returnnewChatProgress(Kind.STREAM,label,null,Instant.now());}publicstaticChatProgresstoolCall(Stringlabel,Stringdetail){returnnewChatProgress(Kind.TOOL_CALL,label,detail,Instant.now());}publicstaticChatProgresstoolResult(Stringlabel,Stringdetail){returnnewChatProgress(Kind.TOOL_RESULT,label,detail,Instant.now());}publicstaticChatProgresssuccess(Stringlabel,Durationelapsed){Stringd="%.1fs".formatted(elapsed.toMillis()/1000.0);returnnewChatProgress(Kind.SUCCESS,label,d,Instant.now());}publicstaticChatProgresserror(Stringmessage){returnnewChatProgress(Kind.ERROR,"Error",message,Instant.now());}}

Six event kinds suffice to describe the whole course of an MCP run: a general notice, the beginning of a stream, a tool call, a tool result, the success and the error. Every event carries a concise label, an optional detail text and the moment of its creation. The detail text is the part decisive for the protocol, for it holds the arguments of a call and the returned result.

The display of these events is taken on by theChatProgressView, a vertical timeline. Its central method appends a row for each event.

javaCopy

publicvoidappend(ChatProgressevent){Divrow=newDiv();row.addClassName("recipe-progress__row");row.addClassName("recipe-progress__row--"+event.kind().name().toLowerCase());Iconicon=newIcon(iconFor(event.kind()));icon.addClassName("recipe-progress__icon");Spantime=newSpan(TIME_FMT.format(LocalTime.ofInstant(event.at(),ZoneId.systemDefault())));time.addClassName("recipe-progress__time");Spanlabel=newSpan(event.label());label.addClassName("recipe-progress__label");Divhead=newDiv(icon,time,label);head.addClassName("recipe-progress__head");row.add(head);if(event.detail()!=null&&!event.detail().isBlank()){Predetail=newPre(event.detail());detail.addClassName("recipe-progress__detail");row.add(detail);}add(row);getElement().executeJs("this.scrollTop = this.scrollHeight");}privatestaticVaadinIconiconFor(ChatProgress.Kindk){returnswitch(k){caseINFO->VaadinIcon.INFO_CIRCLE_O;caseSTREAM->VaadinIcon.PAPERPLANE;caseTOOL_CALL->VaadinIcon.COG;caseTOOL_RESULT->VaadinIcon.CHECK_CIRCLE_O;caseSUCCESS->VaadinIcon.CHECK_CIRCLE;caseERROR->VaadinIcon.WARNING;};}

Each row consists of a head — an icon suited to the event kind, the time and the label — and, if a detail text is present, aPre block set beneath it. This veryPre block carries the content in a monospaced and thus legibly arranged form: here the arguments of a call and the result JSON appear in a shape that the viewer can follow character by character. The event kind also determines a style class of its own, so that calls, results and errors are distinguished by colour as well. Finally, the method scrolls to the most recent entry by way of a small JavaScript call, so that the bar always shows the current happening.

The events are created where the traffic actually takes place — in the methodrunWithMcp, which drives the MCP-enabled request.

javaCopy

privatevoidrunWithMcp(UIui,Stringquestion,AtomicReference<Boolean>leftDone,AtomicReference<Boolean>rightDone){WalkthroughEngineengine=services.engine();Instantstart=Instant.now();try{WalkthroughStatestate=engine.startRun(Prompts.SYSTEM_MCP,question);ui.access(()->rightProgress.append(ChatProgress.info("Fetching tool list from MCP server")));WalkthroughPhase.ToolCatalogcatalog=engine.fetchToolCatalogue(state);ui.access(()->rightProgress.append(ChatProgress.info("Loaded "+catalog.toolNames().size()+" tools from MCP server",String.join(", ",catalog.toolNames()))));for(intsafety=0;safety<WalkthroughEngine.MAX_ITERATIONS;safety++){finalintiterNumber=state.iteration()+1;ui.access(()->rightProgress.append(ChatProgress.stream("Iteration "+iterNumber+": streaming reply...")));WalkthroughPhase.ModelQueryquery=engine.runModelQuery(state,chunk->ui.access(()->{rightBuffer.append(chunk);rightBody.setContent(rightBuffer.toString());}));if(query.toolCalls().isEmpty()){Durationelapsed=Duration.between(start,Instant.now());intit=state.iteration();ui.access(()->rightProgress.append(ChatProgress.success("Reply complete after "+it+" iteration"+(it==1?"":"s"),elapsed)));return;}for(WalkthroughPhase.PendingToolCallpc:query.toolCalls()){ui.access(()->rightProgress.append(ChatProgress.toolCall("Call "+pc.name()+"(...)",pc.argumentsJson())));}WalkthroughPhase.ToolExecutionexec=engine.executeTools(state,query);for(WalkthroughPhase.ToolOutcomeoc:exec.outcomes()){ChatProgressevent=oc.error()?ChatProgress.error(oc.name()+": "+oc.resultText()):ChatProgress.toolResult("Result from "+oc.name(),oc.resultText());ui.access(()->rightProgress.append(event));}}ui.access(()->rightProgress.append(ChatProgress.info("Reached max tool-call iteration limit. Stopping.")));ui.access(()->rightBuffer.append("\n\n[Reached the maximum tool-call iteration limit. Stopping here.]"));ui.access(()->rightBody.setContent(rightBuffer.toString()));}catch(Exceptione){logger().warn("MCP chat failed",e);ui.access(()->rightProgress.append(ChatProgress.error(e.getMessage())));ui.access(()->rightBody.setContent("**Error:** "+e.getMessage()));}finally{rightDone.set(Boolean.TRUE);maybeReenable(ui,leftDone,rightDone);ui.access(sidebar::refreshGrid);ui.access(sidebar::refreshProfileForm);}}

The method drives a loop whose inner steps — the fetching of the catalogue, the model run, the tool execution — are performed by theWalkthroughEngine and are examined more closely only in the second part. For this chapter, all that matters is what happens between those steps: at every significant point aChatProgress event is created and appended to the timeline by way ofUI.access. First an event reports the fetching of the tool list, another the number and the names of the loaded tools. In each run an event announces the beginning of the stream. If the model requests no further tools, a success event reports the completion together with the elapsed time. Otherwise the method creates, for each requested call, a call event whose detail text carries the arguments, and after the execution, for each result, a result event with the returned text — or, in the error case, an error event. Thus, alongside the answer, a running, timestamped record of the whole traffic comes into being.

The sequence of these events can be read as the timeline of a run.

This is how the timeline looks during a run:

With that, the traffic is no longer hidden. Alongside the right-hand answer the viewer sees which tools the model requests, with which arguments it calls them and which results flow back — and he sees it at the very moment it happens. It should be noted that the step-by-step view presents the same traffic more elaborately still: with one card per phase and with concurrently executed calls as side-by-side lanes under a parallel marker. This richer, paused presentation is the subject of the second part; the main view contents itself with the compact, running timeline.

One detail of the method already points ahead: in thefinally block the sidebar is refreshed after every run. Behind this lies the question of how the display of the pantry and the profile agrees with the actual state that the tools may have changed. It is to this very question of state consistency that the following chapter turns.

7. Keeping the State Consistent

The previous chapter ended with a detail that pointed ahead: in thefinally block ofrunWithMcp the sidebar is refreshed after every run. Behind this lies a consistency problem to which this chapter is devoted. For two writers act upon the same business state — the pantry and the dietary profile. The operator changes it by hand through the maintenance sidebar; the model changes it indirectly through the MCP tools, for instance by striking out a consumed ingredient or adjusting the profile. A display that is to do justice to both writers must therefore be conducted with care.

The first decision concerns the path the sidebar takes when writing. It writes directly against the REST server and deliberately bypasses the MCP server. The reason lies in its role: the sidebar is the operator’s instrument, not part of the model dialogue. The REST server holds the authoritative state; the MCP server accesses this very state only by reading and writing through its tools. It would be mistaken to route an operator’s action through the model’s tool channel. The pantry write shows this.

javaCopy

privatevoidsaveItem(){try{Stringname=nameField.getValue();if(name==null||name.isBlank()){Notification.show("Name is required",2500,Notification.Position.MIDDLE).addThemeVariants(NotificationVariant.LUMO_ERROR);return;}Doubleqty=quantityField.getValue();if(qty==null)qty=0.0;Stringunit=blankToDefault(unitField.getValue(),"piece");Stringcategory=blankToDefault(categoryField.getValue(),"Pantry");Optional<LocalDate>bestBefore=Optional.ofNullable(bestBeforeField.getValue());PantryItemitem=newPantryItem(name,qty,unit,bestBefore,category);if(nameField.isReadOnly()){pantryClient.replace(item);Notification.show("Updated "+name,1500,Notification.Position.BOTTOM_START);}else{pantryClient.create(item);Notification.show("Added "+name,1500,Notification.Position.BOTTOM_START);}clearForm();refreshGrid();}catch(Exceptione){Notification.show(e.getMessage(),3000,Notification.Position.MIDDLE).addThemeVariants(NotificationVariant.LUMO_ERROR);}}

After a brief check of the name, aPantryItem is assembled from the fields. Whether it is created or replaced is decided by the state of the name field: if it is read-only, an existing entry has been loaded for editing, and the callreplace replaces it; otherwisecreate adds a new one. What is decisive is the turn at the end of the successful branch: the form is cleared and the grid is reloaded. This very turn recurs on deletion.

javaCopy

privatevoiddeleteSelected(){Optional<PantryItem>sel=grid.getSelectionModel().getFirstSelectedItem();if(sel.isEmpty()){Notification.show("Select an item first",1500,Notification.Position.BOTTOM_START);return;}try{pantryClient.delete(sel.get().name());Notification.show("Removed "+sel.get().name(),1500,Notification.Position.BOTTOM_START);clearForm();refreshGrid();}catch(Exceptione){Notification.show(e.getMessage(),3000,Notification.Position.MIDDLE).addThemeVariants(NotificationVariant.LUMO_ERROR);}}

Here too the grid is reloaded after the write. With that, the actual consistency principle shows itself, which resides in the methodrefreshGrid.

javaCopy

publicvoidrefreshGrid(){try{grid.setItems(pantryClient.list());}catch(Exceptione){logger().warn("Could not refresh pantry grid: {}",e.getMessage());}}

The grid is not updated locally — the entry just created is not, say, added to the existing display — but refilled entirely from the server. After every change the display thus reflects the authoritative state and never a locally maintained, possibly diverging view. This principle is plain but consequential: as long as every change closes with a reload, the display cannot drift apart.

The writes themselves are carried out by a thin REST client using the platform’s own means. The replacing method may stand for them.

javaCopy

publicPantryItemreplace(PantryItemitem){try{Stringbody=MAPPER.writeValueAsString(item);HttpResponse<String>resp=http.send(HttpRequest.newBuilder(URI.create(baseUrl+"/pantry/"+encode(item.name()))).timeout(Duration.ofSeconds(5)).header("Content-Type","application/json").PUT(HttpRequest.BodyPublishers.ofString(body,StandardCharsets.UTF_8)).build(),HttpResponse.BodyHandlers.ofString(StandardCharsets.UTF_8));ensureSuccess(resp,"replace pantry item");returnMAPPER.readValue(resp.body(),PantryItem.class);}catch(RuntimeExceptionre){throwre;}catch(Exceptione){thrownewRuntimeException("Failed to replace pantry item "+item.name(),e);}}

AnHttpRequest with the methodPUT carries the entry, cast as JSON, to the address of the REST server; a check of the status code ensures success. Creating and deleting proceed withPOST andDELETE respectively, after the same pattern. No additional dependency is needed for this; the platform’sHttpClient suffices.

The profile section of the sidebar is built after the same pattern. Its write transmits the changed profile through the associated REST client, and its refresh likewise reloads the profile from the server into the form. What holds for the pantry therefore holds for the dietary profile as well: write, then reload.

There remains the opposite direction. The writes considered so far proceed from the operator. The second writer is the model, which changes the same state through the MCP tools. So that its changes too become visible, the main view refreshes the sidebar after every MCP run — those very two calls in thefinally block that the previous chapter announced: the reloading of the grid and the reloading of the profile form. Thus the circle closes in both directions. If the operator changes the data, the next MCP-enabled answer reflects the change, because the model re-fetches the state through the tools on every request. If the model changes the data, the sidebar reflects it, because it reloads after the run.

This very closed circle is the actual demonstration value of the sidebar. The operator can show, without a restart, how a change of data affects the next answer — for instance by switching the diet, adding an intolerance or striking out an ingredient — and he can at the same time observe how a change carried out by the model appears at once in the sidebar. The rigour with which everything is reloaded after every change is the condition for this demonstration to succeed reliably. With that, the constituents of the main view have been considered in full; the following and final chapter of this part draws the sum.

8. Conclusion

The introduction to this part presented the main view as a proof: the single image of two answers set side by side replaces the assertion about the value of MCP with immediate perception. The guiding observation was that the persuasive force of this juxtaposition rests less on the logic of the answers than on the discipline of their presentation. The tour through the concrete hurdles has made good on that observation.

Six hurdles had to be taken. Running without a starter laid the foundation by wiring the start-up by hand and thereby disclosing what a starter otherwise conceals. Conducting two requests concurrently created the simultaneity and, through the symmetric construction of both columns, the equality of conditions. Channelling a character-by-character stream into the component tree overcame the separation between the background thread and the server-side interface, by having@Push andUI.access work together. Rendering the stream as Markdown let the answer come into being as a structured document before the viewer’s eyes. Making the protocol visible turned the hidden tool traffic into a legible, running timeline. And keeping the state consistent ensured that, after every change, the display reflects the authoritative state, whether the operator or the model has changed it.

However different these hurdles are, a common thought connects them. An interface for model-driven tool use must not merely display results; it must keep the process of their emergence comprehensible. Each of the decisions discussed serves precisely this comprehensibility: the simultaneity, so that the difference between the answers becomes undeniable; the progressive rendering, so that the answer comes into being vividly; the timeline, so that the traffic does not remain hidden; the reloading, so that the display does not deceive. It is this very comprehensibility that turns a mere display into a proof.

It should not be passed over that, for all its disclosure, the main view conceals something. It sets the result of two requests side by side, yet it lets the mechanism that brings forth the right-hand answer vanish into the automatic run. The running timeline hints at it but does not halt it. It is precisely here that the second part begins. The step-by-step view reverses the relationship: it halts the pipeline, makes each phase individually triggerable, and turns the otherwise fleeting course into a legible, temporally ordered object. Where this part showed that the attached server makes a difference, the next will show how that difference comes about — the passage from the what to the how.

With that, the first part is concluded. The main view is no mere accessory to the MCP server, but the means by which its value becomes perceptible — and it is so precisely because it makes the discipline of its presentation its business.

]]>JavaVaadinMCP