RateFloor: Know the Gap. A Boundary First Decision Tool

The Problem RateFloor is intended to solve or assist with:

Negotiating the value of your work when you have set your minimum floor can be surprisingly difficult.

A freelancer, student, creator, contractor, or small business owner may know the minimum amount they need to accept, but pressure from a client, an unexpectedly low offer, or a long negotiation can make that boundary difficult to maintain.

I wanted to build something simple that could help a person make that decision without allowing the surrounding conversation to redefine their minimum.

That idea became "RateFloor".

RateFloor is a boundary-first negotiation tool: the user defines a minimum floor, enters an offer, and gets an immediate decision based on that floor. It can also generate a professional response, save reusable floor presets, and retrieve recent checks.

Why WebMCP?

The part that interested me most about WebMCP was the possibility of turning a normal web application into something that an AI agent can actually interact with through structured tools.

Instead of building an AI assistant that needs to know every application and every API beforehand, I wanted to explore a different direction:

What if useful web applications could expose their own capabilities directly to an AI agent?

RateFloor became my first practical experiment with that idea.

The application exposes three WebMCP tools:

1 check_offer — compares an offer against a minimum floor and produces a useful negotiation response. 2 save_floor_preset — saves a named minimum rate for future use. 3 get_recent_checks — retrieves recent negotiation checks.

This creates a small but functional example of a web application acting as a tool provider for an AI agent.

How I Built It

I built RateFloor as a lightweight web application with a focus on keeping the core interaction fast and understandable.

The application contains the normal human-facing interface, while the WebMCP layer exposes selected capabilities through document.modelContext.

I tested the WebMCP implementation directly in Chrome by inspecting the registered tools and executing them through the Model Context API.

For example, the check_offer tool accepts structured information such as:

{
  "floor": 50000,
  "offer": 35000
}

The tool correctly returned a result identifying the offer as below the user's floor and generated a professional response though there are about four more response types.

I also tested saving a floor preset and retrieving recent checks. These tests confirmed that all three registered tools could be discovered and executed successfully.

What I Learned

One of the biggest lessons was that exposing a tool is not the same thing as simply writing a JavaScript function.

The WebMCP layer has its own tool registration and execution model, and understanding the distinction between a registered tool and the arguments passed to it was an important part of building and debugging the project.

I also learned how valuable structured capabilities can be compared with an AI having to interpret a website purely through its visual interface.

A tool such as check_offer gives an agent a clear capability with defined inputs and outputs. That makes the interaction more predictable and easier to reason about.

Challenges

The biggest challenges were around understanding and debugging the WebMCP execution flow.

During testing, I initially attempted to execute a tool by its name. That failed because the API expected the actual registered tool object.

I then passed a normal JavaScript object as the arguments, which also failed because the execution interface expected the arguments in serialized JSON form.

After inspecting the registered tool and its input schema, I corrected the invocation to pass the registered tool together with JSON.stringify(...).

That allowed the same tool to execute successfully.

These small debugging steps were important because they changed my understanding of WebMCP from simply "adding AI support" to designing a proper machine-readable interface for an application.

Where This Is Going

RateFloor is intentionally small.

It is also the first proof of a larger idea I am working toward with "KEX", an AI assistant architecture designed to discover and use capabilities provided by different applications.

I do not want KEX to become an enormous system that has to contain a custom integration for every service in existence.

Instead, I am interested in an ecosystem where applications can expose useful capabilities themselves, while an intelligent layer can discover and use those capabilities when appropriate.

RateFloor is one small experiment toward that vision.

The WebMCP challenge gave me an opportunity to turn that idea into something concrete: a real web application with tools that can be discovered and executed through the WebMCP interface.

The Goal

The goal of RateFloor is not to tell people what their work is worth.

It is to help people "hold the boundary they have already chosen".

And the larger goal behind the project is to explore what becomes possible when ordinary web applications are designed not only for humans, but also to provide clear, structured capabilities to intelligent agents.