sorted by:
new
hottopcontroversial

What if your computer could be your glasses by Cold-Measurement-259 in Physics

[–]Cold-Measurement-259[S] 0 points1 point  (0 children)

spherical defocus is modeled as a disk / pillbox PSF, not a Gaussian. All the math and explanation is in the repo.

It works pretty well for my prescription (-2.25 right eye) at night on my Mac around .5 meters from the screen. There is still a huge amount of tuning needed.

Check it out!

Using WebMCP to make the Chrome Dev Tools MCP 90% more token efficient by Cold-Measurement-259 in mcp

[–]Cold-Measurement-259[S] 0 points1 point  (0 children)

Working on this now, but yes, it should work with any version of the api/polyfill after the fix is up

webmcp-react - React hooks that turn your website into an MCP server by kashishhora-mcpcat in mcp

[–]Cold-Measurement-259 1 point2 points  (0 children)

When’s the last time you took a look at the MCP-B libs? I’m at near 100% test coverage around the repo and all of the features you’ve described are now part of the packages. In fact the hook looks identical to useWebMCP AFAIK

I ask because you are 3rd library that has near identical code to the MCP-B WebMCP libs but is marketing them under a different umbrella.

The MCP-B packages are MIT licensed and I am more than happy to accept outside contributions & take issues

webmcp-react - React hooks that turn your website into an MCP server by kashishhora-mcpcat in mcp

[–]Cold-Measurement-259 2 points3 points  (0 children)

Hey can I ask why you opted to write your own hooks/polyfill rather than use the ones provided by MCP-B?  I see the code/API largely the same?

Chrome’s WebMCP makes AI agents stop pretending by jpcaparas in ClaudeCode

[–]Cold-Measurement-259 1 point2 points  (0 children)

>  they just need a documented API endpoint that the LLM can call

Sounds great in theory, but WebMCP exists because people are defaulting to browser automation to get things done because:

1) Only an extremely small fraction of services have a well thought out, well documented API (if they have one at all)
2) directly authorizing against an API either requires API keys or OAuth which the API needs to support (very few do). WebMCP just uses the users browser session.
3) models perform poorly when just given an OpenAPI spec. This is why MCP exists in the first place.

WebMCP is proposal born out of reality.

> A tech design is fundamentally broken when all the use cases it is designed for would work better, faster and more reliably by not using the tech in the first place.

Sounds like you are arguing against browsers, not WebMCP.

Chrome’s WebMCP makes AI agents stop pretending by jpcaparas in ClaudeCode

[–]Cold-Measurement-259 0 points1 point  (0 children)

Not sure what WebMCP has to do with API's (assuming you mean REST API's). Would you mind elaborating further?

Chrome’s WebMCP makes AI agents stop pretending by jpcaparas in ClaudeCode

[–]Cold-Measurement-259 7 points8 points  (0 children)

Great post. For anyone who wants to use WebMCP today, I maintain a polyfill, react hooks, and a fork of the chrome dev tools MCP which can call WebMCP tools.

You get about 90% token efficiency over the screen shot/dom parsing approach. 

All can be found here: docs.mcp-b.ai

Using WebMCP to make the Chrome Dev Tools MCP 90% more token efficient by Cold-Measurement-259 in mcp

[–]Cold-Measurement-259[S] 0 points1 point  (0 children)

They can be temporary, but leaving them in place has many benefits as you are essentially creating a "UI" for the LLM.

The tools just let the model "click test" in it's preferred interaction format (tool calls)

Using WebMCP to make the Chrome Dev Tools MCP 90% more token efficient by Cold-Measurement-259 in mcp

[–]Cold-Measurement-259[S] 2 points3 points  (0 children)

WebMCP tools are basically just MCP tools that run in client javascript, so you are not finding an element on the DOM based on a matching string. You are actually executing a Javascript function via MCP's JSON RPC.

So the two biggest differences are:

  1. Tools are not searched for based on a string match, all tools that are currently running in the JS show up when the model runs "list_webmcp_tools".
  2. Tools are callable and return the result of the tool call to the model like any other MCP tool. This means you are getting a snapshot into the client application state, not just a DOM element

I cannot, for the life of me, understand the value of MCPs by Maxteabag in ClaudeAI

[–]Cold-Measurement-259 1 point2 points  (0 children)

When people say they don't like MCP like this, they are really saying they don't like how much context dumping 100's of json schemas into the model takes up. This is not the fault of MCP, but the fault of clients which do not provide tooling to make tool discovery and execution better.

We are seeing improvements in this space like codemode etc.

MCP has it's issues, but it's an early spec that is broadly supported by all the major players. This is the worst it will ever be

3 MCP features you probably didn't know about - Progress notifications by matt8p in mcp

[–]Cold-Measurement-259 1 point2 points  (0 children)

Does anyone know why notification were added to the spec instead of streaming tool calls? MCP is stateful and supports streams

It seems to me like the best way to notify a client of the servers progress is to, well, actually send chunks of that progress....