mirror of
https://github.com/upstash/context7.git
synced 2026-09-14 19:09:34 +08:00
Fahreddin Özcan
b89a04e620
* fix(cli): write the API key as an Authorization header
Codex resolves a server's auth mode by checking only for
`bearer_token_env_var` or a header literally named `Authorization`
(`auth_status_before_discovery` in codex-rs/rmcp-client/src/auth_status.rs,
mirrored in `create_transport` in rmcp_client.rs). The custom
`CONTEXT7_API_KEY` header matched neither, so Codex fell through to any OAuth
credential stored for the same server name and URL and refreshed it during
startup. A dead refresh token then failed the server with `invalid_grant`
before the API key was ever sent, and re-running setup could not recover it
because setup writes config.toml and never touches the credential store.
The hosted endpoint accepts both header forms, so existing configs keep
working.
Two places keep the legacy header deliberately: the plugin .mcp.json files
default to `${CONTEXT7_API_KEY:-}`, and the server rejects `Bearer` with an
empty token while treating a missing header as anonymous; and `env` blocks in
stdio configs, where the name is an environment variable rather than a header.
* fix(plugins): send the API key via the Authorization header
The Claude and Copilot plugin configs default to `${CONTEXT7_API_KEY:-}`, and
both plugins document that an unset key still works over the anonymous tier.
The Bearer form cannot express that: the server rejects `Bearer` with an empty
token while treating an empty or missing Authorization header as anonymous.
The raw-key form satisfies both states. It is genuinely parsed rather than
ignored, verified by an invalid raw key being rejected, so a set key still
authenticates while an unset one falls back to anonymous as documented.
Once the server treats an empty-token Bearer as no header, these can move to
the `Bearer <key>` form used everywhere else.
* refactor(cli): narrow the Codex OAuth probe and trim its surface
Only `oauth` proves a stored credential exists. `not_logged_in` also covers
"no credential, server merely advertises OAuth", which is the normal state for
anyone who never logged in, so treating it as stale told most users their
config held a credential it did not.
Collapse the module to the two functions the call site needs, derive nothing
from a hand-maintained status list, and skip the subprocess entirely when the
server is not already in Codex's config. Drop the probe timeout to 1.5s and
kill with SIGKILL so it is a real ceiling rather than an intent, since the
result is only an advisory hint.
Lock the plugin manifests' raw-key form behind a test, so normalizing them to
`Bearer` for consistency with the CLI fails loudly instead of silently
breaking anonymous access.
* refactor(cli): drop the Codex OAuth cleanup note
The note existed because re-running setup could not rescue a stuck user. The
Authorization header change in this same branch makes it rescue them: Codex
never reads the stored credential once that header is present, so the
credential is inert and the hint only offered cosmetic cleanup.
Removing it drops a subprocess spawn from a user-facing path and a dependency
on the shape of `codex mcp get --json`, an external contract this repo does not
pin. The reason the header name matters moves to `withHeaders`, where the
decision is encoded.
63 lines
2.3 KiB
Plaintext
63 lines
2.3 KiB
Plaintext
---
|
|
title: CodeRabbit
|
|
sidebarTitle: CodeRabbit
|
|
description: AI-powered code review tool
|
|
---
|
|
|
|
[CodeRabbit](https://coderabbit.ai) is an AI-powered code review tool that automatically reviews pull requests. By connecting Context7 as an MCP server, CodeRabbit can access up-to-date library documentation during reviews, helping it verify implementations against the latest API references and best practices.
|
|
|
|
## Setup
|
|
|
|
<Steps>
|
|
<Step title="Navigate to MCP Servers">
|
|
Go to your [CodeRabbit dashboard](https://app.coderabbit.ai) and navigate to **Integrations** → **MCP Servers**.
|
|
|
|
|
|
</Step>
|
|
<Step title="Add Context7">
|
|
Click the **Add** button next to **Context7** MCP server.
|
|
|
|
Add the following header for higher rate limits:
|
|
|
|
| Header | Value |
|
|
|--------|-------|
|
|
| `CONTEXT7_API_KEY` | Your API key from the [Context7 dashboard](https://context7.com/dashboard) |
|
|
|
|
```json
|
|
{
|
|
"Authorization": "Bearer YOUR_API_KEY"
|
|
}
|
|
```
|
|
|
|
|
|
</Step>
|
|
<Step title="Connect">
|
|
Click the **Connect** button to connect the server.
|
|
|
|
|
|
</Step>
|
|
<Step title="Enable for Public Repos">
|
|
To use Context7 with public repositories, go to **Organization Settings** → **Configuration** → **Knowledge Base**. In the MCP section, select **Enabled** instead of **Auto** and click **Apply Changes**.
|
|
|
|
|
|
</Step>
|
|
</Steps>
|
|
|
|
## Usage Guidance
|
|
|
|
In the **Usage Guidance** field, you can instruct CodeRabbit on how to use Context7 during reviews. For example:
|
|
|
|
```
|
|
Use Context7 to look up documentation for any libraries used in the code being reviewed.
|
|
Verify that API usage matches the latest documentation and flag any deprecated patterns.
|
|
```
|
|
|
|
## How It Works
|
|
|
|
Once connected, CodeRabbit will query Context7 for relevant library documentation when reviewing pull requests. This helps CodeRabbit:
|
|
|
|
- Verify correct API usage against the latest documentation
|
|
- Identify deprecated methods or patterns
|
|
- Suggest improvements based on library best practices
|
|
- Provide more accurate and informed review comments
|