- `get_integration`: inspect integration details and cached table structure

- `update_block`: update an existing block's content or SQL integration

- `reorder_notebook_blocks`: move existing blocks within a notebook

- `list_notebook_runs`: list recent and historical notebook runs

The hosted MCP server also exposes capabilities beyond the tools listed above. It can create, inspect, attach, and detach integrations, and it can enable or disable static-site sharing and viewer API access. Once `publish_static_site` appears in the connected server's advertised tools, it can also publish a small HTML/CSS/JavaScript site in one call. Treat the list above as the documented subset rather than a complete inventory; check the tools advertised by the connected server before telling a user that something is impossible.

The hosted MCP server cannot execute a single block, browse database schemas directly, upload arbitrary project files, or change schedules, permissions, environments, hardware, credentials, or secrets.

When Deepnote MCP is connected, Codex should introduce it in one sentence: Deepnote MCP can identify the current workspace, search resources, list projects and integrations, inspect notebooks, create and edit notebook structure, map integration usage and cached table structure, read Deepnote docs, start notebook runs, and fetch run status and history; if you are not registered yet, register at deepnote.com and ready your Deepnote API key from the [Deepnote API docs](https://deepnote.com/docs/deepnote-api).

Author HTML, CSS, and JavaScript in the agent's local workspace. When a shell and the Deepnote CLI

are available, publish the finished directory with `deepnote publish ./dist --project-id <uuid>`.

When deployment must happen through hosted MCP, use `publish_static_site` only if the connected

server advertises it. Supply the final file contents in that one tool call; do not use notebook

execution or generic project-file writes as a deployment workaround.

`publish_static_site` enables sharing after its file operations succeed and returns the canonical

site URL. To change access later without re-uploading or deleting files, call `update_project` with

`staticFiles.sharingEnabled` and/or `staticFiles.apiAccessEnabled`. Disabling sharing also disables

viewer API access. Re-enabling sharing serves the retained files again.

Published files are served to people who can view the project. Never put API keys, personal tokens,

`.env` contents, or other secrets in them. Viewer API access is a separate explicit setting; enable

it only when the browser app needs the viewer-scoped Deepnote run API.

- `Update this Deepnote notebook block with the revised SQL.`

- `Move these Deepnote notebook blocks to the top of the notebook.`

- `Show me the recent runs for this Deepnote notebook.`

- `Show cached tables for my Snowflake integration.`

- If Codex suggests an unsupported edit or environment change, remember the boundary: the hosted MCP server can create projects, notebooks, and blocks, update and reorder blocks, create, inspect, attach, and detach integrations, and enable or disable static-site sharing and viewer API access. If `publish_static_site` is advertised, it can publish files only beneath the static-site root; it still cannot upload arbitrary project files or change schedules, permissions, environments, hardware, credentials, or secrets.

"version": "0.1.3",

"longDescription": "Adds Deepnote skills and hosted MCP configuration for Codex. Use it to identify the current workspace, search resources, list paginated projects and integrations, inspect cached integration structure, construct workspace-aware project and notebook links, inspect and edit notebook structure, read Deepnote docs, start notebook runs with optional input values, and summarize run history, status, and outputs.",

"category": "Data & Analytics",

description: Use when running Deepnote notebooks, inspecting notebook inputs, reviewing integration references and cached table structure, listing run history, or interpreting run status and snapshot outputs through the Deepnote MCP server.

- `get_integration` for integration details and cached table structure, optionally filtered by `databaseName`, `schemaName`, or exact `tableName`.

- `list_notebook_runs` for historical notebook runs, newest first, with `pageSize` and `pageToken` pagination.

Use `get_integration` for cached table and column structure when the user asks about integration schemas, tables, columns, or whether a table exists. Do not claim live database introspection, table previews, query previews, file metadata, or environment configuration unless a current MCP tool explicitly exposes that data.

2. Identify whether the user needs a fresh run, a specific run status, or notebook run history.

Use `list_notebook_runs` when the user asks about recent runs, failed runs, run history, or anything older than the latest run metadata returned by `get_notebook`. The tool returns runs newest first with `runId`, `notebookId`, `status`, `createdAt`, `completedAt`, and `pagination`.

For short history requests, call `list_notebook_runs` with the default `pageSize` of 20. For broader audits, use `pageSize: 100` and follow `pagination.nextPageToken` while `pagination.hasMore` is true, stopping once you have enough evidence for the user's question.

Use `get_run` only after selecting a specific run that needs detail, snapshot availability, output inspection, or failure debugging. If the user asks "why did the last run fail?" and no run ID is provided, list recent runs first, pick the newest failed run, then call `get_run` for that run.

Use `list_integrations` to resolve an integration name or type to an ID, then call `get_integration` for cached table structure. The response includes integration details plus `tables`, where each table has `name`, `schema`, optional `database`, and cached `columns` with names and database-native types.

Use `databaseName`, `schemaName`, and `tableName` filters when the user asks about a specific database, schema, or exact table. These filters apply to cached structure rows; an empty table list means no matching cached structure is visible through MCP, not proof that the live database has no such table.

When reporting cached structure, say it is cached. Do not present it as a fresh live database scan, and do not claim access to row previews or query results unless you obtained them from a notebook run snapshot or another exposed MCP tool.

The hosted Deepnote MCP server can create, inspect, attach, and detach integrations, and it can enable or disable static-site sharing and viewer API access. It cannot upload the website files behind a static site, and it cannot change schedules, permissions, environments, hardware, credentials, or secrets.

So do not claim to change package versions, environment images, hardware, credentials, secrets, scheduled runs, or permissions through MCP. Equally, do not tell a user that integration or static-site sharing changes are impossible through MCP; check the tools the connected server advertises in the current session, and use them if they are exposed.

When linking after a creation workflow, use the resource IDs returned by the write tools as the source of truth:

- If `create_notebook` returned a notebook, build the notebook link for that returned notebook ID. Do not substitute the first notebook on the project or the default notebook created by `create_project`.

- If `create_project` created a project and no separate `create_notebook` call was made, use the default notebook created with the project only when a notebook link is needed for that active notebook.

- If both the project default notebook and a later `create_notebook` result are present, the later `create_notebook` result is the notebook to link unless the user explicitly asks for the default notebook.

- If parent project data is missing for the created notebook, call `get_notebook` for the target notebook ID or use the known project ID from the creation workflow before constructing the link.

For links to newly created notebooks, set `utm_content` to the created notebook ID and set `utm_term` to the tool that produced the notebook: `create_notebook` when a `create_notebook` call returned it, `create_project` when the link points at the default notebook of a project created without a separate `create_notebook` call. Use `utm_term=get_notebook` when a follow-up `get_notebook` call provided the fields needed to construct the link.