ArtSoul Agent-Native Art Auctions

An agent can read a live ArtSoul auction on Base bids, deadline, provenance through declared tools instead of guessing at pixels. It prepares the bid. You sign it.

Comment

Inspiration

ArtSoul is an art auction protocol I have been building on Base.

The basic idea is simple: an artist can publish a work without minting an NFT first. Collectors discover the work and bid in an auction. Every bid has real commitment behind it through a deposit. Only after the auction settles is the NFT minted to the First Collector.

While testing ArtSoul through an AI agent, I noticed a problem.

A human can look at the page and usually figure out what is happening. An agent has to infer it from buttons, labels and whatever happens to be visible on screen.

But things like the current auction state, the exact deadline, the owner of an artwork or whether a wallet is allowed to bid are not visual guesses. ArtSoul already knows the exact answers.

That made WebMCP a very natural fit for the project.

Instead of teaching an agent how to navigate ArtSoul visually, I used the challenge to expose the protocol itself to the agent.

What it does

ArtSoul now exposes eleven WebMCP tools:

search_artworks - search published works by text, creator, lifecycle state or artwork number find_active_auctions - return auctions that are actually open for bidding, ordered by deadline get_artwork - return the public record for one artwork get_auction_state - return the current auction state, bids, bidder and timing get_artwork_provenance - return Creator, First Collector, current Owner and the event history behind them explain_settlement - explain where an artwork is in the publish → auction → settlement → mint lifecycle open_artwork - open the correct artwork for the user prepare_bid - check the current state and prepare the user for a bid place_bid - hand the transaction to the user's wallet for approval end_expired_auction - finalize an auction whose bidding period has ended prepare_artwork_registration - validate artwork details and open the publishing flow

This lets someone ask normal questions such as:

“What auctions are open right now?”

“Who created artwork 19, who was its first collector, and who owns it now?”

“Can you place a bid for me?”

The answers come from ArtSoul's own data and Base state instead of from the model trying to interpret the page.

ArtSoul currently runs on Base Sepolia. Mainnet is planned after an independent contract audit.

The read tools do not require a wallet.

The line the agent does not cross

The most important part of the integration is what the agent cannot do.

It cannot sign a transaction.

In my demo, I ask the agent to place a bid.

Before doing anything, it checks the live auction state and gives me the current terms.

During testing, the first wallet I used was the creator of the artwork. ArtSoul detected that and refused to send me into a transaction that the contract would reject.

I then connected another wallet as a collector.

The agent checked the auction again, found the current valid minimum bid, and prepared the transaction.

My wallet opened with the transaction details.

And that is where the agent stopped.

I had to review and sign it myself.

That separation matters because a bid locks a deposit. I do not want an AI agent, browser page or tool to have authority to make that financial decision for me.

Reading can be automatic.

Signing stays with the person.

No second source of truth

I also made a deliberate decision not to copy ArtSoul's economic rules into the WebMCP layer.

Things like:

bid increments deposits auction duration settlement timing

belong to the protocol and its contracts.

The WebMCP tools read the current state instead of maintaining another JavaScript version of those rules.

That means the agent layer cannot silently drift away from the protocol.

The contracts remain the source of truth.

Building the agent surface found real bugs

One of the most useful parts of the challenge was unexpected.

Making ArtSoul answer an agent precisely forced me to check whether every answer was actually correct.

That exposed bugs that were much easier for a human using the interface to overlook.

Provenance

The first implementation returned empty provenance fields because I had assumed the shape of an API response instead of validating the actual production payload.

I fixed the parser and changed the test fixture to use the real response structure.

Creator bidding

The contract already rejects a creator bidding on their own artwork.

But before the WebMCP work, a user could still get far enough in the interface to attempt that transaction.

The tools now check the connected wallet first and explain the restriction before opening the wallet.

Artwork IDs versus auction IDs

Artwork IDs and auction IDs are separate counters.

Because the numbers can overlap, an artwork lookup could accidentally resolve to an older finished auction with the same numeric ID.

That caused a live artwork to appear as if its auction had already ended.

The resolver now prefers the live auction belonging to the artwork.

This was not just an AI problem.

It affected normal bidding too.

WebMCP exposed it because an agent cannot compensate for an ambiguous answer the way a person sometimes can.

How I built it

The integration is intentionally small.

The site registers its WebMCP tools through:

document.modelContext.registerTool()

using JSON Schema inputs.

The tools reuse endpoints that ArtSoul already had.

I did not create a second backend for the agent and I did not change the protocol contracts for the challenge.

The WebMCP implementation is isolated from the main application logic and the tool definitions are built from injected dependencies, which lets me test them against mocked responses in the existing Node test suite.

The repository currently has 831 tests, with CI running on Ubuntu and Windows.

For visitors using a normal browser without WebMCP support, the integration does effectively nothing.

The bootstrap exits before registering tools or making extra requests.

Challenges

The biggest challenge was deciding where automation should stop.

It would have been easy to make the demo look more impressive by pushing more logic into the agent layer.

I deliberately went in the opposite direction.

For example, an early version of the bidding helper calculated bidding values itself.

I removed that.

If the contract controls an economic rule, the agent should not maintain its own copy of it.

Another challenge was working inside an existing product rather than a clean hackathon prototype.

ArtSoul already has contracts, an indexer, APIs, UI flows and tests.

I wanted WebMCP to sit on top of that architecture without changing how the protocol itself behaves.

Most of the integration therefore lives in new code rather than rewriting existing application logic.

What I learned

The most interesting WebMCP question for me became:

What should the agent not be allowed to do?

Giving an agent more tools is easy.

Knowing where to stop is harder.

For ArtSoul, the boundary is clear.

The agent can search, read, explain, verify and prepare.

It can help a person reach the correct transaction.

But it cannot make the final financial decision.

I also learned that exposing an application to an agent is a surprisingly effective correctness test.

A human can look at a slightly confusing interface and work around it.

An agent asks for a precise state.

If the application gives the wrong answer, there is nowhere for that ambiguity to hide.

What's next

The next step is making auction state more reactive so an agent can receive changes as they happen rather than only fetching them on request.

I also want to improve the bid handoff so the prepared amount can move directly into the bidding interface while keeping the exact same security boundary:

the agent prepares the person signs.

ArtSoul is currently running on Base Sepolia, and the next major protocol step is an independent contract audit before Base mainnet.

Built With

Share this project:

Updates

Submission history