i needed web search in an ai agent. sounds simple. it’s not anymore.

microsoft killed the standalone bing search api in august 2025. if you had an app calling it, it just stopped working. the official replacement is “grounding with bing search” inside azure ai foundry. i tried it, got frustrated, and ended up with serpapi instead. here’s why.

the foundry way

you create a bing grounding resource in azure, connect it to your foundry project, add it as a tool to your agent. the agent decides when to search, bing returns results, the model writes the answer with citations.

setup is quick. that part is fine.

but you never see the raw search results. they go straight into the model and you only get the final answer out. no urls to cache. no snippets to filter. no way to log what was actually retrieved. it’s a black box.

and you pay premium for that box. around 35 dollars per 1000 grounding transactions, plus model tokens on top. the old bing api was 7 to 18 per 1000. so the replacement costs 2 to 5 times more than the thing it replaced, and gives you less control.

also, it only works inside foundry agent service. want the same search in a console app, an azure function, a background job? you can’t. it’s not a search api, it’s an agent feature.

the serpapi way

serpapi is a search api. you call it, you get structured json back. titles, urls, snippets, knowledge graph, related questions, everything on the page. bing is one of the engines, but you also get google, duckduckgo, youtube, maps and a bunch of others through the same interface. switching engines is changing one parameter.

you own the retrieval step. cache results, filter domains, rerank them, log everything for later, feed them to any model you want. or skip the model entirely and just use the data.

in .net with semantic kernel it’s one plugin function:

[KernelFunction, Description("search the web")]
public async Task<string> SearchAsync(string query)
{
    var url = $"https://serpapi.com/search.json?engine=bing&q={Uri.EscapeDataString(query)}&api_key={_apiKey}";
    var response = await _http.GetStringAsync(url);
    return response;
}

that’s it. the model calls it as a tool. i decide what happens with the results.

a few things i didn’t expect to like as much as i did:

the playground. you build your query in the browser, see the parsed json live, then copy the exact request. i had a working query before writing a single line of code.

the docs. every engine, every parameter, every response field documented with examples. after fighting azure docs that describe three different versions of the same service, this felt unreal.

the parsing is their problem. serps change layout all the time. i don’t maintain any of that. the json contract stays stable, they handle the rest. they even run a legal us shield for their customers, which tells you how seriously they take this being a real product and not a weekend scraper.

the math

foundry bing grounding: ~35 dollars per 1000 searches, results locked inside the agent.

serpapi: 75 dollars a month for 5000 searches, so 15 per 1000. less than half the price, and you get the raw data.

so microsoft’s option costs more and returns less. that’s the whole comparison, really.

when foundry grounding still makes sense

if you’re building a quick chat demo fully inside foundry agent service and never need to see the results, the built in tool is less code. that’s the one scenario. everywhere else i’d rather own the search layer.

my take

microsoft took a simple api, made it more expensive, and locked the results inside their agent service. i get why, they want you in foundry.

but search results are data. i want them as data. one function, structured json, any engine, half the price. serpapi it is.