MCP (Model Context Protocol) is an open standard developed by Anthropic that allows AI agents to interact with external tools.

By giving the AI access to real-world context, MCP reduces hallucinations and expands what agents can actually do — from querying live APIs to inspecting browser state.

One of the simplest and most effective use cases is letting the AI see your browser console logs. For web development, this is a huge unlock. Normally, if the AI builds something buggy, it's completely blind to runtime errors unless you manually copy and paste the error into your chat window.

That’s not just tedious — it also breaks multi-step agent workflows. If an AI is trying to implement a feature but hits a runtime error, it often can’t recover without visibility into what went wrong.

Connecting console logs is the first step toward giving the AI full awareness of your browser — and it's already incredibly useful.

While there’s a lot of hype around advanced MCP integrations (project tracking, build systems, etc.), debugging browser errors with MCP is the most accessible and practical place to start.

In this guide, you’ll learn how to set it up using Cursor IDE, the most popular AI coding assistant today. The same approach works with tools like Cline or Windsurf if you're using one of those instead.

The Plan

This tutorial uses the Agent Desk AI plugin. While their docs are sufficient, they cover a lot of ground unnecessary to a simple setup. They're also slightly out of sync with the current version of Cursor, and glossed over some important concepts such as the difference between SSE and function MCPs.

We want the simplest possible proof-of-concept that lets us verify the AI can see and fix a browser error. So given that, the plan is:

1. Create a new NextJS app
2. Throw a simple error that will show in the browser logs
3. Install the BrowserDesk tool
4. Wire Cursor together to the MCP tool
5. Verify the AI agent can now see the console errors and fix the issue

Creating The App

For this experiment we will just create a generic NextJS app:

npx create-next-app@latest mcp-test 

and now we can just create a simple error in the main index file:

  useEffect(() => {
    // Simulate a bug
    const broken = undefined;
    // console.log(broken.length); // This will throw an error - Commented out to fix
  }, []);

Now we have a nice big fat red error:

If we use Cursor to fix the error, it will tell us it has no way of seeing the error.

Installing and Configuring the Browser Desk Tool

The AgentDesk plugin has 3 parts:

1. A chrome extension that provides the information about the browser logs
2. A Node server that knows how to talk to the chrome extension
3. Another CLI tool that knows how to query the Node server for the browser information

MCP Function vs Server

This is already a few different moving parts, but what makes this especially confusing is that you're running a server but it's not AN MCP server. An MCP server is a specific standard that must implement features like SSE (server-side events) which this server does not. Instead, the final tool is an MCP function, which talks to a custom non-MCP server.

Installing the Chrome Extension

Download the chrome extension here, then go to Chrome -> Extensions -> Load Unpacked and select the zip file. Make sure its running in Chrome.

Installing the Server

The server step is the simplest, as you just run:

 npx @agentdeskai/browser-tools-server@latest`

in your terminal. Note that thsi should be done before running the browser-tools-mcp@latest in the next step, despite the GitHub README mistakenly switching the order at one point.

Configure the MCP

The final step is to give Cursor the ability to run the command to talk to the server. To do that, we just go to Cursor->Settings->Install New MCP server and drop off this JSON:

{
 "mcpServers": {
   "browser-tools": {
     "command": "npx",
     "args": ["-y", "@agentdeskai/browser-tools-mcp@1.2.0"]
   }
 }
}

as you can see the MCP in this case is not a server but instead a CLI command.

It Should Work

You should see Cursor show that the MCP is now loaded:

And now if you ask a model in Cursor if it sees the error, it should tell you it sees the error and be able to fix it.

Conclusion

Browser dev logs are a no-brainer use case for MCP and the first anyone working in webdev should setup. Hit me on twitter @bill_prin or email waprin@gmail.com with any comments.

This post is about why I stopped using the web framework Django in favor of NextJS. More broadly, it’s about why I would entirely avoid Python web frameworks, such as Flask, if you plan to serve up any HTML. While I’ve only dabbled in the Ruby community, I imagine most of my points will also apply to frameworks like Rails.

The summary is that using a language like Python or Ruby for a significant web project has increasingly gotten less reasonable over time to the point where now, in 2022, it’s getting hard to justify. By not keeping your web stack in pure Javascript, you are making your life unnecessarily difficult (as usual, we’ll include languages like Typescript as part of the Javascript ecosystem). You will almost certainly invest a bunch of time-solving problems that would be automatically solved for you if you just stuck with Javascript.

I will provide specific examples of solving problems using Django that would have been trivially solved in NextJS.

I can only think of two valid reasons to use Python or Ruby for the web in 2022:

• You’re working on an existing project that hasn’t been migrated yet or is not worth migrating.
• You are already a master of a Python or Ruby web stack, and you need to implement a new project as soon as possible, and you don’t have time to learn a better stack.

Developer circles have a sentiment that it’s best to master a few tools, know them well, and stick with them. It’s good advice to avoid constantly chasing new tools and frameworks over getting any work done. The developers I know who are best at shipping things have a few solid tools they stick with and focus on shipping products rather than updating their tech stacks. But, like many pieces of advice, you need to find a balance.

When I first found Django, I fell in love with how productive and "batteries included" it was and switched my "side project stack" from PHP to Django. I pushed to work on Python and Django and when I joined Google I led all the documentation around using Django on Google Cloud Platform, including docs on how to run it on App Engine (managed and flexible), Compute Engine, and Kubernetes / Container engine. My only Github repo that's attracted non-negligible attention is a Django on Kubernetes sample. And in past few years the vast majority of my development focus has been on Python.

So I was not eager to get rid of Python, if anything my career has me tagged as a “Python guy”. In 2020, my non-technical friend really wanted to make a little side project where we listed music livestreams and hosted Zoom parties around them. We felt there was a cultural wave as part of Covid and wanted to move fast so I stuck with what I knew which was Django. In some sense it worked really well because I had several non-technical people use the admin console to update the website with minimal influence from me.

The issue is that I ran into several problems:

• At first, I thought I didn’t need fancy frameworks like React, and it’s better to use something simple, which was ZeptoJS (a more perfomant jQuery clone). But even the “simple” features our website needed like an infinite scroll of music livestreams started turning into spaghetti code. I wanted to move to React to achieve a more declarative approach but getting Django and React to play nicely together was non-trivial. NextJS makes it trivial to start a new React project, and even brings me back to the PHP days of mapping the filename to a single page
• My webpage loaded a bunch of images and rendered them in a gallery which was very slow. I wanted to only load the image when the user scrolled to see it. To accomplish this, I had to use the Intersection API, which was fun, but NextJS Image component does this out of the box.
• Because I wanted infinite scroll to make the website more modern, I had to render the grid components as they scrolled. It would have been better to do this server-side since it would be faster, but it also needed to be done client-side after the timezone was updated. (see my post on How to show local timezones on a webpage without asking the user for their location )
• Furthermore, I wanted the first page load to be very quick and contain content so the SEO would be faster. Some of the content could be rendered ahead of time statically. But again, I had to rewrite the same code in Python and in Javascript

So one of my biggest problem was wanting to render the same component, but some times statically ahead of time, sometimes dynamically on the server (for user specific cases), and sometimes on the client (to re-render any timezone updates).

Being able to easily render components statically, server-side, or client-side is one of the fundamental features of NextJS. This is in addition to a ton of commonly used frontend optimizations like Image viewport rendering that Django simply does not offer. Django is not really “batteries included” anymore now that the batteries have changed.

Besides these features, there’s a few other good reasons to stick with Javascript. For one, every web project uses it so almost all of the good tooling for other things you need such as CSS preprocessing will be Javascript-centric. You will inevitably need NodeJS in your project , and if you have two languages, now you need to worry about tooling for both (e.g. dependency upgrades).

When NodeJS first came out, Python still felt more usable in many ways. NodeJS would easily turn into callback hell. But in 2022, it’s Python that feels hobbled by an awkward async story, while NodeJS async/await feels much simpler. Typescript also feels more fleshed out than Python typing and the tooling around it feels easier to understand.

Python is still an amazing language and it’s still probably the best “jack-of-all trades” language there is. It might make sense to use something like Django Rest Framework if you plan to do a significant amount of machine learning and want to use one language to write all your models. Of course, I’m very indebted to all the amazing OSS contributions made by the Python and Django communities.

But going forward, Django is something I will look back fondly on rather than use for any projects. Aside from quick experiments for learning purposes, I plan to stick entirely within the Javascript ecosystem for web projects.

This post will explore the classic game Slime Volleyball and some of its physics, notably 2D ball elastic collision.

It will go over:

• Some history of Slime Volleyball and how it's being used by cutting edge deep learning AI researchers
• How Conservation of Momentum and Conservation of Kinetic Energy serve as the underlying equations for the calculations
• Some practical tips on how to understand it intuitively, how to code it in up in a 2D game, and how the game physics diverges from real world physics

This post was created while writing an implementation of Slime Volleyball in Go using SDL 2.

Background

Slime Volleyball was a viral Java applet game that emerged around the year 2000, and I have many fond memories of playing it as a kid. I was watching Francesc Campoy's excellent just for func video series where he coded up a Go version of Flappy Bird, and I wanted to follow along with a different game, so I chose Slime Volleyball. However, when I got to the collision of the ball and the slime, I realized that I didn't understand how to correctly code it. So I started looking at some other implementations and tried to learn a little more about how the calculations are derived.

One option would be to just reach for a physics engine like Box2D, but I wanted to learn more about the underlying physics, wanted to be able to tweak it more easily, and I didn't want to bring in a big dependency for what was ultimately just a few lines of code.

In most games, it's not super critical that the game physics closely match real world physics, and you often intentionally diverge from them either out of practical necessity or as an intentional part of the design. However, as humans we do have some intuition for how things work in the "real world" so having at least some understanding of how the real physics work is a good baseline to start from. Slime Volleyball physics both use some simplifications, some "fudge" factors, and then one major divergence from real world physics which I will review.

Along the way reviewing other implementations, I stumbled upon hardmaru, a Google Brain researcher that uses Slime Volleyball to compare reinforcement learning algorithms.

Like Bitcoin, the original creator of Slime Volleyball is unknown, though at least one version was maintained by Quin Pendragon and Daniel Wedge. Reddit user /u/marler8997 decompiled the Java applet and rewrote it in Javascript for an HTML5 version which I used as a reference for my Go version. However, his collision physics code isn't exactly easy to understand.

 function collisionBallSlime(s) {
   var dx = 2 * (ball.x - s.x);
   var dy = ball.y - s.y;
   var dist = Math.trunc(Math.sqrt(dx * dx + dy * dy));

   var dVelocityX = ball.velocityX - s.velocityX;
   var dVelocityY = ball.velocityY - s.velocityY;

   if(dy > 0 && dist < ball.radius + s.radius && dist > FUDGE) {
     var oldBall = {x:ball.x,y:ball.y,velocityX:ball.velocityX,velocityY:ball.velocityY};
      ball.x = s.x + Math.trunc(Math.trunc((s.radius + ball.radius) / 2) * dx / dist);


     ball.y = s.y + Math.trunc((s.radius + ball.radius) * dy / dist);
     var something = Math.trunc((dx * dVelocityX + dy * dVelocityY) / dist);

     if(something <= 0) {
       ball.velocityX += Math.trunc(s.velocityX - 2 * dx * something / dist);
       ball.velocityY += Math.trunc(s.velocityY - 2 * dy * something / dist);
       if(     ball.velocityX < -MAX_VELOCITY_X) ball.velocityX = -MAX_VELOCITY_X;
       else if(ball.velocityX >  MAX_VELOCITY_X) ball.velocityX =  MAX_VELOCITY_X;
       if(     ball.velocityY < -MAX_VELOCITY_Y) ball.velocityY = -MAX_VELOCITY_Y;
       else if(ball.velocityY >  MAX_VELOCITY_Y) ball.velocityY =  MAX_VELOCITY_Y;
     }
   }
 }

What is something variable supposed to be? I will review that now:

Elastic Collision Physics

The main concept to understand the bounce is Elastic Collision. This means a collision with no loss of energy. In the real world there would be some friction and loss of energy, but we can ignore that in our slime world. In an elastic collision, two equations apply, the Conservation of Momentum and Conservation of Kinetic Energy (this one only applying in elastic idealized collisions). The Conservation of Momentum states that:

and the Conservation of Kinetic Energy states that:

Now what you can note is that, since we can assign whatever masses to our two circles that we want, and we know their initial velocities, there's only two unknowns, which are the two final velocities. And we have two equations, and two unknowns, so we can solve for those two unknowns.

However, the actual algebraic derivations are quite tricky, so we can take Wikipedia's word for it and use their final equations, particularly the "angle-free" equations which use dot-product calculations instead of using trigonometry on the angle of the collision:

In our case, the slime is x1 with velocity v1 and mass m1, and the ball is at position x2 with velocity v2 and mass m2.

A helpful note, in this case x1 and x2 are the position values, which each have an (x,y) component. This (x,y) component represents the center of the circle (the slime itself is represented as a circle with the bottom half not rendered).

The parentheses in the Wikipedia equation represent the dot product, so we are taking the dot product of the difference in positions of the two circles and the difference in velocities, across the x-axis and y-axis. In the code this is represented by:

(dx * dVelocityX + dy * dVelocityY)

There's a few important takeaways from the "angle free" collision equation. Our new velocities are based on the initial velocities with some change. The change of the ball velocity has three terms.

• The first term is based on the ratio of the masses (2m1/(m1+m2)). This will simplify to just 2.
• The second term is a dot product divided by a distance. This will be a scalar value.
• The third term is the vector difference of the two positions (x2-x1). This will be a vector value.

Importantly, the first two terms are scalar values (just a magnitude with no direction), while only the third term has a vector value.

We can simplify things by making the slime mass m1 set to 1, and the ball mass m2 set to infinitesimal (rounds to 0), as if the slime has much more mass. This leaves the slime velocity unchanged, v1 = v1, since the velocity change is multiplied by the mass m2=0. This is a good simplification for the game since we don't want the slime itself to bounce.

The direction of the ball's velocity change is determined by the final x2-x1 component, which is the vector difference between the two positions. That is also called the "normal" component of the collision, since it's in the direction perpendicular to the tangent line between the two circles.

So now we know the direction of the force we are applying, we just need to know how much force we need to apply (the magnitude).

As mentioned, the first term, the ratio of the masses, should simplify to 2, so we just need to calculate the dot product of the position difference with the velocity. This is basically where the angle of the collision gets taken into account, as the dot product is a simpler way to write the product of the magnitudes and the cosine of the angle.

Again, in the code this looks like:

(dx * dVelocityX + dy * dVelocityY)

So the closer to the top of the slime hits, the more the ball will be affected by the y-velocities, and the closer to the edge of the slime the ball hits, the more the ball will be affected by the x-velocities. This also aligns with our intuitive understanding of how the physics "should" work.

The final part of the equation is dividing by the distance between the two velocities, squared. In physics, it's very common to divide a vector by a distance to "normalize" it, which turns a vector into a distance of 1. This makes sense for when you're trying to calculate a direction without having the raw magnitudes affect the end result. My way of thinking about dividing by the distance squared is both the second (the dot product) and third terms (the direction) are being normalized, so only the relative masses affect the end calculations.

Tying back to the HTML5/Javascript implementation, it's now clear that the something variable is the dot product value in the Wikipedia elastic collision equation, though normalized ahead of time.

Coding The Physics In The Game

In this last part, we will review some practical tips on implementing the "bounce" in the code.

The first important step is detecting the collision itself. Fortunately, this is super simple, as we represent both the ball as a circle, and the slime as a circle (the bottom half is simply not rendered). Since both circles have a radius, we can decide the ball collides with the slime if the distance between the two circle centers is less than or equal to the sum of the two radii.

Once the collision is detected, you don't want to apply the calculations right away. This is because if you change velocity, but in the very next frame the ball is still colliding, the velocities will be recomputed again based on the new post-collision velocities, which won't be right and may create the ball to get stuck in some weird loop. So instead, once the collision is detected, we first move the ball away from the slime so that it's no longer colliding and then calculate the new velocities.

  ball.x = s.x + Math.trunc(Math.trunc((s.radius + ball.radius) / 2) * dx / dist);
  ball.y = s.y + Math.trunc((s.radius + ball.radius) * dy / dist);

Another detail that the HTML5 version applies is capping both the new x and y velocities at a maximum value. While this shouldn't be strictly necessary, it keeps the game more even paced and avoids a strange collision sending the ball rocketing.

As another adjustment, while in the "real" physics calculations our mass ratio term was 2, in the game we can basically consider this a fudge factor to be whatever we want so that the game feels fun and natural.

Finally, both the HTML5 version and hardmaru's Python version make one significant divergence from true elastic collision physics. That is, during the collision when calculating the new velocities, they also add the slime's current velocity to the new ball velocity. In the actual elastic collision detections, the slime's velocity only plays a role in that the difference between the slime's velocity and the ball's velocity contribute to the dot product magnitude of the change.

What's the impact of this divergence from real physics? The main impact is that the ball becomes a bit more controllable by the slime. For example, it's easier to "catch" the ball by moving the slime backwards as the ball is coming towards it. If the physics calculations stuck to the real world, the ball's velocity would bounce forward and fall and hit the ground. By also adding the slime's velocity to the new velocity, the ball "sticks" the slime and moves with it, giving the player more fine-tuned control of the ball and letting the player make more surprising moves.

Conclusion

These days, most game developers use engines like Unity 3D that come with pre-packaged physics solutions, so you don't need to learn about these topics to make a game. Still, creating a game from scratch with a minimalistic 2D layer like the HTML5 Canvas or libsdl allows you to learn a lot of interesting graphics, physics, and AI concepts from first principles. I had fun recreating one of my favorites games and learning from other implementations, and I hope this article might help anyone stuck on 2D game physics in the future.

Of course, people get annoyed if you don't render the start times of the stream in their local timezone, so while we initially listed all the start times in EDT, one of the biggest initial complaints was for local timezone support.

The site is currently a Django webpage backed by Google App Engine. I am a lot more comfortable with Python than Javascript so I was looking for a way to do the timezone localization server side.

I had previously mistakenly believed there were a few ways to accomplish this, none of which are great:

• Ask the user to create an account and specify their timezone preference
• Require the user to provide their location to get local timezones
• Guess their timezone based on their IP address (not very accurate)

However, my friend and former colleague Chris Broadfoot pointed out there's a better way to accomplish this: Javascript! Of course, I'm sure it's possible to do this all in frontend Javacript, but I know Python a lot better and was hoping to leverage Python's datetime libraries to do the heavy lifiting. Fortunately, you only need a few lines of Javascript and can then let the server do the rest of the work. However, If you have a favorite Javascript library to accomplish this, let me know on Twitter.

Any timezone you serve as part of your web page should not be delivered initially, but instead be served by an AJAX call. Before you make this AJAX call, you use Javascript to get the user's timezone or UTC offset, add that as a parameter to the call, and then the server can use that to provide the local timezone.

First, get the user's timezone

The key to get the user's timezone is in two Javascript functions outline in this Stackoverflow question. The first is new Date().getTimezoneOffset(), which just offers the offset from UTC. This is almost always supported, but makes it difficult to render the user's actual timezone, since multiple timezones can have the same offset. It's also nice for the user if they see the abbreviation of their timezone rendered (EDT, PDT for Americans, VET for a Venezuelan), which is only possible if you know the actual timezone, since if you just have the offset you have to guess.

Fortunately, there's a way to get the actual timezone that's usually supported as the second answer to that Stack Overflow answer:

console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)

Since this is usually but not alway supported, I wrap it in a try/catch that falls back to getTimezoneOffset if it fails.

Now render the timezone on the server

Once I have the timezone name, or the offset, I can use Python/Django's excellent datetime libraries to render the timezone in a local format:

    local_tz = None
    if tzInfo: # tzInfo is passed an AJAX parameter based on Intl.DateTimeFormat().resolvedOptions().timeZone
        try:
            local_tz = pytz.timezone(tzInfo)
            local_start = start_date.astimezone(local_tz)
            start_time = local_start.strftime("%I:%M %p") # renders as 12:30 PDT        
        except Exception as e:
            logger.info(f"failed to load timezone {tzInfo}")
    
    # only on a few old browsers, fall back to tzOffset which was obtained by new Date().getTimezoneOffset()
    if local_tz is None: 
        tzName = 'Local' # guess 'local' if we can't find it  in mapping 
        # if we don't know the timezone , we can guess based on the offset
        # you have to manually fill this in with your best guess of a timezone based on offet, e.g. 240 -> EDT
        tz_mapping = {
          ... 
        }
        if tzOffset in tz_mapping: 
            tz = tz_mapping[tzOffset]
        local_start = start_date + datetime.timedelta(minutes=(-1 * tzOffset))
        start_time = local_start.strftime("%I:%M ") + tzName
     

And that's it! With this approach, I can let Python and Django do the heavy lifting of timezone localization and render the time in each user's timezone without asking them for their location or preferences.

A while back, I noticed a lot of Python projects were starting to contain a file called 'tox.ini', which is a file read by tox.

Of course, the tox documentation should be considered the canonical source. It has lots of good examples, but I still found the docs a bit confusing at first, so I thought I would take my own shot at explaining the basics.

This is what a complete tox.ini file might look like:

   [tox]
   envlist = py26-django{15,16},
             py{27,33,34}-django{15,16,17,18}
   install_command = pip install {opts} {packages}
   
[testenv]
   basepython =
       py26: python2.6
       py27: python2.7
       py33: python3.3
       py34: python3.4
   
   commands =
       nosetests

   deps =
       nose
       django15: Django>=1.5,<1.6
       django16: Django>=1.6,<1.7
       django17: Django>=1.7,<1.8
       django18: Django>=1.8,<1.9

At first, it was unclear to me what the point was at all, because we were already either using unittest or nose to actually run the tests. If we already have a test framework, why do we need yet another tool?

The problem that tox is trying to solve is that your tests might be run using multiple tools in a variety of different environments. So, for example, you might want to run Python unit tests using the standard unittest tool, as well as check your style with a tool like flake8, and your code coverage with a tool like coveralls. You want to run these tools using both Python 2.7 and Python 3. That means you have 3 different tools and 2 different environments. Tox helps you declare how all of this gets pieced together in one spot, and helps manage situations like different environments requiring different dependencies.

This combination of environments is generally what you specify at the top of the tox file underneath the [tox] directive, like so:

[tox]
envlist = py26-django{15,16},
          py{27,33,34}-django{15,16,17, 18}

In the above example, we are creating 14 different environment names, 2 environments on the first line and 12 environments on the second line. Using the braces means we want to repeat each of the factors in the braces for a different environment. So the first line creates two environments, py26-django15 and py26-django16. The second line creates 12 more environments, combining each of the three versions of Python that we specify with each of the 4 different versions of Django that we specify.

Following that, we can put all our default settings that applies to all environments underneath the [testenv] directive:

[testenv]
  configuration that applies to every environment goes here

Next, we configure specific environments by adding a a directive with the environment name after the colon, so to setup configuration specific to the Python 2.6/Django1.5 environment we created above we would add:

[testenv:py26-django15]

and then we would put everything specific to that environment underneath it.

Until we configure an environment, it's doesn't have any special meaning. py26-django15 is just a name until we use the basepython directive to match the py26 "factor" to the python2.6 executable, and the deps command to match django15 "factor" to the Django1.5 dependency.

Here is how we can match our Python environment names to the correct Python executable:

[testenv]
basepython =
    py26: python2.6
    py27: python2.7
    py33: python3.3
    py34: python3.4

Note how we are individually referencing just part of the environment name , or factor, such as py26, and tox is smart enough to match that base command with all the complete environment names that contain the py26 factor.

We also need to add the correct dependencies, which we might do something like this:

deps =
    pytest
    django15: Django>=1.5,<1.6
    django16: Django>=1.6,<1.7
    django17: Django>=1.7,<1.8
    django18: Django>=1.8,<1.9
    py26: unittest2

My first question upon seeing the deps field in tox was, why are we using tox to manage dependencies? I thought the general Python best practice was to combine a requirements.txt file with something like pip?

While pip is a popular approaches to dependency management, it's not the only ones, and tox tries to remain somewhat agnostic and not rely on pip or the existence of a requirements.txt . However, if your dependencies are nicely captured in a requirements.txt file, tox supports that:

 deps = -rrequirements.txt

Finally, we need to give tox something to actually run our commands. This is literally just the command we need to run, so it's something as simple as:

commands =
    python test.py

With all this done, we can just run 'tox' and all our commands will be run for each of our environments.

Conclusion

So that's a basic introduction to tox and why you would use it. A lot of this information is a rehash from the tox documentation, and of course the best way to learn is by example, for which you can find many on the tox site and floating around on Github.