Positron’s experimental MCP server connects agents to live Python and R sessions

Live state adds evidence beyond source files

Posit announced an experimental built-in Model Context Protocol, or MCP, server on October 13, 2026, connecting external coding agents to live Python and R sessions. According to the company, it supports listing sessions, executing Console code and inspecting objects without adding history entries. Agents can also read recent history, interrupt computation, retrieve the current plot, and discover and execute Positron commands. Executed code carries the agent’s name. Sources: Posit

A proposed sales-dashboard experiment makes the debugging opportunity concrete: keep the committed input clean, then introduce a duplicate into the live Python object. Repository inspection sees the original input, while session inspection can reveal the discrepancy. The research included no hands-on test of Positron and found no substantive independent review or controlled benchmark of the new server. Treat the workflow below as an experiment that tests diagnosis and reproducibility, not evidence of a productivity gain.

Connect the agent and define its access

Record the exact development environment build, operating system, Python version, agent version, model identifier, dependencies and enabled settings. The retrieved release notes identify build 2026.10.0-297. Posit’s setup instructions specify the ai.mcp.enabled setting; the implementation pull request says ai.enabled must also be enabled. The announcement describes automatic configuration for Claude Code and the Positron MCP: Add to Coding Agent command for the Codex and Gemini command-line clients. Other clients can obtain a URL and token through Copy Connection Details. Sources: Posit, GitHub

Review the chosen client’s execution permissions before connecting it to a working session. The implementation pull request describes loopback binding and workspace-specific 32-byte bearer tokens. It also says terminals receive connection credentials and Positron adds no further approval dialog. Keep tokens out of the evidence bundle, but capture relevant tool traces and logs. The pull request says tool and command outcomes and durations are logged, while full code appears in debug logging. Sources: GitHub

Distinguish session access from control of a running app. Posit’s announcement separately describes Assistant preview features for apps, interpreters, connections and Viewer content, while calling comparable external-agent tools a goal. The release notes associate those broader features with assistant.previewFeatures. Use the table below to keep each documented capability attached to its interface. Sources: Posit

Establish the session and change only memory

Create a small project containing data/orders.csv, analysis.py, app.py, tests/test_analysis.py, pyproject.toml, uv.lock, project instructions and an evidence directory. Commit the following CSV as the experiment’s clean input. Treat its values as fixture data, not performance measurements. Declare that order IDs must be unique so the agent has an explicit rule against which to assess duplicates.

order_id,region,revenue_cents
1,North,1000
2,North,2000
3,South,1500
4,South,2500

Open the project’s Python interpreter and run the Console code below to load the fixture and record runtime identity. Ask the connected agent to identify the session containing orders and report its interpreter, session identity, shape, columns and regional totals without modifying data. Capture evidence that it inspected the existing session rather than inferred values from files or started another process. Keep requests focused because the implementation pull request describes a 32 KB output cap with truncation flags. Sources: GitHub

import os
import sys
import pandas as pd

print({
    "python": sys.executable,
    "version": sys.version,
    "pid": os.getpid(),
    "cwd": os.getcwd(),
})

orders = pd.read_csv("data/orders.csv")

Introduce the controlled defect with the next Console snippet, leaving the committed CSV unchanged. Ask the agent to compare the live object with the file, identify the duplicated order and show its evidence before suggesting a repair. Require it to connect the discrepancy to the declared uniqueness rule. This tests whether the agent can explain the unexpected state before changing it.

orders = pd.concat(
    [orders, orders.loc[orders["order_id"].eq(3)]],
    ignore_index=True,
)

Establish what the running app uses

Build a minimal dashboard around a function in analysis.py that reads the CSV and aggregates revenue. Have both the Console and app use that function. Add a temporary diagnostic panel showing the Python executable, process ID, input path, row count, totals and an application revision marker. Compare the displayed values with the corrupted Console object, establishing the app’s actual process, inputs and refresh behavior rather than assuming shared memory.

Ask the agent to discover available commands, launch the intended app and report its status and URL where supported. Record displayed-content inspection separately from launching, since a successful launch alone does not establish correct data. The release notes list Dash, FastAPI, Flask, Gradio, marimo, Streamlit and Shiny as supported by Assistant’s app commands. They also describe Assistant Viewer capabilities for reading, screenshots and interaction. Introduce the conditions in the table below separately; the wrong-editor scenario also reflects a documented Run/Debug App fix. Sources: Posit

Save the repair and restart

Once the discrepancy is understood, ask the agent to put the transformation and validation into project files. A corrected live object is useful evidence, but the deliverable should include the code, dependencies, inputs and checks needed to reproduce it. Require the app and analysis to use the same transformation. Set acceptance criteria before judging the dashboard’s appearance.

• Clean input matches the committed fixture and has unique order IDs.
• Regional totals match the expected sums of the clean fixture.
• A deliberate duplicate produces a clear validation failure.
• The app and Console analysis use the same transformation.
• A rebuilt environment and fresh Python process reproduce the expected result.

If the corrupted object is needed for diagnosis, export it as a labeled fixture with its schema and provenance, keeping the clean input separate. Document environment creation, app startup and verification in the project instructions. Positron’s release notes say projects containing uv.lock or pixi.lock can prompt environment creation when none exists. Close the Console and app, reopen the project, recreate the environment and follow only those instructions. Treat any required but undocumented session step as an unfinished repair. Sources: Posit

Compare diagnosis with durable repair

Compare ordinary repository and terminal access with the same agent connected through Positron MCP. Treat Posit Assistant as a separate product comparison, holding the model and configuration constant where possible and disclosing differences. Reset files, sessions and app processes before repeating each fault. Use assertions and app outputs as ground truth, and fail the durability criterion whenever a repair works only in the existing Console.

Record diagnosis accuracy, final correctness, time to diagnosis, time to durable repair, human interventions and wrong-session actions. Track tool calls, failures, truncations, retries, tokens and actual billed cost alongside clean-restart success. Pay particular attention to session selection and intervening human actions: a reviewer raised both concerns in the implementation pull request. Those comments were pre-release observations, not confirmed release defects. Use the recorded results to decide whether live access improves the complete repair process. Sources: GitHub