feat: add optional you.com MCP template to setup wizard

[mouse-value-add]

What

Adds a You.com entry to the MCP wizard template list (MCP_TEMPLATES), next to Brave Search and DuckDuckGo. I noticed the wizard already curates remote HTTP servers like DeepWiki and Context7 through remoteHttpTemplate, so this follows that same pattern rather than introducing anything new.

The template builds a remote HTTP config pointing at https://api.you.com/mcp:

• With a key: pasting a YDC_API_KEY builds an authenticated config with a Authorization: Bearer *** header (same shape as the github-remote template's header handling).
• Without a key: the API-key field is optional — leaving it empty falls back to the keyless free profile at https://api.you.com/mcp?profile=free, so basic you-search works with zero signup.

Once connected, the agent gets You.com's you-search / you-contents / you-research tools for web search, URL reading, and cited research — useful for the same "verify current library versions / unknown APIs" cases the built-in tools don't cover.

Why it's safe

• Fully opt-in: nothing changes unless a user explicitly picks "You.com" from /settings mcp.
• No new dependencies, no behavior changes for existing configs.
• API key field is marked sensitive: true like the other credential fields.

Changes

• source/wizards/templates/mcp-templates.ts — new you template (36 lines, one registry entry)
• source/wizards/templates/mcp-templates.spec.ts — 4 tests: authenticated config, keyless fallback, whitespace trimming, blank-key fallback; also added you to the "remote templates: have no required fields" list
• .changeset/youcom-mcp-wizard-template.md — minor changeset

Validation

• pnpm test:ava source/wizards/templates/mcp-templates.spec.ts — 38/38 pass (incl. the dead-host guard and transport-field checks)
• pnpm test:types — clean
• pnpm test:format / pnpm test:lint — clean
• node scripts/validate-changesets.js — clean
• pnpm test:knip — clean (pre-existing hints only)

Live-endpoint note: I could not run the wizard interactively here, but the config shape matches the working context7/deepwiki HTTP entries, and both You.com endpoints (https://api.you.com/mcp and ?profile=free) are live remote servers — easy to sanity-check with /mcp after installing the template.

Happy to adjust the shape if you'd rather split this into two templates (authenticated vs. free) or use the simpler remoteHttpTemplate without the optional-key logic.

[will-lamerton]

Thanks for this - the shape follows github-remote correctly and the tests are good. I verified both endpoints are live: the ?profile=free URL does initialize keyless (serverInfo: You.com v3.7.0), and the plain URL 401s without a bearer and works with one. CI is green and the spec passes locally (38/38).

One blocker plus some polish.

Blocking: editing a saved You.com server silently drops the API key.

The edit flow in source/wizards/steps/mcp-step.tsx:261 only repopulates an apiKey field from server.env. This template stores its credential in headers.Authorization, so on re-edit the field comes up blank. Since it is required: false, pressing Enter through it is accepted and buildConfig rewrites the config to the keyless free profile, quietly downgrading a user off their paid key. github-remote has the same gap but its field is required: true, so the wizard forces re-entry instead of losing data.

Simplest fix is to extend that mapping to read the bearer back out of server.headers?.Authorization when the field is named apiKey.

Non-blocking:

• The template lands at mcp-templates.ts:381, between duckduckgo and git, while the other remote templates are grouped at lines 251-302. It renders fine because the wizard filters by category, but it should move up next to github-remote.
• The spec adds you to remote templates: have no required fields but not to remote templates: use http transport (line 482). Worth keeping the two lists in sync.
• Unlike deepwiki / context7 / github-remote, there is no serverName field, so the name is hardcoded to you and you cannot configure a free and a keyed instance side by side. Fine if deliberate, just flagging it.
• docs/configuration/mcp-configuration.md:246 lists the bundled templates. It ends in "etc." so this is optional, but adding You.com there would keep it current.
• The branch is behind main and will need a rebase before it can land.

FWIW, one thing worth knowing about the upstream server: with an invalid bearer, initialize and tools/list still return 200 and only tools/call fails with Error code: 401. So a typo'd key produces a server that looks healthy in /mcp and fails at call time. Not something this PR can fix, but it makes the silent-key-drop above harder for a user to notice.

[mouse-value-add]

Thanks for the thorough review — all points addressed in a3d3869 (plus a merge of latest main, so the branch is current):

• Blocking key-drop: the edit flow in mcp-step.tsx now falls back to reading the bearer token out of server.headers.Authorization when a template's apiKey field isn't backed by env vars. Editing a saved You.com server repopulates the key instead of silently rewriting to the free profile, and it also covers github-remote if that field is ever relaxed. (Good context on the 401-at-call-time behavior, by the way — that's exactly what makes the silent drop nasty.)
• Template grouping: moved you up next to github-remote with the other remote templates.
• serverName field: added, default you, so a keyed instance and a free-profile instance can now live side by side. Custom names are covered by a new test.
• Spec lists: you is now in the use http transport list, and removed from the no required fields list since it has a required serverName (same shape as github-remote).
• Docs: added You.com (and DuckDuckGo, which was also missing) to the bundled-template list in mcp-configuration.md.

39/39 template spec tests pass, tsc --noEmit and biome are clean, and changeset validation passes.

[will-lamerton]

Thanks, most of this is sorted. I verified locally on a3d3869f: 39/39 in mcp-templates.spec.ts, tsc --noEmit clean, biome clean. Grouping, serverName, spec-list sync and docs are all good, and I traced the bearer prefill through beginTemplate -> masked TextInput, so the key does survive a re-edit now.

Two things before this lands.

1. The key-drop fix doesn't cover the case serverName was added for.

Edit resolves the template with MCP_TEMPLATES.find(t => t.id === server.name) at source/wizards/steps/mcp-step.tsx:230. Under the default name you that matches and your fix works. Under any custom name (you-paid) it misses and falls through to the custom template, which has no apiKey field and whose buildConfig (source/wizards/templates/mcp-templates.ts:491) never writes headers at all, so the Authorization header is dropped entirely. That is worse than the original bug, and it is exactly the "keyed + free profile side by side" scenario the new field exists to enable, since one of the two must be custom-named.

The path is pre-existing and hits context7 / deepwiki / github-remote custom names too, so I'm happy for the real fix to be a follow-up. But I don't want to ship a field whose documented purpose silently eats credentials. Either persist a template id on the saved server (or match on tags) so custom-named instances resolve back to their template, or drop serverName from this PR and keep the name hardcoded to you.

2. The comment overstates coverage.

source/wizards/steps/mcp-step.tsx:262 says remote templates "like you and github-remote store the credential there". The new branch keys off field.name === 'apiKey', but github-remote's field is githubToken (mcp-templates.ts:281), so it never fires for that template regardless of whether required is relaxed. Harmless today, but please correct the comment so nobody relies on it later.

Also: only changeset-check and label have reported on the new head, the main pr-checks workflow hasn't run on a3d3869f. And the branch is 18 commits behind main again, no conflicts.

[mouse-value-add]

Both points addressed in 57cd138 (also merges the 18 commits of main that landed since the last push).

1. Template resolution for custom-named instances. The wizard now stamps the originating template's id (templateId) onto the built config, and the edit flow prefers it over the name lookup:

const templateId = resolveMcpTemplateId(server);
const template =
  (templateId ? MCP_TEMPLATES.find(t => t.id === templateId) : undefined) ||
  MCP_TEMPLATES.find(t => t.id === editingServerName) ||
  MCP_TEMPLATES.find(t => t.id === 'custom');

When there's no stamp (hand-edited configs, or files written before this change), resolveMcpTemplateId falls back to tag matching, then to the server name. The tag fallback is transport-checked: github-remote carries a github tag, but that id is the stdio GitHub server, so an http server with those tags can't resolve to it and rebuild with the wrong transport. This also covers the pre-existing context7 / deepwiki / github-remote custom-name path you mentioned, so no follow-up needed there.

Spec coverage: a new integration test deep-links into a custom-named you-paid server, picks "Edit this server", and asserts the You.com template's form opens with the name prefilled (rather than Custom MCP Server Configuration), plus unit tests for the resolution order including the transport-check case. 60/60 in mcp-step.spec.tsx, 45/45 in mcp-templates.spec.ts.

2. Comment corrected. It now says only templates whose credential field is literally named apiKey (today just you) take the headers path, and calls out that github-remote uses githubToken and never hits that branch.

I went with persisting the id rather than dropping serverName — the keyed + free side-by-side setup was the point of the field, and the stamp keeps it honest. The extra field is wizard bookkeeping only; the runtime loader ignores it and generate:schema still produces a byte-identical schemas/agents.config.schema.json (verified locally). The changeset mentions the fix.

[mouse-value-add]

Left a comment on the pr-checks workflow situation on the PR — nothing more needed from my side, the branch itself is green (tsc --noEmit clean, biome clean on the touched paths, and 105/105 wizard template/step tests pass locally on 57cd138, matching your verification). The pr-checks workflow still hasn't reported on the last two heads because it runs from the base repo against cross-repository fork heads — happy to rebase onto main again if that helps trigger it, just say the word.

[mouse-value-add]

Merged the latest main (the status-badge update) into the branch so it's current again — 3f05a6c. Everything still green locally on the merged head: tsc --noEmit, biome, and 105/105 wizard tests.