{"slug": "my-agent-could-fetch-a-url-but-could-not-search-for-one", "title": "My agent could fetch a URL but could not search for one", "summary": "A developer testing DeepSeek Harness v0.1.1-rc.2 found that the agent's web_fetch tool worked via anonymous HTTP while web_search failed with a 402 Insufficient Balance error, because the default searchProvider (deepseek-official) required a funded DeepSeek API account. The developer wrote a Tavily search provider and plugin checked against the installed type declarations, but it was not tested with a Tavily key, so the fix remains unverified. The developer concluded that agent tooling should surface provider and account dependencies before a task needs them, since 'tool enabled' is weaker than 'the selected provider can complete a request with this account.'", "body_md": "In my September 1 setup of DeepSeek Harness v0.1.1-rc.2, `web_fetch` worked while `web_search` could not complete a search. The difference was the service behind each tool, rather than whether the agent could reach the web.\n\nThis is a record of that setup, not a claim about the current release or every account.\n\nThe default profile selected `searchProvider: deepseek-official` and looked for its key in `DEEPSEEK_API_KEY`. My fresh DeepSeek API account returned `402 Insufficient Balance`.\n\nHaving a key was therefore insufficient. The request reached a service that required a funded account. In the version I inspected, the three bundled search backends were DeepSeek, Exa, and Perplexity; none supplied a free search path for my setup.\n\n`web_fetch` still worked. Fetching an already-known public URL used anonymous HTTP, without that search-provider balance requirement. That made the failure easy to describe too broadly: “the agent cannot use the web” would have hidden the useful capability that remained.\n\nFor a similar failure, I would separate these checks:\n\n`web_search` does not tell you which external service will receive the request.\nThose are diagnostic steps, not a guarantee that every `402` has the same cause. The concrete observation here was the `Insufficient Balance` response from my account.\n\nI wrote a Tavily provider and plugin, and checked the interface against the installed type declarations. I had not tested it with a Tavily key. That means I had an implementation to try, not a verified alternative, and I cannot report that it fixed search.\n\nThe useful result from this investigation was a smaller, more accurate description of the system: fetching worked; the configured search service required funding; the proposed replacement remained untested.\n\nFor agent tooling, I would like a setup check to expose those dependencies before the first task needs them. “Tool enabled” is a much weaker statement than “the selected provider can complete a request with this account.”", "url": "https://wpnews.pro/news/my-agent-could-fetch-a-url-but-could-not-search-for-one", "canonical_source": "https://dev.to/build996/my-agent-could-fetch-a-url-but-could-not-search-for-one-ddg", "published_at": "2026-11-15 16:14:21+00:00", "updated_at": "2026-11-15 16:19:36.767249+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools"], "entities": ["DeepSeek", "DeepSeek Harness", "Exa", "Perplexity", "Tavily"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/my-agent-could-fetch-a-url-but-could-not-search-for-one", "markdown": "https://wpnews.pro/news/my-agent-could-fetch-a-url-but-could-not-search-for-one.md", "text": "https://wpnews.pro/news/my-agent-could-fetch-a-url-but-could-not-search-for-one.txt", "jsonld": "https://wpnews.pro/news/my-agent-could-fetch-a-url-but-could-not-search-for-one.jsonld"}}