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.

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.

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.

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.

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