Furrow

• 

  svg

What it is

Furrow is a garden plan you draw and your agent reviews in the margin. You lay out raised beds by season and put crops on wooden plant stakes in your own hand. Your agent reads the live plan through WebMCP, leaves comments anchored to the exact bed and strip, and proposes plantings in pencil. It never plants. Only you can.

Live: https://anusree-j.github.io/furrow/

Code: https://github.com/Anusree-J/furrow (MIT)

Why this is a WebMCP use case

Planning a vegetable garden is a shared-document problem wearing wellies. The plan is a structured artifact that one person authors from what only they know: which bed floods, what the kids will eat, how many hours they really have. A good adviser adds what they do not know: rotation, sowing windows, succession, effort. The natural shape is the one everyone recognises from a shared document: the author writes, the reviewer comments in the margin anchored to the exact spot, the author resolves.

That shape needs the page. The agent has to read the live plot, not a description of it, and its comments have to land on the bed and season they are about. Its proposals have to be visible next to the person's own choices without becoming the plan. A chat cannot hold a plot; a remote server cannot see the page the person is editing.

How it improves the experience

• You never describe your garden twice. get_garden gives the agent beds, sun, last year's families, this year's plantings, the household profile, and the page's own agronomy flags in one call.
• The page computes the facts (rotation, sowing season, sun, antagonists) deterministically and tells the agent not to restate them, so the agent spends its turn on judgement: what this household should grow, where, and why.
• Agent proposals appear as pencil stakes with reasons. Tick one, plant them all, or skip. A comment with a suggested alternative is applied in one click.
• Every change from either side is attributed in one log and undoable.

What becomes possible together

The division of labour is enforced by the tool surface. Planting, moving, removing, accepting, and resolving are page controls with no tool behind them. The agent cannot propose anything until you have told it about your climate and frost dates: propose_planting and propose_plan are not registered until the profile is set, so the agent's first move is to ask. withdraw_comment exists only while the agent has open comments. You keep authorship; the agent keeps the margin.

How I built it

Vanilla ES modules, no build step. Nine imperative tools on document.modelContext with JSON Schemas and readOnlyHint annotations, registered with AbortSignal so availability follows plan state and fires toolchange. Every mutating tool returns the changed object plus phase, current page flags, and suggested next actions. A single store with snapshot undo persists to localStorage. A 25-crop catalog and a deterministic rules module drive page flags. All illustrations are an inline SVG sprite. A built-in Tool inspector invokes the registered tools through the agent's code path for anyone without an agent host. Verified on Chrome with the WebMCP testing flag: tools register natively, getTools reflects availability changes, and executeTool drives the full loop.

What I learned

An approval gate is only meaningful when the agent could act without you. Here the agent can only propose, so the honest design is pencil versus ink, not a confirmation dialog. And state-gated tool availability is a better way to make an agent ask first than any instruction in a prompt.

What's next for Furrow

Month-level sowing windows, a multi-year rotation memory per bed, and a climate-aware catalog so the same page works in Kerala as well as Kent.

Impact

Home and allotment growers plan a season every year and most get rotation and timing wrong, which is the main reason beds underperform and beginners give up. Furrow makes the plan itself the shared object, so advice arrives where the decision is made and the person stays in charge of their own ground.

Built With

• webmcp