Add You.com as a built-in web search integration

[brainsparker]

Disclosure up front: I work at You.com. I am proposing our service, and I have tried to write this so it is easy to say no to, or to redirect to a vendor-neutral version.

What feature would you like to see?

Kimi Code has no first-class web search. The VS Code extension ships a curated RECOMMENDED_MCP_SERVERS list (apps/vscode/webview-ui/src/services/recommended-mcp.ts) containing Playwright, Context7, and GitHub — browser automation, library docs, and repo operations, but nothing that answers "what is the current state of X on the open web." Agents working against fast-moving libraries or APIs fall back to whatever is in the model's weights.

I would like to add You.com's MCP server as a recommended web search option:

{
  "mcpServers": {
    "you": {
      "url": "https://api.you.com/mcp",
      "bearerTokenEnvVar": "YDC_API_KEY"
    }
  }
}

It already works with Kimi Code today through the generic HTTP MCP transport — no wrapper or adapter needed. Tools exposed: you-search, you-contents, you-research, you-discover, you-balance. There is also a keyless profile (?profile=free, you-search only) so it can be tried without an account.

Two parts, and they need different decisions from you

1. Recommended list. Adding an entry to RECOMMENDED_MCP_SERVERS is user-visible, which is why I am opening this issue rather than a PR. There is also a real design question: the RecommendedMCPServer interface currently models stdio servers only —

export interface RecommendedMCPServer {
  id: string; name: string; description: string;
  command: string; args: string[]; github?: string;
}

— with no url field, so a remote HTTP server cannot be represented at all. That affects any hosted MCP server you might want to recommend, not just ours. Options as I see them: extend the interface with an optional url/transport and branch in recommendedToConfig, or keep the list stdio-only and have vendors ship npx wrappers. Happy to implement whichever you prefer, or to leave it to you if the interface is something you would rather own.

2. Docs. I jumped the gun here and already opened #2278, which adds an authenticated-HTTP example to docs/*/customization/mcp.md using You.com as the example server. My reasoning was that it is documentation-only and therefore exempt from the issue-first rule, and that it fills a genuine gap — bearerTokenEnvVar and enabledTools are in the options table but never demonstrated. In hindsight, a vendor example is a vendor addition regardless of which file it lands in, and it should have come after this discussion. Treat #2278 as subordinate to this issue: close it if you would rather decide here first, or ask me to rewrite it with a placeholder server so the missing bearerTokenEnvVar example lands without naming anyone.

Additional information

If the answer is "we do not want vendor-specific entries," that is a reasonable position and the useful residue is still the interface gap in part 1 — the recommended list cannot express hosted servers, and that will keep coming up.

Verified against the live server on 2026-07-27: keyless profile returns you-search only; Authorization: Bearer succeeds where X-API-Key returns 401; npx vitepress build passes with the #2278 docs change applied.

[brainsparker]

Closing this in favor of #2093, which adds You.com through the plugin marketplace. That is the better fit — opt-in install, no change to the curated in-editor list, and no design question about whether RecommendedMCPServer should model HTTP servers.

Thanks for the consideration.