ClearList exposes 24 tools to AI agents. An agent can create your account, write your listings, price your items, publish your sale page, read your buyer queue, reply to buyers, book pickup times, and generate a payment link.
It cannot tell anyone where you live. Not with a confirmation prompt, not with a scope, not with a warning label. The tool does not exist.
This is the decision I am most confident about in the whole product, and it is also the one that took the longest to get right, because "just add a confirmation step" is such an obvious answer that you have to work to see past it.
The threat is physical
Most privacy conversations in software are about data in the abstract. An email address leaks, someone gets more spam, everyone is annoyed.
This one is not that.
Picture someone leaving a bad relationship. They have moved, they have not told the person they left, and they are selling furniture because they are starting over and need the money. They photograph a couch and put it online.
The person they left recognizes the couch.
They message as an interested buyer. Friendly, normal questions. When can I pick it up, is it still available, what is the address. Everything about the conversation looks like every other conversation that seller is having that week.
That is the situation. Any automated path to the address is the last step to their door.
Why a confirmation prompt is the wrong answer
My first instinct was the same as everyone's: keep the tool, add a confirmation. The agent asks, the human approves, the address goes out. Human in the loop, problem solved.
It is not solved, for two reasons.
The first is that a prompt is a conversation, and conversations can be steered. If an agent can be argued into disclosing an address, then some sequence of messages exists that argues it into disclosing an address. We are all still discovering what those sequences look like. Building a safety mechanism whose reliability depends on nobody finding the right phrasing is not a safety mechanism, it is a bet.
The second reason is the one that actually settled it. A confirmation prompt is a mechanism that fails occasionally. That is fine for most features. It is not fine here, because the population most likely to be targeted is the population least able to absorb a single failure. The cost of the mistake is not distributed evenly across users. It lands almost entirely on the person who could least afford it.
When those two things are true together, the correct move is not a better prompt. It is not having the capability.
Absence is not the same as a permission
Here is the part I think is generalizable beyond this product.
There is a real difference between a capability that is restricted and a capability that is absent, and the agent ecosystem keeps treating them as the same thing.
A restricted capability still exists. There is code that does the thing, sitting behind a check. Every check is an argument, and every argument can eventually be won, whether by a clever prompt, a permission that gets loosened later, or a refactor two years from now where someone removes a guard they do not understand.
An absent capability has no code. There is nothing to bypass because there is nothing there.
For most features restriction is the right call, because most features need to work sometimes. But for a small number of capabilities, where the worst case is severe and irreversible, absence is the only version that holds.
Disclosing a home address to a stranger is one of those. So it lives with the human, in the app, and no agent credential reaches it.
What it actually takes to make a capability absent
Deleting the tool is the obvious step and it is not sufficient by itself, because it is one line of defense and one line of defense is a single point of failure. Someone adds it back for a good reason on a busy afternoon and nothing catches it.
So there are two independent guarantees.
The tool does not exist on the MCP surface. Nothing named share_address is registered, so it never appears in any agent's tool list.
The REST route underneath refuses agent credentials. Even if a tool appeared tomorrow, the endpoint it would need to call rejects an API-key credential outright with a 403, and it does so before authenticating it at all. Removing the tool is not the only thing standing in the way.
Both are pinned by tests, which matters more than either guarantee on its own. They assert that the tool list never contains share_address, that the server source never registers it, that the address route refuses an API-key credential with a 403 without authenticating it, that the refusal does not leak the address inside its own error message, and that a first-party signed-in session still reaches auth normally.
That last one is easy to forget and worth stating. The point is not to break the feature. Sellers still share their address, deliberately, when they have decided to. The point is that the human who carries the risk is the only one who can take the action.
What this costs
I want to be straight about the tradeoff rather than pretend there isn't one.
It makes the agent experience worse in a specific way. An assistant managing your sale has to hand the last step back to you. It cannot fully close the loop, and "fully closes the loop" is exactly what people want from agents. Someone will eventually build the competing product where the agent does handle it, and in the demo it will look better than ours.
I think that is the right thing to lose.
Agent-readiness has quietly become a race to expose everything, on the theory that more tools means more useful. But a tool list is a description of what an automated system is permitted to do on someone's behalf, and some things should not be on it at any price. The interesting question for anyone building in this space is not how many tools you shipped. It is which one you decided not to.
For us it is the address. It is the only capability in the product an agent cannot reach, and it is staying that way.
More on how the rest of it works: every tool in the ClearList MCP server, explained and what happens when you let ChatGPT run your sale.