Debasish Ghosh debasishg

A study on how the Model Context Protocol (MCP) compares to traditional control plane architectures for orchestrating agentic applications. It contains the technical differences, expert and community opinions, and examines any evidence of real-world adoption or use cases for both approaches.

Comparison of Model Context Protocol (MCP) and Traditional Control Planes for Agentic Applications

Introduction

The Model Context Protocol (MCP) is a recently proposed open standard (originating from Anthropic) that defines how AI models (especially LLM-based agents) connect to external tools and data sources in a consistent way. By contrast, traditional “control plane” architectures in agentic AI refer to custom or framework-based orchestrators that manage how one or multiple AI agents invoke tools, coordinate tasks, and enforce policies. This report compares MCP with traditional control-plane designs for orchestrating agentic applications, focusing on technical differences in architecture and communicat

Here’s a reference end-to-end architecture for giving LLMs seamless, MCP-powered access to ClickHouse data and rendering results in a rich web UI.

1. High-level Components

ClickHouse Cluster Your OLAP datastore, hosting raw event or business data.
MCP Server (“ClickHouse Tool”)

Performance Engineering, Hardware and cache awareness with algorithm and data structures

Parallel Computing Course - Stanford CS149, Fall 2023
Performance-Aware Programming Series by Casey Muratori
Algorithms for Modern Hardware
Computer Systems: A Programmer's Perspective, 3/E - by Randal E. Bryant and David R. O'Hallaron, Carnegie Mellon University
Performance Engineering Of Software Systems - am MITOCW course
Parallel Programming 2020 by NHR@FAU
Cpu Caches and Why You Care - by Scott Meyers

The error you're encountering seems to occur during the build process for librdkafka, which is being built and linked statically as part of your Rust project that uses the rdkafka crate. Here's a breakdown of possible causes and solutions:

1. Resource temporarily unavailable (`make[1]: *** read jobs pipe: Resource temporarily unavailable.`)

This error suggests that the build process is hitting some system resource limits, possibly related to the number of parallel jobs make is trying to run. The default behavior of make is to run jobs in parallel, which can sometimes overwhelm system resources.

Solution: Try limiting the number of jobs make runs in parallel by setting the MAKEFLAGS environment variable:

export MAKEFLAGS="-j1"

Trait Bounds

Trait bounds in Rust are really powerful and also offers lots of idiomatic ways to constrain your model. Bounds are for enforcing constraints even in other languages like Scala, but Rust offers them at a different level.

Here's one example from the book Rust for Rustaceans (a great book BTW).

Suppose you want to construct a HashMap<K, V, S>, whose keys are some generic type T, value is a usize, you can write bounds like T: Hash + Eq, S: BuildHasher + Default.

pub fn doit<T>(value: T)

Abstraction and Parametricity implementing domain models in OCaml

One of my favorite comments on abstraction and parametricity ..

Parametricity can be thought of as the dual to abstraction. Where abstraction hides details about an implementation from the outside world, parametricity hides details about the outside world from an implementation.

When using OCaml as the implementation language, you abstract using ADTs (Abstract Data Types) and make your abstraction parametric using functors. And bind all of the algebras together using Modules.

Abstraction

Algebraic Domain Modeling

When we talk about the algebra of an operation, we talk about the signature of the operation, and how, starting from the input, we can just "follow the types" to lead to the implementation of that operation.

Consider the following operation generateTrades as part of a domain service TradingService. The idea is to generate all trades that happened on the day (input to the operation) and executed by the user (input to the operation) in the back-office of a securities trading organization.

In the example below, note the following 2 principles that form the core of the algebraic modeling:

The sequence of steps mentioned in the specification of the method as comments and correspond one-to-one to the types of the operations used in implementing generateTrades. I have annotated the steps in the implementation below.
The implementation of generateTrades is completely decoupled from the implementation of the operations like queryExecutionsForDate, `getAccountNoF

	#[derive(Debug)]
	enum MyError {
	Io(std::io::Error),
	Parse(pest::error::Error<Rule>),
	}

	#[derive(Debug)]
	struct StoreError(MyError);

	impl std::fmt::Display for StoreError {

	(* Modules - the signature of functions and types with no
	implementation whatsoever. Pure interfaces. *)
	module type OrderedType = sig
	type t
	val compare : t -> t -> int
	end

	(* Note we don't specify any representation for the implementation of a
	[heap]. Just the facts that define a heap - an ordered element, an
	abstract type and a bunch of functions *)

	(* an abstract signature for instantiations of the existential quantifier *)
	module type EXISTS =
	sig
	(* the predicate *)
	type 'a phi

	(* the existential type *)
	type t

	(* the introduction rule *)