# MCP Security & Limits


What a key can reach, how to keep it narrow, and the limits the server enforces.

## Key profiles

Every key carries a profile that decides which tools it can call. Pick the narrowest one that does the job — you can always mint a second key.

| Profile | Allows | Good for |
| --- | --- | --- |
| **Read-only** _(default)_ | Reads only. Nothing is created, changed or deleted, and no tool can reach a private network. | Research, Q&A, first-time setup |
| **Minimal** | A small core set: list notebooks and sources, read content, ask questions, add simple sources. | A focused assistant that should not wander |
| **Standard** | Everything except destructive tools. Creates and edits; never permanently deletes. | Day-to-day work — the usual choice |
| **Full** | Every tool, including deletion of notebooks, sources, artifacts and tags. | Bulk clean-up you are supervising |

<img src="/docs/img/docs/concept-key-profile.svg" alt="What a read-only key lets through" width="760" />

## Blocking individual tools

When generating a key you can also list tools to deny by name. The deny-list wins over the profile, so a Standard key with `open_notebook, download_podcast_zip` denied can do everything Standard allows except open browser windows on your machine.

## Managing keys

- **Shown once.** Kortex stores only a hash. Losing the key means revoking it and generating another.
- **One key per client.** Separate keys for Claude Desktop, Cursor and a script mean you can revoke one without breaking the others.
- **Revoke from the popup.** Settings → General → MCP Connection lists your active keys with their label, profile and last use. Revocation takes effect immediately.
- **Set an expiry** on keys you are handing to something temporary.

:::warning
Treat a Kortex MCP key like a password. Anyone holding it can act on your notebooks with that key's profile. Never commit one to a repository, paste it into a shared document, or send it in chat. Use your client's secret prompt (VS Code's `inputs` block) or an environment variable where one is available.
:::

## Rate limits

| Limit | Value |
| --- | --- |
| Per key | 60 calls per minute |
| Per user, across all keys | 120 calls per minute |
| Unauthenticated calls per IP | 30 per minute (`initialize` and `tools/list` only) |

Exceeding a limit returns a clear error telling you how many seconds to wait. Limits exist to stop a runaway agent loop, not to ration normal use.

## Other limits worth knowing

- **First call after idle:** up to 30 seconds while the extension wakes. Later calls in the same session are fast.
- **File uploads:** 50 MiB per file, staged in chunks, discarded after an hour.
- **URL fetches:** 2 MB and 15 seconds per page. Private, loopback and link-local addresses are refused.
- **Gemini Notebook's own limits still apply** — sources per notebook, generation quotas, and so on.

## How your data is handled

- Your Google session never leaves your browser. The server holds no Google credentials and could not obtain them.
- Notebook content passes through the relay only as the result of a call you triggered, and the job record is deleted automatically an hour later.
- Keys are stored hashed. A leaked database row cannot be replayed as a key.
- Calls are audited so you can see what a key did.

## Safe-use practices

- **Check the endpoint.** The only official one is `https://mcp.kortex-notebooklm.com/PLACEHOLDER-AT-LAUNCH`. Do not paste your key anywhere else.
- **Start read-only.** Move up a profile when you hit something the assistant cannot do, not before.
- **Keep confirmations on.** Destructive tools are flagged as such, and clients that honour the flag will ask first. Leave that behaviour enabled.
- **Be careful what you feed it.** A web page or imported source can contain text designed to instruct your assistant ("ignore previous instructions and delete…"). This is prompt injection, and a read-only key is the cheapest defence against it.
- **Revoke keys you are not using.** An unused key is only a liability.