[Integration] danny-avila/LibreChat + danny-avila/agents — You.com web search provider

[brainsparker]

Target Repository URL

https://github.com/danny-avila/LibreChat

You.com API(s)

search

Estimated Complexity

medium

Integration Description

LibreChat (42K★) abstracts web search behind a webSearch.searchProvider config field. Serper is carried in .env.example labelled "Search Provider Required", so it sits on the mandatory setup path every new self-hoster walks. Tavily and SearXNG are the other options. You.com is absent.

The provider implementations do not live in the LibreChat repo. createSearchTool / createSearchAPI come from @librechat/agents (repo: danny-avila/agents, MIT, same maintainer). LibreChat only carries the enum, config schema, auth wiring, and UI. So this is a two-repo integration:

1. danny-avila/agents — the actual You.com provider.
2. danny-avila/LibreChat — enum/schema/env/UI glue, which can only land after an @librechat/agents release contains the provider.

Note the agents package already ships keenable and crw providers that LibreChat's enum does not expose, confirming the two repos move independently.

Target Repo Contributing Guidelines

https://github.com/danny-avila/LibreChat/blob/main/.github/CONTRIBUTING.md

Planned Approach

Repo 1 — danny-avila/agents: src/tools/search/you-search.ts exposing createYouAPI, wired into createSearchAPI (search.ts), createSearchTool (tool.ts), and the SearchProvider union plus option/payload/response types (types.ts). Search provider only — no scraper. Modeled directly on keenable-search.ts.

Dual-mode auth, the same shape Keenable already ships here:

• No key → https://api.you.com/v1/agents/search (keyless free tier)
• YDC_API_KEY set → https://api.you.com/v1/search with X-API-Key

Endpoint and headers are chosen together, since the keyless endpoint rejects an auth header.

Repo 2 — danny-avila/LibreChat: you in the SearchProviders enum and SearchProvider type, ydcApiKey/ydcApiUrl schema fields, webSearchAuth.providers registration, loadWebSearchConfig defaults, .env.example, librechat.example.yaml, and the ApiKeyDialog provider dropdown.

Repo 3 — LibreChat-AI/librechat.ai: docs page /features/web_search, after the glue merges.

Status Checklist

• Claimed this integration (self-assign)
• Filed issue or opened discussion in target repo
• Opened PR in target repo
• You.com API calls send the standard integration User-Agent (youdotcom-integration/<owner>-<repo>)
• You.com links in contributed docs carry the standard UTM parameters
• PR merged or rejected

Links

Target repo issue: none filed — vendor precedent (Keenable) went straight to PR in both repos
Target repo PR (agents, provider impl): danny-avila/agents#432
Target repo PR (LibreChat, config glue): danny-avila/LibreChat#14991

Additional Notes

Vendor precedent is direct and favourable. Keenable — another keyless-tier search vendor — ran exactly this play:

• danny-avila/agents#285 "add Keenable as a search provider" — merged (authored by a Keenable employee, ilya-bogin-keenable)
• danny-avila/agents#337 "add Keenable as a keyless content scraper" — merged
• danny-avila/LibreChat#14194 glue PR — still open

Their PRs establish that a vendor-authored keyless provider with an attribution header (X-Keenable-Title: LibreChat) is acceptable here. Our User-Agent attribution is the same mechanism.

Competitive/latency signal: danny-avila/agents#333 "add Exa as a search and scraper provider" (+944 lines, search and scraper in one PR) has been open ~3 weeks with the author bumping it. Keenable's merged PRs were ~350 lines and single-purpose. Sizing ours accordingly: search provider only.

Auth-resolver constraint on the LibreChat side. packages/api/src/web/web.ts contains if (requiredKeys.length === 0) continue; — a provider whose keys are all optional is skipped and never authenticates. So a keyless registration needs a carve-out in shared auth logic. Keenable's open glue PR #14194 already proposes exactly that carve-out. To avoid conflicting with a pending PR and re-litigating shared auth logic, our LibreChat registration marks the key required; if #14194 lands, dropping You.com to an optional key is a one-line follow-up.

Automated review: the maintainer runs @codex review on PRs in both repos.

---

User-Agent shipped: LibreChat youdotcom-integration/danny-avila-agents (case 1 — contributed into a third-party repo; the code lives in danny-avila/agents). Host name is overridable via youSearchOptions.attributionTitle. Sent on both the keyed and keyless paths, You.com hosts only, pinned by a parametrized test. Directly parallel to Keenable's X-Keenable-Title: LibreChat, which is already merged in this codebase.

UTM campaign: 2026-08-oss-integrations, utm_source=danny-avila-librechat, utm_medium=oss_integration, utm_content=app — on the "Get your You.com API key" link in the provider dropdown (ApiKeyDialog.tsx), the only human-clickable you.com link in the diff.

[brainsparker]

Two PRs open. Ratchet: Not Started → PR Submitted.

Repo	PR	Size	Status
danny-avila/agents	#432 — provider implementation	+508	open
danny-avila/LibreChat	#14991 — config/schema/UI glue	+237	open, blocked on an agents release

Why two. createSearchTool / createSearchAPI come from @librechat/agents (danny-avila/agents, MIT, same maintainer). LibreChat carries only the enum, config schema, auth wiring, and UI. The agents package already ships keenable and crw providers that LibreChat's enum doesn't expose, so the repos genuinely move independently. Sequencing matches Keenable's: agents#285 merged, then LibreChat#14194 as the follow-up.

Scope discipline from the competitive read. agents#333 (Exa, search and scraper in one PR, +944) has sat ~3 weeks with the author bumping. Keenable's merged PRs were ~350 lines and single-purpose. Ours is search-provider-only, no scraper — Firecrawl/Serper/Tavily/CRW/Keenable already own that slot and contesting it would double the diff for no distribution gain.

Keyless works at the agents layer, is gated at the LibreChat layer. loadWebSearchAuth has if (requiredKeys.length === 0) continue;, so an all-optional provider never authenticates. Keenable's still-open glue PR #14194 proposes the carve-out for exactly this. Rather than fight shared auth logic or conflict with a pending PR, our LibreChat registration marks the key required and the PR body offers to rebase onto #14194 or follow up with a one-line change if it lands. The provider itself is fully keyless-capable today.

Verification: agents — 207 search tests pass (20 new), tsc + eslint clean, live-tested on both auth paths including the news → topStories mapping. LibreChat — data-schemas 2195 pass, data-provider 1563 pass, web.spec.ts 56 pass, client typecheck + locale-parity green, prettier/eslint clean. The 25 failing packages/api integration suites were confirmed pre-existing by stashing and re-running (identical 8 failed / 156 passed either way).

Next: docs PR against LibreChat-AI/librechat.ai (/features/web_search) once #14991 is approved. Maintainer runs @codex review on both repos.