Web search can find pictures and video
Results are now parsed by their own type. Image search actually returns image URLs (they used to be dropped entirely), video results carry duration, resolution and cover, and WebFetch can save to disk — which completes the search → download → send chain that used to break on the last metre.
Ask the robot to find a picture online and it used to find one but never get it — the image URL was dropped during parsing. That path works now: search, download, send.
What it was like
The search tool declared web, image and video types from the start, but the response parser only understood the web shape. The three types return genuinely different structures:
| Type | Where the content actually is | What you used to get |
|---|---|---|
| Image | The image URL is a separate field | A title and an intermediate landing page — the image lost |
| Video | Duration, cover and resolution each live elsewhere | All dropped |
| Web | Inline pictures are in an extension field | Dropped |
Now
- Image search really returns images — results are parsed by their own type, so mixed responses render correctly too
- Video results carry duration, resolution, a cover image and a playable landing page
- Web results additionally bring their first few pictures and an authority score
WebFetchcan now save to disk, so once an image is downloaded the robot can send it to you over chat
That completes the chain: search → download → send. It used to break on the last metre — outbound attachments must be local files, and the page-fetching tool could not handle binaries.
What is not here
This search backend does not actually support news verticals, site restriction or safe search — passing those parameters raises no error and changes nothing. Since they cannot be honoured, they are not exposed as if they could.