I'll put my cards on the table before the coffee cools: the scary headline item in laravel/mcp 1.0, the removal of server-side sessions, is the easiest part of the upgrade for us. The part that will decide whether agents actually do useful things against your app is the tool catalog, and that one ships with a default you are allowed to ignore. I think ignoring it is the real mistake waiting in this release.

Start with sessions, because that is where the anxiety lives. The package now speaks MCP revision 2026-07-28, and under that revision there is no conversation the server remembers between calls. $request->sessionId() and $request->setSessionId() are gone, and so is SessionInitialized. If you were stashing an expensive lookup or a running tally of agent steps against a session ID, that code stops compiling in your head the moment you read the changelog. Fair enough. Now think about what PHP has been doing since before most of us wrote our first foreach: every request boots, does its job, and forgets everything. We built entire careers on that amnesia. Queues, Redis, a correlation ID in the payload, a row in a table keyed by something the caller hands back to you. That toolbox is already in your vendor folder.

So for a Laravel shop the migration looks like this in practice. You search the app directory for the removed methods, and each hit becomes a small design question: which identifier does the agent need to send me so I can find my own notes? Usually the answer is a job ID or a report ID you were generating anyway. I have watched teams in other ecosystems spend real effort bolting sticky routing onto their long-lived processes; Go folks, to their credit, tend to reach for explicit IDs early too, and it is nice to see the protocol settle on the approach both camps already trusted. Your load balancer stops caring which box answers. That is a gift.

Older clients will not fall off a cliff, either. The release still recognises the 2025-06-18 and 2025-11-25 revisions for clients that come in the old way, which matters if agents you do not own point at your server. Test that path separately. It is the kind of compatibility code that works on launch day and rots by Christmas if nothing exercises it.

Now the part I actually want you to lose sleep over. 1.0 lets an agent find tools through search_tools and execute_tools instead of receiving your whole inventory up front. Picture the typical internal admin app I get pulled into: thirty-odd tools, half of them named some variant of GetOrder, FindOrder, OrderLookup, each with a paragraph of description and a fat JSON schema. Every connection pays for all of that in context before the model has typed a single token of useful work, and then the model has to pick the right one out of a lineup of near-twins. It picks wrong more often than you'd like, and you end up blaming the model for a menu you designed.

The Statamic MCP server made the choice I'd like to see become normal: three tools visible on connect, the remaining eight reachable through search. That is a product decision, the same kind you make when you decide what goes in a navigation bar and what lives in settings. Somebody has to own it. In most teams I know, nobody will, because the old behaviour keeps working and no test turns red when an agent burns a third of its context reading descriptions of tools it never calls. Add the new cache hints to the static stuff, reference tables and schema descriptions, and you cut repeat round trips on top.

Quick word on auth so you don't get ambushed: PKCE is mandatory now, and if a third-party authorization server fails to advertise code_challenge_methods_supported in its metadata, redirect() will throw instead of carrying on. Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents. Deprecated still means it works today, so put the switch on your roadmap and do it on a boring Tuesday rather than the week removal lands.

Here is where I'd like to hear from you, because I have a strong opinion and thin data. When you split your tools into what an agent sees on connect and what it has to search for, what rule do you use? Most-called, most-dangerous, most-ambiguous, something tied to user roles? Tell me how you drew that line in a real app, and whether the agent got better or just got different.