Fredy's MCP server could answer questions about your searches. It could not do
anything about them. Now it can.
Write tools
Point your Agent of choice at Fredy and ask it to:
| Tool | What it does |
|---|---|
add_listing_note
| Append a note to a listing, keeping what is already there |
set_listing_notes
| Replace a listing's notes outright; an empty string clears them |
watch_listing
| Put a listing on the watch list. Repeating it is not an error |
unwatch_listing
| Take it off again. Repeating it is not an error |
start_job_draft
| Begin the interview that creates a search |
update_job_draft
| Record one answer and get the next question |
create_job_from_draft
| Create the search, once you have confirmed the summary |
discard_job_draft
| Throw the interview away |
Every one of them goes through the same ownership, sharing and channel
permission rules as the web interface.
Creating a search is an interview
A search needs four things an assistant cannot invent: a name, at least one
search URL from a portal Fredy supports, whether you are renting or buying,
and a notification channel. Rather than one tool with a large payload, Fredy
holds a draft and computes the next question:
- name — up to 40 characters, the same limit the web form enforces.
- providerUrls — the portal is worked out from the URL's host, so you are
never asked to name it. A URL that is only the portal's homepage is
refused: it would save cleanly, run on schedule and quietly find nothing. - dealType — renting or buying. The URLs usually give it away, and the
draft offers that reading, but it still asks. - channelIds — one or more of your own channels. If you have none, it
tells you where to create one and waits. - refinements — price, size, rooms, blacklist words, travel time limits,
sharing, and whether the search starts switched on. Asked once, and
answerable with "skip". - ready — the summary is read back to you, and only then does
create_job_from_draftwithconfirmed=truecreate anything.
The questions come from Fredy, not from the assistant. That is what makes this
work with a small local model as well as with a large one: nothing has to
remember what was already answered.
The draft lives in memory, keyed by user, for 30 minutes after the last
answer. A client that reconnects mid-interview picks up where it left off.
Out of scope on purpose: area filters (a polygon is drawn, not described),
editing or deleting existing searches, creating notification channels (their
secrets must not travel through an assistant), and triggering a run.
Upgrading: existing connections stay read-only
If you have already connected a remote LLM client, it keeps read-only access
until you disconnect and reconnect it.
Writing is a separate OAuth scope (mcp:write). Every grant approved before
this release was approved on a consent page that only mentioned reading, and
letting those grants quietly gain the ability to create searches and rewrite
notes would be an upgrade nobody agreed to.
Settings → Connections now has an Access column showing which of the
two each client holds.
An MCP token you pasted into a client yourself is unaffected. It has always
been full access, because you handed it over directly and there was no consent
page in between.
Full documentation: lib/mcp/README.md
Full Changelog: 28.2.0...28.3.0