| name | deepnote-notebooks |
| description | Use when reading, reviewing, inspecting, or reasoning about hosted Deepnote notebooks, blocks, inputs, SQL, Python, or notebook outputs through the Deepnote MCP server. |
Deepnote Notebooks
Notebook Inspection Workflow
- Resolve the target notebook with
search or project context before using get_notebook.
- Read the notebook with
get_notebook before answering questions about structure, inputs, blocks, or last-run state.
- Preserve distinctions between block types, notebook inputs, code, SQL, markdown, and metadata in your reasoning.
- When reporting inputs, include the input
name, type, current value, and label when useful.
- When SQL connection usage matters, use
list_integrations and the integration usage tools to confirm project, notebook, or block references instead of inferring solely from names.
- When asked to review or explain a notebook, ground the answer in specific notebook/block names or IDs when useful.
- If the user asks to create a project, create a notebook, add blocks/cells, or scaffold notebook content, use the
deepnote-notebook-editing skill.
Notebook Inspection Output
Great notebook-inspection output should help the user decide what the notebook does, whether it is safe to run, and what to do next. Prefer this structure:
Keep notebook inspection brief and high signal by default. Lead with the answer, then include only the tables or cautions that materially help the user. Omit exhaustive block listings, raw code, and long outputs unless the user asks for more detail.
- Start with a one-sentence brief:
Notebook "Name" in project "Project" has 12 blocks, 2 inputs, 1 visible connection, and last ran successfully on YYYY-MM-DD HH:MM UTC.
- Show a compact status table:
| Field | Value |
|---|
| Project | Project name |
| Notebook | Notebook name |
| Notebook ID | notebook-id |
| Scheduled | Yes or No |
| Last Run | status/date/run id or No run visible |
| Visible Connections | Integration name (type) or None visible via MCP |
- If inputs exist, add an inputs table:
| Input | Type | Current Value | Label |
|---|
input_name | text | safe summary or value | Human label |
- Add a block map when useful, especially for reviews and debugging:
| Order | Type | Purpose | Connection / Output |
|---|
1 | sql | SELECT demo.gapminder sample | Clickhouse (clickhouse) |
- Add
Cautions only when actionable: cells that print environment variables, hard-coded credentials, mutating external calls, long-running servers, large dataset dumps, missing inputs, failed/pending last runs, SQL blocks whose integration is not visible, or integration usage that was not checked when it matters.
- End with
Useful Next Actions only when it helps, such as run notebook, inspect last run, map integrations, summarize outputs, or review risky cells.
When MCP does not expose a detail, say Not visible via MCP rather than inferring from names. Keep raw code excerpts short; summarize large cells and mention block IDs when useful.
Code And Output Handling
- Before suggesting code changes, inspect nearby blocks for imports, shared variables, SQL connections, inputs, and upstream assumptions.
- Prefer deterministic notebook code. Avoid hidden global state, implicit external files, or hard-coded credentials.
- Do not claim an edit was applied unless a write-capable tool is available and reports success. For project, notebook, and block creation, use
deepnote-notebook-editing.
- If you run a notebook, pass requested input values through
create_run.inputs using the input name fields returned by get_notebook, then capture run status with get_run. Omit snapshotDelivery for status checks so the default download URL delivery is used; request snapshotDelivery: "inline" when you need to summarize snapshot content or errors.
- Run input values do not change the notebook's saved default input values.
- For SQL blocks, preserve the existing connection or data source in recommendations unless the user asks to move it.
- Before running a notebook, flag cells that print
os.environ, environment variables, credentials, tokens, or broad secret dumps. Do not run those notebooks unless the user explicitly confirms after the risk is named.
- Treat cells that start servers, send network requests, write files, cancel/modify external records, or call production-like systems as stateful. Call out the side effect before execution.
Review And Cleanup
Use Deepnote MCP reads to verify notebook structure before making claims. If execution was not run, say so plainly and mention the remaining risk. For larger reviews, summarize relevant sections rather than listing every block.
