DSH plugins for Web Search

Search plugins fill the single largest capability gap in a text-only harness. They come in two shapes: provider plugins that wire a search backend into the existing search tool, and bridge plugins that expose search to any model that lacks it, usually returning structured evidence rather than raw HTML.

When comparing them, check whether results carry citations, whether fetching a page is a separate tool call, and how the provider handles rate limits. A plugin with no API key and a public backend is convenient but can be throttled; a keyed provider is more predictable at volume.

How to evaluate

Start with evidence quality. Do hits include URLs the model must cite? Is page fetch separated from search so you can allow one and deny the other? Next, resilience: failover across providers, retry behaviour, and whether the plugin fails loudly when every backend is down. Finally, fetch safety: SSRF hardening on arbitrary URLs is not optional if the tool can leave your network.

Free keyless defaults are fine for experiments. For anything load-bearing, plan on a keyed provider and read how the plugin stores that key.

What good looks like

A strong search plugin returns structured results with citations, keeps network fetch as an explicit second step, and documents its engines. Settings live in a UI the user controls, not only in a file the model rewrites. Rate limits and key rotation are visible. Where the project refuses external contributions or depends on a single maintainer, that is a sustainability note you should weigh — not a reason to ignore the tool, but a reason not to bet a workflow on silent updates.

Several listings compete here. Differences in citation format, default backend, and security posture on fetch matter more than the phrase “web search.”

Common failure modes

The usual failure is stuffing raw HTML into context without truncation, which drowns the answer. The second is a public free backend that throttles the first week you actually need it. The third is claiming “no API key required” while the fetch path will happily request http://169.254.169.254/ if the model asks — convenience without a fetch guard is a security bug, not a feature.

Install order and boundaries

Pick one citation contract before multi-engine sprawl. Keyless is fine for experiments; once search is load-bearing, move to a keyed provider and confirm the fetch path has an SSRF guard.