MCP · djuleayo

MCP · djuleayo https://316c0611.personalpage-ahl.pages.dev/tags/mcp/ Hugo en Dynamically Generated Languages vs MCP Servers https://316c0611.personalpage-ahl.pages.dev/posts/dynamical-languages/ https://316c0611.personalpage-ahl.pages.dev/posts/dynamical-languages/ Sun, 18 Jan 2026 17:10:43 +0200 <h1 id="dynamically-generated-languages-solve-the-same-class-of-problems-as-mcp-servers--and-do-it-better"> Dynamically Generated Languages Solve the Same Class of Problems as MCP Servers — and Do It Better <a class="heading-link" href="#dynamically-generated-languages-solve-the-same-class-of-problems-as-mcp-servers--and-do-it-better"> Link to heading </a> </h1> After battle-testing these ideas in practice, here is my conclusion: Centralized interaction and intent architectures are inevitable. The only real question is whether we build them as formal systems or probabilistic agents. <hr> <h2 id="from-clicking-and-scrolling-to-invoking-capabilities"> From Clicking and Scrolling to Invoking Capabilities <a class="heading-link" href="#from-clicking-and-scrolling-to-invoking-capabilities"> Link to heading </a> </h2> User interaction is moving away from clicking and scrolling and toward invoking capabilities directly, most notably via voice. This shift is powerful: <ul> <li>If you can name a capability, you can invoke it</li> <li>Interaction becomes direct</li> <li>UX complexity drops dramatically</li> </ul> From a UX-complexity standpoint, this is a clear win. However, this change forces a fundamental architectural shift compared to traditional frontend setups. <hr> <h2 id="react-and-the-problem-of-distributed-capabilities"> React and the Problem of Distributed Capabilities <a class="heading-link" href="#react-and-the-problem-of-distributed-capabilities"> Link to heading </a> </h2> Consider a typical React application. In React: <ul> <li>Capabilities are exposed through components</li> <li>Components expose behavior via props and callbacks</li> <li>Capabilities are therefore distributed by construction</li> </ul> There is no centralized place where “what the system can do” exists. Trying to centralize this in React quickly reveals deep friction: <ul> <li>Hooks produce unstable references across renders</li> <li>Central registries must constantly re-register handlers</li> <li>Context-based solutions become brittle and stateful</li> <li>Unsubscribing DOM listeners requires the exact same function reference</li> <li>That reference is often no longer available or stable</li> </ul> Yes, you can build a capability registry on top of React. But it is: <ul> <li>Clunky</li> <li>Hard to reason about</li> <li>Tightly coupled to rendering lifecycle</li> <li>Architecturally inverted</li> </ul> All of this is a strong signal: centralized capability invocation does not belong inside the UI layer. <hr> <h2 id="centralization-is-not-optional"> Centralization Is Not Optional <a class="heading-link" href="#centralization-is-not-optional"> Link to heading </a> </h2> Now compare this with a system like the Visual Studio Code command palette. VS Code exposes: <ul> <li>A centralized</li> <li>Runtime-configurable</li> <li>Discoverable</li> <li>Uniform command surface</li> </ul> Once a command is registered: <ul> <li>It does not matter where it lives</li> <li>It does not matter which UI triggered it</li> <li>It can be invoked uniformly</li> </ul> This is not an accident. It is a capability-first architecture. <hr> <h2 id="the-natural-conclusion-a-decoupled-capability-layer"> The Natural Conclusion: A Decoupled Capability Layer <a class="heading-link" href="#the-natural-conclusion-a-decoupled-capability-layer"> Link to heading </a> </h2> What naturally follows is a module that: <ul> <li>Is decoupled from the frontend</li> <li>Has no dependency on UI frameworks</li> <li>Accepts voice or textual input</li> <li>Emits discrete, authorized commands</li> </ul> At first glance, this smells like parsing. And that is exactly what it is — with one important caveat. <hr> <h2 id="this-is-parsing--not-ai"> This Is Parsing — Not AI <a class="heading-link" href="#this-is-parsing--not-ai"> Link to heading </a> </h2> Traditional parsing assumes: <ul> <li>Full input available upfront</li> <li>A lexing phase</li> <li>A parsing phase</li> <li>A final AST</li> </ul> User interaction does not work this way. For voice and interactive input we need: <ul> <li>Incremental parsing</li> <li>Partial feedback</li> <li>Real-time guidance</li> <li>Asynchronous evaluation</li> </ul> This is not AI. This is asynchronous parsing. That distinction matters. <hr> <h2 id="mcp-servers-and-the-core-problem"> MCP Servers and the Core Problem <a class="heading-link" href="#mcp-servers-and-the-core-problem"> Link to heading </a> </h2> MCP servers attempt to solve a similar problem: <ul> <li>Centralized capability invocation</li> <li>Access via natural language</li> <li>Location-agnostic execution</li> </ul> In practice: <ul> <li>Once a capability is integrated, its origin no longer matters</li> <li>If you can name it, you can invoke it</li> </ul> On the surface, this sounds ideal. It is not. <hr> <h2 id="why-informal-invocation-is-dangerous"> Why Informal Invocation Is Dangerous <a class="heading-link" href="#why-informal-invocation-is-dangerous"> Link to heading </a> </h2> MCP-style systems rely on: <ul> <li>NLP → mapping informal language to formal side effects</li> <li>Agents → which can and do hallucinate</li> </ul> This creates a fundamental mismatch: <ul> <li>Informal input</li> <li>Formal consequences</li> </ul> The moment real side effects exist, you must introduce: <ul> <li>Authorization</li> <li>Capability scoping</li> <li>Denial rules</li> <li>Auditability</li> </ul> At that point, you are already rebuilding a formal system. <hr> <h2 id="languages-are-formal-systems"> Languages Are Formal Systems <a class="heading-link" href="#languages-are-formal-systems"> Link to heading </a> </h2> Languages: <ul> <li>Are minimal</li> <li>Are precise</li> <li>Can be syntactically close to natural language</li> <li>Support deterministic navigation</li> <li>Enable runtime introspection (autocomplete, discovery)</li> </ul> Most importantly: Languages allow relational identification. Objects are identified not by name alone, but by their position in a capability topology. This is strictly stronger than nominal invocation. <hr> <h2 id="relational-navigation-beats-nominal-invocation"> Relational Navigation Beats Nominal Invocation <a class="heading-link" href="#relational-navigation-beats-nominal-invocation"> Link to heading </a> </h2> LLMs are good at resolving names. They are bad at: <ul> <li>Systematic search</li> <li>Relational exploration</li> <li>Topological disambiguation</li> </ul> A formal language enables: <ul> <li>Search through capability graphs</li> <li>Context-aware narrowing</li> <li>Progressive discovery</li> <li>Authorization by construction</li> </ul> This is not “autocomplete”. This is relational observation over a formal structure. <hr> <h2 id="the-implementation-is-already-known"> The Implementation Is Already Known <a class="heading-link" href="#the-implementation-is-already-known"> Link to heading </a> </h2> Asynchronous parsing is not new. Generators: <ul> <li>Exist in JavaScript for over a decade</li> <li>Are foundational in operating systems</li> <li>Are widely used in parsers and schedulers</li> </ul> They are exactly the right abstraction: <ul> <li>Incremental</li> <li>Stateful</li> <li>Deterministic</li> <li>Interruptible</li> </ul> Nothing exotic is required. <hr> <h2 id="the-critical-difference"> The Critical Difference <a class="heading-link" href="#the-critical-difference"> Link to heading </a> </h2> The most important outcome of such a system is this: It can correctly deny you access. This places it in a completely different category than LLM-driven systems. LLMs aim to be helpful. Formal systems aim to be correct. When invoking real capabilities, correctness wins. <hr> <h2 id="closing"> Closing <a class="heading-link" href="#closing"> Link to heading </a> </h2> Dynamically generated languages and centralized capability graphs solve the same class of problems as MCP servers. They do so: <ul> <li>Deterministically</li> <li>Safely</li> <li>Transparently</li> <li>With better UX</li> <li>And with lower long-term complexity</li> </ul> This is not the future of “AI interfaces”. This is the future of intent architecture. <h1 id="dynamically-generated-languages-solve-the-same-class-of-problems-as-mcp-servers--and-do-it-better"> Dynamically Generated Languages Solve the Same Class of Problems as MCP Servers — and Do It Better <a class="heading-link" href="#dynamically-generated-languages-solve-the-same-class-of-problems-as-mcp-servers--and-do-it-better"> Link to heading </a> </h1> After battle-testing these ideas in practice, here is my conclusion: Centralized interaction and intent architectures are inevitable. The only real question is whether we build them as formal systems or probabilistic agents. <hr> <h2 id="from-clicking-and-scrolling-to-invoking-capabilities"> From Clicking and Scrolling to Invoking Capabilities <a class="heading-link" href="#from-clicking-and-scrolling-to-invoking-capabilities"> Link to heading </a> </h2> User interaction is moving away from clicking and scrolling and toward invoking capabilities directly, most notably via voice. This shift is powerful: <ul> <li>If you can name a capability, you can invoke it</li> <li>Interaction becomes direct</li> <li>UX complexity drops dramatically</li> </ul> From a UX-complexity standpoint, this is a clear win. However, this change forces a fundamental architectural shift compared to traditional frontend setups. <hr> <h2 id="react-and-the-problem-of-distributed-capabilities"> React and the Problem of Distributed Capabilities <a class="heading-link" href="#react-and-the-problem-of-distributed-capabilities"> Link to heading </a> </h2> Consider a typical React application. In React: <ul> <li>Capabilities are exposed through components</li> <li>Components expose behavior via props and callbacks</li> <li>Capabilities are therefore distributed by construction</li> </ul> There is no centralized place where “what the system can do” exists. Trying to centralize this in React quickly reveals deep friction: <ul> <li>Hooks produce unstable references across renders</li> <li>Central registries must constantly re-register handlers</li> <li>Context-based solutions become brittle and stateful</li> <li>Unsubscribing DOM listeners requires the exact same function reference</li> <li>That reference is often no longer available or stable</li> </ul> Yes, you can build a capability registry on top of React. But it is: <ul> <li>Clunky</li> <li>Hard to reason about</li> <li>Tightly coupled to rendering lifecycle</li> <li>Architecturally inverted</li> </ul> All of this is a strong signal: centralized capability invocation does not belong inside the UI layer. <hr> <h2 id="centralization-is-not-optional"> Centralization Is Not Optional <a class="heading-link" href="#centralization-is-not-optional"> Link to heading </a> </h2> Now compare this with a system like the Visual Studio Code command palette. VS Code exposes: <ul> <li>A centralized</li> <li>Runtime-configurable</li> <li>Discoverable</li> <li>Uniform command surface</li> </ul> Once a command is registered: <ul> <li>It does not matter where it lives</li> <li>It does not matter which UI triggered it</li> <li>It can be invoked uniformly</li> </ul> This is not an accident. It is a capability-first architecture. <hr> <h2 id="the-natural-conclusion-a-decoupled-capability-layer"> The Natural Conclusion: A Decoupled Capability Layer <a class="heading-link" href="#the-natural-conclusion-a-decoupled-capability-layer"> Link to heading </a> </h2> What naturally follows is a module that: <ul> <li>Is decoupled from the frontend</li> <li>Has no dependency on UI frameworks</li> <li>Accepts voice or textual input</li> <li>Emits discrete, authorized commands</li> </ul> At first glance, this smells like parsing. And that is exactly what it is — with one important caveat. <hr> <h2 id="this-is-parsing--not-ai"> This Is Parsing — Not AI <a class="heading-link" href="#this-is-parsing--not-ai"> Link to heading </a> </h2> Traditional parsing assumes: <ul> <li>Full input available upfront</li> <li>A lexing phase</li> <li>A parsing phase</li> <li>A final AST</li> </ul> User interaction does not work this way. For voice and interactive input we need: <ul> <li>Incremental parsing</li> <li>Partial feedback</li> <li>Real-time guidance</li> <li>Asynchronous evaluation</li> </ul> This is not AI. This is asynchronous parsing. That distinction matters. <hr> <h2 id="mcp-servers-and-the-core-problem"> MCP Servers and the Core Problem <a class="heading-link" href="#mcp-servers-and-the-core-problem"> Link to heading </a> </h2> MCP servers attempt to solve a similar problem: <ul> <li>Centralized capability invocation</li> <li>Access via natural language</li> <li>Location-agnostic execution</li> </ul> In practice: <ul> <li>Once a capability is integrated, its origin no longer matters</li> <li>If you can name it, you can invoke it</li> </ul> On the surface, this sounds ideal. It is not. <hr> <h2 id="why-informal-invocation-is-dangerous"> Why Informal Invocation Is Dangerous <a class="heading-link" href="#why-informal-invocation-is-dangerous"> Link to heading </a> </h2> MCP-style systems rely on: <ul> <li>NLP → mapping informal language to formal side effects</li> <li>Agents → which can and do hallucinate</li> </ul> This creates a fundamental mismatch: <ul> <li>Informal input</li> <li>Formal consequences</li> </ul> The moment real side effects exist, you must introduce: <ul> <li>Authorization</li> <li>Capability scoping</li> <li>Denial rules</li> <li>Auditability</li> </ul> At that point, you are already rebuilding a formal system. <hr> <h2 id="languages-are-formal-systems"> Languages Are Formal Systems <a class="heading-link" href="#languages-are-formal-systems"> Link to heading </a> </h2> Languages: <ul> <li>Are minimal</li> <li>Are precise</li> <li>Can be syntactically close to natural language</li> <li>Support deterministic navigation</li> <li>Enable runtime introspection (autocomplete, discovery)</li> </ul> Most importantly: Languages allow relational identification. Objects are identified not by name alone, but by their position in a capability topology. This is strictly stronger than nominal invocation. <hr> <h2 id="relational-navigation-beats-nominal-invocation"> Relational Navigation Beats Nominal Invocation <a class="heading-link" href="#relational-navigation-beats-nominal-invocation"> Link to heading </a> </h2> LLMs are good at resolving names. They are bad at: <ul> <li>Systematic search</li> <li>Relational exploration</li> <li>Topological disambiguation</li> </ul> A formal language enables: <ul> <li>Search through capability graphs</li> <li>Context-aware narrowing</li> <li>Progressive discovery</li> <li>Authorization by construction</li> </ul> This is not “autocomplete”. This is relational observation over a formal structure. <hr> <h2 id="the-implementation-is-already-known"> The Implementation Is Already Known <a class="heading-link" href="#the-implementation-is-already-known"> Link to heading </a> </h2> Asynchronous parsing is not new. Generators: <ul> <li>Exist in JavaScript for over a decade</li> <li>Are foundational in operating systems</li> <li>Are widely used in parsers and schedulers</li> </ul> They are exactly the right abstraction: <ul> <li>Incremental</li> <li>Stateful</li> <li>Deterministic</li> <li>Interruptible</li> </ul> Nothing exotic is required. <hr> <h2 id="the-critical-difference"> The Critical Difference <a class="heading-link" href="#the-critical-difference"> Link to heading </a> </h2> The most important outcome of such a system is this: It can correctly deny you access. This places it in a completely different category than LLM-driven systems. LLMs aim to be helpful. Formal systems aim to be correct. When invoking real capabilities, correctness wins. <hr> <h2 id="closing"> Closing <a class="heading-link" href="#closing"> Link to heading </a> </h2> Dynamically generated languages and centralized capability graphs solve the same class of problems as MCP servers. They do so: <ul> <li>Deterministically</li> <li>Safely</li> <li>Transparently</li> <li>With better UX</li> <li>And with lower long-term complexity</li> </ul> This is not the future of “AI interfaces”. This is the future of intent architecture.