Forem: Matías J. Magni

Extending LLMs with Real-Time Data: A Comprehensive Guide to the Model Context Protocol (MCP)

Matías J. Magni — Mon, 19 Jan 2026 15:39:58 +0000

The Context Crisis in Generative AI

The rapid evolution of Large Language Models (LLMs) has revolutionized the landscape of artificial intelligence, yet these models remain constrained by a fundamental limitation: the "Knowledge Cutoff." Pre-trained models, regardless of their parameter count or reasoning capabilities, operate within a frozen temporal window. They are disconnected from live data streams, private databases, and the immediate physical state of the systems they inhabit.

Traditional solutions, such as Retrieval-Augmented Generation (RAG) or manual context injection, often prove brittle, slow, or insufficient for real-time agentic workflows where latency and data freshness are paramount.

This disconnect manifests starkly in professional environments. An LLM trained in 2023 cannot tell a developer why their server is lagging right now, nor can it provide the current trading price of a volatile cryptocurrency. Without external connectivity, the model attempts to answer these queries based on probabilistic patterns learned during training, leading to confident hallucinations.

The MCP Solution: A Universal Standard

The Model Context Protocol (MCP) addresses these fragmentation issues by defining a universal standard for how AI models interact with tools and data. Described conceptually as the "USB-C of AI," MCP provides a single, standardized port that allows any "peripheral" (server) to connect to any "computer" (AI client). Just as a USB-C drive works with a laptop regardless of the manufacturer, an MCP server works with any MCP-compliant host (like Claude Desktop or Cursor IDE) without custom glue code.

This standardization occurs at two critical levels:

Transport Layer: Supporting standard input/output (stdio) for local, secure execution, and Server-Sent Events (SSE) for remote connections. The stdio transport is particularly significant for local development, as it ensures that sensitive API keys remain entirely on the user's machine.
Protocol Layer: Utilizing JSON-RPC 2.0 to define message structures for requests, responses, and notifications.

Architectural Primitives of MCP

To build effective MCP servers, one must understand the three core primitives that the protocol exposes to the LLM:

Tools (Action): Executable functions exposed by the server. They represent the "hands" of the agent. For example, get_crypto_price(coin: "solana").
Resources (Reading): Passive data sources like file handles or URLs. They provide context that can be loaded on demand, identified by URI schemes like crypto://watchlist.
Prompts (Guidance): Pre-configured templates that help users accomplish specific tasks (e.g., an analyze_market prompt that pre-loads context).

Case Study I: Financial Intelligence with TypeScript

The first implementation focuses on a Crypto Tracker built using TypeScript. This demonstrates how to leverage the extensive JavaScript ecosystem and the official MCP SDK. You can find the source code for this implementation here: BugMentor/mcp-crypto.

The Tool Definition

Using Zod, we can create a schema that acts as the single source of truth for both runtime validation and the JSON schemas required by LLMs.

// server.ts implementation pattern
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

// Initialize the server instance
const server = new McpServer({
  name: "crypto-tracker",
  version: "1.0.0"
});

// Tool Definition using Zod for schema validation
server.tool(
  "get_crypto_price",
  // Zod schema defines the expected input for the LLM
  { crypto_id: z.string() }, 
  async ({ crypto_id }) => {
    // Business Logic: Fetching from external CoinGecko API
    const price = await api.fetchPrice(crypto_id); 

    // Return structured text content adhering to MCP protocol
    return {
      content: [{ type: "text", text: `Current price: $${price}` }]
    };
  }
);

// Start the server using Stdio transport
const transport = new StdioServerTransport();
await server.connect(transport);

Case Study II: Environmental Awareness with Python

The mcp-server-weather project utilizes FastMCP, a high-level framework designed for rapid development. The full implementation is available at BugMentor/mcp-server-weather.

Decorator-Based Definition

FastMCP embraces Python's dynamic nature, using decorators (@mcp.tool()) and type hints to automatically generate tool definitions.

# server.py implementation using FastMCP
from mcp.server.fastmcp import FastMCP
import httpx
import json

# Initialize the FastMCP server
mcp = FastMCP("weather")

@mcp.tool()
async def get_current_weather(latitude: float, longitude: float) -> str:
    """
    Get current weather for a location. 
    The docstring becomes the tool description for the LLM.
    """
    url = f"https://api.open-meteo.com/v1/forecast?latitude={latitude}&longitude={longitude}&current_weather=true"

    # Asynchronous HTTP request to avoid blocking the server
    async with httpx.AsyncClient() as client:
        response = await client.get(url)
        data = response.json()

    return json.dumps(data, indent=2)

Case Study III: High-Performance System Monitoring with Rust

The mcp-server-rust-sentinel addresses a critical requirement for infrastructure agents: Zero Overhead. Rust compiles to a native binary and manages memory without a garbage collector, offering extreme performance. The complete Rust source code can be found at BugMentor/mcp-server-rust-sentinel.

Implementation Logic

The server must define structs that mirror the JSON-RPC 2.0 specification.

// Rust struct definition for JSON-RPC responses
struct JsonRpcResponse {
    jsonrpc: String,
    // The ID matches the request ID to ensure async correlation
    id: Option<Value>,
    // Rust's Option type handles nullability safely
    #[serde(skip_serializing_if = "Option::is_none")]
    result: Option<Value>,
    #[serde(skip_serializing_if = "Option::is_none")]
    error: Option<Value>,
}

This interaction demonstrates true agentic capability: the model perceives a problem (slowness), formulates a diagnostic plan (check stats, then check processes), executes it via Rust, and synthesizes a conclusion based on real-time data.

Integration and Orchestration

Currently, Claude Desktop serves as the primary host environment. To register custom servers, users modify the claude_desktop_config.json file.

{
  "mcpServers": {
    "weather": {
      "command": "uv",
      "args": ["run", "server.py"],
      "cwd": "C:/Users/dev/documents/mcp-server-weather"
    },
    "crypto-tracker": {
      "command": "npx",
      "args": ["-y", "tsx", "src/index.ts"],
      "cwd": "C:/Users/dev/documents/mcp-crypto"
    },
    "rust-sentinel": {
      "command": "C:/Users/dev/documents/mcp-server-rust-sentinel/target/release/mcp-server-rust-sentinel.exe",
      "args": []
    }
  }
}

Note: The configuration strictly requires absolute paths to the executables and working directories (cwd).

Technical Appendix: Comparison

Feature	TypeScript (mcp-crypto)	Python (mcp-server-weather)	Rust (rust-sentinel)
Framework	MCP SDK + Zod	FastMCP	Serde + Sysinfo
Type Safety	High (Compile time via Zod)	High (Runtime hints)	Extreme (Compile time)
Performance	Moderate (Node.js runtime)	Moderate (Python VM)	High (Native Binary)
Best Use Case	Web APIs, JSON heavy tasks	Data Science, Scripts	System Tools, Daemons

Conclusion

The Model Context Protocol represents a maturing of the Generative AI stack. By decoupling the model's reasoning capabilities from its context window and execution environment, MCP enables a modular, scalable, and secure approach to building intelligent systems.

Whether tracking crypto markets, checking the weather, or monitoring server health, MCP provides the missing link that turns a text generator into a functional digital assistant.

References

BugMentor. (2024). Extendiendo LLMs con Datos Reales usando MCP [Presentation]. BugMentor Research Division.
Model Context Protocol. (n.d.). TypeScript SDK Documentation. Retrieved from https://github.com/modelcontextprotocol/typescript-sdk
Model Context Protocol. (n.d.). Python SDK Documentation. Retrieved from https://github.com/modelcontextprotocol/python-sdk
Anthropic. (n.d.). Claude Desktop Configuration Guide. Retrieved from https://docs.anthropic.com/en/docs/agents-and-tools/mcp

The Cloud SDET Manifesto: Scaling Quality with Go 🚀

Matías J. Magni — Mon, 19 Jan 2026 04:04:18 +0000

The Paradigm Shift: From QA to Platform Engineering 🛠️

Let's be honest: the traditional testing pyramid is struggling. In the era of the monolith, we could spin up the full stack, run a suite of Selenium tests, and call it a day. But today? We are dealing with 50+ microservices that change daily.

If you try to test a distributed cloud architecture with standard E2E integration tests, you end up with the "Distributed Monolith":

Slow: Waiting for network latency and database I/O.
Fragility: Tests fail because a dependency (Service B) is down, not because your code (Service A) is broken.
Dependent: You can't test without a full staging environment.

The industry is seeing the birth of the Cloud SDET. This isn't just "writing scripts"; it's Platform Engineering. We build the tools—Internal Developer Platforms (IDP)—that enable teams to test with speed, autonomy, and rigor.

In this post, based on the go-cloud-testing-demo repository, we'll explore the three pillars of this new role: Isolation, Scale, and Resilience.

Pillar 1: Isolation 🧩

Goal: Verify business logic in milliseconds, not minutes.

The biggest enemy of speed is the Direct Dependency. If your UserService imports sql.DB directly, you are tied to a physical database instance.

The Problem: Coupled Code

type UserService struct {
    db *sql.DB // ❌ Direct dependency! Hard to test.
}

func (s *UserService) GetUser(id string) (*User, error) {
    // Requires a running DB to execute!
    row := s.db.QueryRow("SELECT * FROM users WHERE id =?", id)
    //...
}

The Solution: Interfaces & Gomock

We strictly follow the Dependency Inversion Principle. We depend on behavior (Interfaces), not implementation.

// 1. Define the contract
type DBClient interface {
    GetUser(id string) (*User, error)
}

// 2. Inject the interface
type UserService struct {
    client DBClient
}

func NewUserService(client DBClient) *UserService {
    return &UserService{client: client}
}

Now, we can use Gomock to simulate reality. We can reproduce "impossible" edge cases like a DB crash without pulling the plug on a server.

// 3. Test with Mocks
func TestGetUser_DatabaseCrash(t *testing.T) {
    ctrl := gomock.NewController(t)
    defer ctrl.Finish()

    mockDB := mocks.NewMockDBClient(ctrl)

    // Simulate a Fatal DB Error
    mockDB.EXPECT().
        GetUser("user-999").
        Return(nil, errors.New("FATAL: Connection Pool Exhausted")).
        Times(1)

    service := NewUserService(mockDB)
    _, err := service.GetUser("user-999")

    // Verify our service handles the crash gracefully
    assert.Error(t, err)
}

Benefit: We just tested a catastrophic infrastructure failure in 0.001 seconds.

Pillar 2: Scale 📈

Goal: Simulate production load using Synthetic Data Generation (SDG).

Using production dumps for testing is a nightmare (GDPR, size, data gravity). Instead, the Cloud SDET builds High-Performance Data Generators. We use Go's Goroutines and Channels to implement the Worker Pool Pattern.

The Worker Pool Implementation

This architecture allows us to generate tens of thousands of records per second without exhausting memory.

type Job struct {
    ID int
}

type Result struct {
    Data interface{}
    Err  error
}

func worker(id int, jobs <-chan Job, results chan<- Result, wg *sync.WaitGroup) {
    defer wg.Done()
    for job := range jobs {
        // CPU-bound generation logic
        data := generateComplexOrder(job.ID)
        results <- Result{Data: data, Err: nil}
    }
}

func main() {
    jobs := make(chan Job, 1000)
    results := make(chan Result, 1000)

    // Spin up workers (one per CPU core is a good heuristic)
    for w := 1; w <= runtime.NumCPU(); w++ {
        go worker(w, jobs, results, &wg)
    }

    // Dispatch 50,000 jobs
    go func() {
        for j := 1; j <= 50000; j++ {
            jobs <- Job{ID: j}
        }
        close(jobs)
    }()

    // Collect results...
}

The Result? 🚀

Benchmarks from the demo show this pattern hitting ~3,400 Requests Per Second on a local machine.

STARTING FULL-STACK LOAD TEST
Total Orders: 10000
Total Duration: 2.87s
Throughput: 3476.08 Requests/sec
Failed Requests: 0

Pillar 3: Resilience 🛡️

Goal: Prove the system can handle corruption and attacks.

Code coverage tells you what lines ran. Mutation Testing tells you if your tests actually catch bugs. We use Data Mutation to inject faults into valid data and ensure the system rejects it (Zero Trust).

The Mutation Engine

Generate a valid "Golden Record".
Mutate it with a known defect.
Assert that the system returns an error.

// Define a Mutator function type
type Mutator func(*Order)

// Scenario: Logic Fault - Negative Money
func MutateNegativeAmount(o *Order) {
    o.Amount = -100.00
}

func TestResilience(t *testing.T) {
    validOrder := NewValidOrder()

    // Apply mutation
    MutateNegativeAmount(&validOrder)

    // Send to System Under Test
    err := System.Process(validOrder)

    // If no error, the system is vulnerable!
    if err == nil {
        t.Fatalf("Resilience Fail: System accepted negative amount!")
    }
}

This proactively prevents "dirty data" from entering your microservices mesh.

Conclusion

The Cloud SDET is a builder. We use Go not just to write tests, but to engineer the platforms that make testing possible at cloud scale.

Isolation decouples us from the "Distributed Monolith".
Scale proves we can handle Black Friday traffic.
Resilience ensures we survive the chaos of the real world.

Check out the code and start building your own platform:
👉 github.com/BugMentor/go-cloud-testing-demo

References

BugMentor. (n.d.). go-cloud-testing-demo: Cloud testing with Go concepts [Source code]. GitHub. https://github.com/BugMentor/go-cloud-testing-demo

BugMentor. (n.d.). playwright-mcp-demo-example [Source code]. GitHub. https://github.com/BugMentor/playwright-mcp-demo-example

Leapcell. (n.d.). Go routines and channels: Modern concurrency patterns. https://leapcell.io/blog/go-routines-and-channels-modern-concurrency-patterns

Magni, M. J. (2025, December 3). Cloud testing con Go [Webinar]. Luma. https://luma.com/qcoy2jyd

Magni, M. J. (n.d.). Cloud testing con Go: De QA automation a SDET. BugMentor.

Medium. (n.d.). Mastering mocking in Go: Comprehensive guide to Gomock. Towards Dev. https://medium.com/towardsdev/mastering-mocking-in-go-comprehensive-guide-to-gomock-with-practical-examples-e12c1773842f

Singh, K. P. (n.d.). Advanced concurrency patterns: Worker pool. Learn Go. https://karanpratapsingh.com/courses/go/advanced-concurrency-patterns

Uber-Go. (n.d.). Usage of GoMock [Source code]. GitHub. https://github.com/uber-go/mock

When to Choose Playwright Over Cypress: A Guide for SDETs

Matías J. Magni — Mon, 19 Jan 2026 02:03:35 +0000

Playwright enables full control over network requests, including:

Mocking API responses.
Intercepting WebSocket traffic.
Testing offline scenarios.

Use case examples:

Stock trading platforms requiring real-time data validation.
Applications that need to simulate different network conditions (3G, Offline).

7. Summary Table: When to Choose Playwright Over Cypress

Feature	Cypress	Playwright
Multi-Tab Support	❌ Not Supported	✅ Native Support
iFrames	⚠️ Limited / Difficult	✅ First-Class Support
Browser Support	Chromium, Firefox	Chromium, Firefox, WebKit (Safari)
Mobile Emulation	❌ Viewport only	✅ Device Emulation
Parallel Execution	💰 Paid Service (Cloud)	✅ Native & Free
Language Support	JavaScript / TypeScript	JS, TS, Python, Java, .NET

8. Key Takeaway

While Cypress is a great choice for simple, fast, front-end-focused testing, Playwright offers superior flexibility for applications requiring:

Multi-tab workflows
Cross-browser compatibility (Safari)
Complex DOM structures (iFrames)
Advanced network interception
Scalability with parallel execution

For SDETs working on large-scale projects with diverse testing needs, Playwright often proves to be the more powerful and future-proof option.

Reference List

Microsoft. (n.d.). Playwright Documentation. Retrieved from playwright.dev
Cypress.io. (n.d.). Cypress Documentation. Retrieved from cypress.io
W3C. (2022). WebDriver Specification. Retrieved from w3.org
MDN Web Docs. (n.d.). iFrames and Cross-Origin Security. Retrieved from developer.mozilla.org

k6 vs. JMeter: Comparing Load Testing Tools and AI-Enhanced Scenario Generation

Matías J. Magni — Mon, 19 Jan 2026 01:59:01 +0000

Originally published on February 10, 2025 by Matías J. Magni (Sr. SDET | International Speaker).

In today's dynamic software development environment, selecting the appropriate load testing tool is crucial for ensuring application performance and reliability. While Apache JMeter has been a longstanding choice, k6 has emerged as a modern alternative.

This article provides a balanced comparison between k6 and JMeter, addressing specific limitations and exploring how artificial intelligence (AI) can enhance scenario generation in both tools, including code generation in Java.

1. Protocol Support

k6 natively supports HTTP/1.1, HTTP/2, WebSockets, and gRPC, with extensions (via xk6) for niche protocols like MQTT or Redis 8.

JMeter, however, supports a broader range of legacy protocols (FTP, JDBC, SMTP) out-of-the-box via plugins.

Key distinction:

k6 excels for modern API/cloud-native testing.
JMeter remains indispensable for legacy systems (e.g., banking mainframes using JMS).

2. Browser Simulation: Intentional Trade-Offs

k6 does not replicate full browser behavior (DOM rendering, JavaScript execution). Its xk6-browser module enables hybrid testing:

// Example: Protocol-level + limited browser interaction  
await page.goto('[https://app.com](https://app.com)');  
await page.locator('#login').type('user');

This combines protocol-level scalability with select browser actions (e.g., form submissions) but avoids resource-heavy rendering.

Why this matters:

Simulating 10k users with headless browsers is impractical (cost/performance).
k6’s hybrid approach targets backend bottlenecks while JMeter’s GUI-centric model struggles with modern SPA workflows.

3. Scalability: TCP Ports ≠ Virtual Users

Dmitri correctly notes TCP port limitations (~65k per machine). However:

k6’s efficiency: A single machine can simulate 50k+ VUs via Go’s goroutines (1 goroutine ≈ 2KB RAM vs. JMeter’s 1MB/thread).
Distributed testing: Practical limit: 50k–65k VUs per node, depending on network/OS configurations.

4. Scripting: Code-First ≠ Code-Only

JMeter

Programmatic scripting is possible (Groovy/Beanshell) but rarely used. The GUI remains primary for non-developers.

k6

JavaScript/TypeScript aligns with DevOps workflows (Git-friendly, IDE integration).

AI integration example:
LLMs (like GPT-4) excel at generating valid JavaScript for k6. You can feed a Swagger spec to an LLM and get a working k6 script instantly. With JMeter, generating complex XML test plans via AI is error-prone and often results in invalid file structures.

5. Real-Time Analytics: Both Tools Deliver

JMeter: Real-time results via Listeners + InfluxDB/Grafana plugins.
k6: Native streaming to Prometheus, Grafana, or Datadog.

Differentiator: k6’s metrics are natively structured for modern observability stacks.

Comparison Table

Feature	Apache JMeter	Grafana k6
Primary Use Case	Legacy systems, wide protocol support	Modern APIs, Microservices, Cloud-native
Scripting	GUI-based (XML), optional Groovy	Code-first (JavaScript/TypeScript)
Resource Usage	High (Java Threads, ~1MB/thread)	Low (Go Goroutines, ~2KB/VU)
Browser Simulation	Limited (no JS execution)	Hybrid (via xk6-browser)
DX (Dev Experience)	Separate tool, GUI heavy	Git-friendly, IDE integrated
AI Generation	Difficult (XML structure issues)	Excellent (Native code generation)

Conclusion: Choosing the Right Fit

k6 is not a "JMeter killer." Instead, it is a specialized tool tailored for modern, code-centric teams that value efficiency and seamless integration with cloud-native ecosystems.

JMeter remains a valuable asset for testing legacy systems and for teams that prefer a GUI-based workflow.

The choice between k6 and JMeter depends on your specific needs, technical expertise, and the nature of the application you are testing. Consider the factors outlined in this article to make an informed decision.

Thank you, Dmitri, for highlighting the importance of nuance. This revision aims to reflect both tools’ strengths without overreach.

Let’s keep the conversation going: What criteria do you use to choose between k6 and JMeter?

Reference List

Apache JMeter Team. (n.d.). Building a programmatic test plan. Apache JMeter User Manual. Retrieved February 10, 2025, from jmeter.apache.org
Apache JMeter Team. (n.d.). Real-time results. Apache JMeter User Manual. Retrieved February 10, 2025, from jmeter.apache.org
BlazeMeter. (n.d.). Convert Postman API tests to JMeter scripts. BlazeMeter Blog. Retrieved February 10, 2025, from blazemeter.com
Perforce Software. (n.d.). Understanding TCP port limitations. Perforce Portal. Retrieved February 10, 2025, from portal.perforce.com
Grafana Labs. (n.d.). Running browser tests with the k6 browser module. k6 Documentation. Retrieved February 10, 2025, from grafana.com
Grafana Labs. (n.d.). Using k6 protocols. k6 Documentation. Retrieved February 10, 2025, from grafana.com