When a model cannot call a tool, it does not tell you. There is no red banner. There is no exception you can catch and route around. The agent loop just stops doing the thing you built it to do.
If you run agents, you know the shape of this bug. A sub-agent hangs. Another returns a confident answer it invented, because it could not call the function that would have given it the real one. You go looking at your prompts. You go looking at your orchestration. You rewrite a tool schema. The whole time, the model was never able to make that call.
I lost real time to this. So I went and measured it.
The list lies, and it lies in both directions
Every provider publishes a model list. Each entry carries a set of capabilities, and one of them says whether the model can call functions. That field is self-reported. Nobody checks it.
I checked it. As of 10 August 2026, of the 70 models I have probed with a live tool payload:
25 declare function calling and cannot serve one
14 serve one perfectly well and never declare it
Read that second line again. The list is not merely optimistic. It is wrong in both directions, which means you cannot fix it by discounting it. A model list can tell you what a provider believes. It cannot tell you what a provider will actually do when your agent sends a tools array.
Two things break it. Sometimes the model is listed but tool-incapable, and the provider returns a flat refusal the moment a tool payload arrives. Sometimes the provider quietly de-lists the model altogether, and every call fails from then on. The second is worse than it sounds, because a failing model does not simply fail. It burns a cooldown on the way down, so it takes healthy capacity with it.
The fix is boring, which is why it works
A list cannot answer this question. Only a call can.
So SpiderGate™ sends one. It is a small payload with a single weather function and a prompt that all but forces a tool call from anything capable of making one. If the response comes back with a tool call in it, the model can do tools. If it does not, the model cannot. There is no inference and no scoring.
Three properties matter more than the cleverness:
It never bills you. Every probe is a direct provider call. It does not run through the metering path, so it writes no usage row and charges nothing to any account. A health check that bills a customer is not a health check.
It never pollutes your error rate. Because the probe sits outside the request path, a failing probe does not show up as a failed request in your numbers. The measurement stays clean.
It runs on a schedule, not on an incident. A model list is a fact about the day it was fetched. Providers change theirs without telling anyone. So the probe re-runs and the answer carries a timestamp.
Alongside it, two smaller jobs. One diffs the models I have configured against each provider's live list and emails me when something I depend on has quietly disappeared. The other watches for new free-tier providers worth evaluating; it has surfaced 96 models across 27 providers and sent 16 alerts, most recently on 6 August 2026.
What it actually changed
One alias carried both of the dead models I mentioned. Measured over the four days before the fix, 66% of client requests on it failed. Over the last 30 days, 9.3% did, across 29,939 requests. Same query, same definition, same table.
I want to be precise about what that number is and is not.
It is the client-facing rate, so a request that failed once and succeeded on a fallback counts as a success, because that is what the caller saw. And it is one alias. A second alias I watch has not improved, and its failures today are provider credit limits and rate ceilings, which is a different problem that this work does not touch and does not claim to.
The class this fixes is narrower than "reliability" and I would rather say so. Requests failing because a model was listed but could not do tools: that class is now at zero, and has been since 18 June 2026.
The limit, stated plainly
There is a loop that watches all of this and proposes routing changes when a model goes bad.
It proposes. A human approves. It does not re-route customer traffic on its own, and I am not going to describe it as though it does. I could make this sound more autonomous than it is and it would read better. It would also be the kind of claim that turns into a support ticket the first time somebody's traffic moves without a person deciding it should.
The limit is the point. A system that quietly reroutes your production traffic on its own read of a health signal is not obviously better than one that tells a human what it found.
What I would do if I were you
You do not need my tooling to get most of this.
Send one real tool call to every model you depend on, before your agents do. Do it on a schedule, because a provider will de-list something you rely on and will not send you a note. Keep the result with a date on it. Then trust that, and not the capability field.
The model list is a claim. The tool call is the test.
Want the probe results without building it yourself? SpiderGate routes across 100+ providers and keeps the tool-capability answer current for you. See the model catalogue.