Jupyter AI
Bring ACP-compatible AI agents into computational notebook workflows in JupyterLab.
Per-dimension scores and reasoning
The README discloses that agents can read and write files and run terminal commands, and states that file writes and command execution require approval. Workflows use empty default permissions, job-scoped grants, commit-pinned third-party Actions, and disabled credential persistence, supporting moderate scores for least privilege, confirmation, dependency security, and external-effect disclosure. Deductions apply because the permission implementation, per-tool policy, data destinations, and full data lifecycle are not shown. No handling rules are supplied for secrets, prompts, uploaded files, or multi-user chat data, and no undo, snapshot, or recovery mechanism is documented. Organizational, documentation, source, and issue-tracker attribution is present, but the unexplained difference between author_a in the license and Project Jupyter in package metadata prevents full attribution marks.
The README, package metadata, and dependency layout consistently describe a JupyterLab agent product. Dependencies have bounded compatibility ranges, optional functions are separated into extras, and the documentation and release-note machinery has substantial static coverage for missing content, unmatched versions, and malformed markers. Deductions apply because the supplied tests predominantly exercise documentation and release tooling rather than chat, permissions, or ACP/MCP execution. Failure handling is represented mainly by a troubleshooting link and some script safeguards; end-user runtime errors, retries, and graceful degradation are not demonstrated.
Separate getting-started, user, contributor, developer, and troubleshooting paths cover chat, notebook tools, custom MCP servers, personas, collaboration, and extension development, thoroughly identifying audiences and scenarios. Python 3.9 through 3.13, JupyterLab 4, alternative optional RTC stacks, and entry points provide strong environment-fit evidence. Capability boundaries remain high-level and do not distinguish limitations among agents or MCP servers. Dependency-based automatic detection is clear, but conflict resolution, false-trigger prevention, and multi-agent selection rules are not shown.
The README's quick links and separate user, developer, contributor, and troubleshooting sections provide clear information architecture, reinforced by real Sphinx integration tests. The complete BSD-3-Clause text agrees with the package classifier. Dynamic versioning, release checks, frozen documentation snapshots, and tested release-note generation provide strong versioning and changelog evidence. Deductions apply because the supplied material lacks direct installation commands and complete usage examples, while FAQ coverage and known limitations are only indirectly represented by a troubleshooting link and incubation notice. Product, package, and subpackage names are broadly consistent, although display names, underscore package names, and hyphenated repository names coexist. The organization, email, tracker, and incubation home identify a maintenance route, but release ownership and support commitments are unspecified, and publisher identity remains unknown under the prompt.
Native chat, notebook context, file and cell attachment, terminal and notebook tools, concurrent chats, real-time collaboration, and open ACP/MCP extension points offer substantial incremental value for notebook workflows. Outputs can lead directly to file, command, and notebook actions. Deductions apply because no core interaction example, output-quality standard, or user-outcome evidence is supplied. Model charges, token use, resource consumption, latency, data-exposure cost, and agent configuration burden are also unaddressed, leaving cost-benefit support thin.
Major structural claims can be traced among the README, pyproject, workflows, and tests. Dependency ranges, supported environments, documentation builds, and release machinery receive cross-file corroboration, while test comments distinguish real Sphinx builds from mocked network responses. Deductions apply because the permission system, automatic agent discovery, real-time collaboration, and core ACP/MCP behavior are asserted without corresponding implementation files or core-path tests in the supplied evidence. Several effectiveness claims therefore remain project descriptions rather than independently corroborated findings.
- Agents receive file-write and terminal-execution capabilities. Before deployment, verify that approval enforcement covers every agent, MCP tool, notebook operation, and custom server rather than relying on the README summary.
- The supplied material does not define storage, transmission, retention, or deletion rules for API keys, chats, dropped files, notebook data, or collaborative state.
- No unified undo or recovery mechanism is shown for agent actions; use version control, snapshots, or isolated workspaces around valuable notebooks and data.
- The supplied tests focus on documentation aggregation and release notes and do not establish equivalent coverage for core agent execution, approval flows, or output quality.
- The product composes several 0.x subpackages; check each component's compatibility, maintenance status, and security notices before upgrades.
What does this agent do, and when should you use it?
Jupyter AI is a JupyterLab extension that exposes ACP-compatible AI agents through a native chat interface alongside computational notebooks. It automatically detects supported agents whose dependencies are installed, with Claude, Codex, GitHub Copilot, Gemini, Goose, Kiro, Mistral Vibe, and OpenCode named as examples. Agents can read and write server-side files, execute terminal commands, and work with notebooks through the built-in Jupyter MCP server. Users can maintain concurrent chats, drop files or notebook cells into context, and collaborate in real time with others connected to the same server. Its deployment boundary is a JupyterLab environment containing Jupyter AI, a selected agent, and that agent's dependencies, with extension points for custom MCP servers and personas registered through the entry points API.
A user opens the native chat UI in JupyterLab and selects an ACP agent that Jupyter AI has detected from its installed dependencies. Files and notebook cells can be dropped into the conversation as context. The agent can then read or write files, execute terminal commands, and invoke notebook capabilities exposed by the built-in Jupyter MCP server; the permission system requests approval before file writes or command execution. Users can keep several chats active and collaborate with other users on the same server. Developers can attach custom MCP servers that expose domain-specific tools, resources, and prompts, or register custom AI personas through the entry points API.
- A data analyst exploring a Jupyter notebook can attach relevant cells to a chat and let an agent assist with notebook, file, and terminal operations in the same workspace.
- A developer evaluating Codex, Gemini, Claude, or another supported ACP agent can use one JupyterLab interface without committing the workflow to a single agent vendor.
- A research team connected to one Jupyter server can collaborate in real time while maintaining multiple chats and sharing files or notebook cells as context.
- An administrator in a controlled environment can permit agent access to files and terminal commands while retaining approval gates for writes and execution.
- A platform developer can expose specialized tools, resources, and prompts through a custom MCP server or register a purpose-built persona through the entry points API.
What are this agent's strengths and limitations?
- ACP support connects one JupyterLab interface to multiple named agents instead of imposing a single-agent vendor.
- The built-in Jupyter MCP server gives agents concrete notebook capabilities in addition to file and terminal access.
- Approval is required before file writes and command execution, providing an explicit guardrail around consequential actions.
- Concurrent chats, drag-and-drop context, and real-time collaboration address practical shared-notebook workflows.
- Custom MCP servers and the entry points API provide documented extension paths for domain tools and personas.
- The primary experience depends on JupyterLab, so adopters outside that ecosystem would need a different integration.
- Each agent brings separate dependencies, while the supplied material gives no dependency list, credential procedure, or compatibility matrix.
- Agents can reach the filesystem and shell; even with approval prompts, operators must assess server permissions and data exposure.
- The project is under incubation within the JupyterLab organization, and no stability commitment or maturity metric is supplied.
- The supplied installation information lacks executable commands, configuration samples, and documented failure behavior.
How do you install or deploy this agent?
The supplied material states that Jupyter AI and the chosen agent must be installed, including that agent's dependencies; eligible agents are then detected automatically. It does not provide a copyable pip, conda, npm, or other installation command. It also omits runtime versions, agent-specific credential setup, and the command used to start JupyterLab, so a complete verifiable installation sequence cannot be reproduced from the supplied information alone.
How do you use this agent?
Open the native chat UI in a JupyterLab environment where Jupyter AI and the selected agent's dependencies are installed, then start a chat with an automatically detected agent. Drag files or notebook cells into the chat when they should become context, and create additional concurrent chats as needed. Review permission prompts whenever the agent requests a file write or terminal command. Add a custom MCP server for domain-specific tools, resources, or prompts, or use the entry points API to register a custom persona. The supplied material does not include credential fields, a configuration example, or a copyable first invocation.