LinkedIn has started telling job seekers that it is gradually retiring classic job search. The filter-based search (location dropdowns, seniority checkboxes, the date-posted toggle) is being replaced by AI search where you just describe the job you want. It’s been one of the most talked-about product changes on LinkedIn this month, with predictable reactions: some people love it, and some are mourning their carefully tuned filters.

I don’t have a strong view on job search UX. What I noticed is that LinkedIn’s change is the consumer-facing version of something I’ve been dealing with on the API side of Calendrz: when the caller is an AI, it describes what it wants. It doesn’t fill in a form. That changes how you should design the interface underneath.

Filters assume the caller has read the manual

A filter UI is a contract. The product decides the fields, the user learns them, and the product checks what comes back. That works for people because the UI shows them which fields exist. The checkbox is right there.

An AI model calling a tool doesn’t get a UI. It gets a schema and a description, and then it does what models do: it guesses based on everything it has seen before. That’s where things went wrong for us.

A real example: get_events and the parameter guessing game

Calendrz runs an MCP server, so assistants like Claude and ChatGPT can read and manage your calendar setup across all your connected Google and Microsoft accounts. One of the most used tools is get_events, which takes an optional date range named startDate and endDate.

Our nightly log review (an AI agent that reads production logs and opens fixes; I wrote about it last week) kept surfacing the same warning: clients calling get_events with parameters that don’t exist. Over a few weeks we saw all of these:

• timeMin / timeMax / timeZone: the Google Calendar API’s naming
• time_min / time_max: the same thing in snake_case
• start_date / end_date
• start / end: guessed from the field names in the tool’s response

Every one of these is a reasonable guess. None of them is what the schema says. The validator correctly rejected them, but its error message only named the property it rejected. So the model got “unknown property: timeMin” and had nothing to go on for its next attempt. It guessed again, and often wrong again.

Two fixes, and the one that actually worked

The first fix was better documentation. We rewrote the tool and parameter descriptions to spell out the exact input names. That helped, but descriptions are a hint, not a guarantee. Models still pattern-match on what they’ve seen most often, and Google’s API has been seen a lot.

The second fix was to make the error message useful. We wrapped the MCP SDK’s JSON schema validator so that when validation fails, the error now lists every accepted parameter: its name, type, whether it’s required, and its description. That message goes back to the client as the tool result, so the model can correct itself on the next call without a human getting involved.

We deliberately didn’t make validation lenient. Unknown parameters are still rejected instead of being silently ignored or mapped to “what it probably meant”. A client asking for timeMin and getting back every event in your calendar, because the filter was dropped without a word, is worse than an error. Strict input with helpful errors gives you both correctness and recovery.

What LinkedIn’s change means for product builders

When the front door becomes natural language, the structure doesn’t go away. It moves to the back. LinkedIn’s AI search still has to turn “remote senior Java roles in fintech, posted this week” into a structured query. Someone, or something, is still filling in the filters. It just isn’t the user any more.

For anyone building tools that AI agents call, here’s what I’d take away:

1. Assume the caller will guess. Name parameters the way the most popular API in your space names them, or accept that you’ll spend time correcting guesses.
2. Treat error messages as part of the interface. For an AI client, the error is the documentation it actually reads, at the moment it needs it. “Invalid input” is a dead end. “Here’s what I accept” lets the client recover.
3. Stay strict. Being lenient feels friendly but hides mistakes. Reject clearly, explain fully, and let the client retry.
4. Watch your logs. We only noticed this because something was reading the warnings every night. Agent traffic fails quietly. It doesn’t file support tickets.

The filter isn’t dead, it’s just not the UI any more

I suspect LinkedIn’s power users will miss their filters for a while, and that’s fair. But the direction is clear: more and more of the people asking questions of our software won’t be people, and the ones who are will increasingly ask through an assistant. The products that do well will be the ones that are easy for that assistant to use, including when it gets things wrong.

At Calendrz, that has meant designing every tool as if a smart, confident caller who hasn’t read the manual is going to use it. Most of the time, that’s exactly who’s calling.

Calendrz keeps your work and personal calendars in sync and works with AI assistants through MCP. Try it free.