docs: document an authenticated HTTP MCP server - #2278
Conversation
The optional-fields table documents `bearerTokenEnvVar` and `enabledTools`, but the only worked examples on the page are an unauthenticated HTTP entry and two stdio entries, so neither field is shown in use. Add a short subsection to Configuration that connects one real HTTP server both with and without credentials, and narrows it with `enabledTools`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8d8babe126
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
| ``` | ||
|
|
||
| `you-free` needs no credentials and exposes `you-search` on its own. The authenticated entry reads its token from `$YDC_API_KEY` and additionally exposes `you-contents`, `you-research`, `you-discover`, and `you-balance`. To authorize through the browser instead of a static token, omit `bearerTokenEnvVar` and run `/mcp-config login you`. |
There was a problem hiding this comment.
Remove the unsupported browser-login alternative
For users who follow this alternative without YDC_API_KEY, /mcp-config login you cannot replace the static token: that command performs the MCP OAuth discovery/authorization flow, while this endpoint authenticates with a You.com API key and the commit only verified bearer-token access. The result is a failed login rather than a connected server, so either omit this sentence or point to an OAuth-capable endpoint and verify its authorization flow.
Useful? React with 👍 / 👎.
|
Closing this. A colleague had already opened #2093 to add You.com through the plugin marketplace before I filed this, which is the cleaner path for a vendor addition — it keeps the integration out of the core docs and behind an opt-in install. The gap this PR described is still real and vendor-independent: |
Relates to #2279 — please read that first; this PR is subordinate to it.
Disclosure: I work at You.com, and this PR uses our MCP server as its example. I originally framed it as a documentation-only change, which under CONTRIBUTING is exempt from the issue-first rule. That framing was not right: a vendor example is a vendor addition regardless of which file it lands in, and it should have followed a discussion rather than preceded one. I have now opened #2279 to make the actual proposal explicit. Close this if you would rather settle the question there first.
What it changes
docs/en/customization/mcp.mdanddocs/zh/customization/mcp.mdgain an### Example: an authenticated HTTP serversubsection at the end of Configuration.The gap it addresses is real and independent of the vendor question: the optional-fields table documents
bearerTokenEnvVarandenabledTools, but no example on the page uses either. The worked examples are two stdio entries and one unauthenticated HTTP entry, so anyone connecting an authenticated remote server has to infer the shape from the table alone.If you want that gap closed without naming a vendor, say the word and I will rewrite it with a placeholder server.
Verification
Everything asserted in the prose was checked against the live server first:
?profile=freeconnects without credentialstools/list→ 200, exposesyou-searchonlyyou-contents,you-research,you-discover,you-balancebearerTokenEnvVaris sufficientAuthorization: Bearer $YDC_API_KEY→ 200/mcp-config loginalternativenpx vitepress buildpasses; both locales render.Written with AI assistance, reviewed and verified by me end to end.