Roadmap

Roadmap

An informal snapshot of what's shipped and what's likely next, organized by theme. Not a commitment or a timeline — pick items up as they're useful. Check CHANGELOG.md for what's actually landed and when.

Shipped

• Structured MCP tool output (typed Pydantic models), streamable-http transport option, duration_s/timeout_s capping
• Persistent frame history buffer backing passive-listening tools + dashboard (replacing a fresh-listener-per-call design that dropped frames)
• get_vehicle_snapshot tool — one-call overview of every signal's last known value
• UDS-style diagnostic responder + send_diagnostic_request/diag-request, OBD-II exposed as an MCP tool (send_obd_request) alongside the pre-existing CLI-only version
• Correlated, plausible signal generation (RPM/throttle/speed/temp/fuel move together, not independently random) — see Architecture
• Named fault-injection scenarios with real DTC encoding — see Fault Injection
• logging throughout (replacing bare print()), /healthz, CORS made configurable with a safer credentials default
• Read-only live dashboard
• CONTRIBUTING.md, CHANGELOG.md, this wiki

Likely next — LLM/MCP ergonomics

• @mcp.prompt() — a guided prompt (e.g. "diagnose vehicle health," walking an LLM through read_can_frames/get_vehicle_snapshot → decode_can_frame → send_diagnostic_request). The prompt primitive is currently unused entirely.
• Queryable DBC resource templates (dbc://message/{name}, dbc://signal/{name}) so a client can look up one signal without fetching the entire dbc_info dump.
• Resource links from tool results — e.g. decode_can_frame linking to the relevant dbc://message/{name} resource, once the above exists.
• Elicitation before destructive diagnostic actions — confirm before sending RESET_ECU/WRITE_MEMORY service IDs through send_diagnostic_request, now that the diagnostic responder exists to make this meaningful.
• stdio transport verification — Settings.mcp_transport already types stdio as an option; confirm it's actually exercised/working end-to-end (e.g. as a Claude Desktop-style local subprocess config), not just accepted by the type.

Likely next — automotive realism

• OBD Mode 01 wired to live state — coolant temp/speed/fuel-level PIDs are currently hardcoded constants (see Diagnostics and OBD-II), not connected to the correlated driving state the DBC-based signals already use.
• Broader DTC storage — fault presets currently carry their own fixed DTC list; a general settable DTC list independent of a named preset (e.g. via a dedicated tool/CLI command) would round this out.
• Bigger/lower-priority: J1939 support (different addressing/DBC conventions — commercial-vehicle audience), CAN FD (bus.py::make_bus would need fd=True; nothing currently needs >8-byte frames), multi-bus/gateway simulation (real architecture change). None of these are near-term.

Likely next — production hardening

• Optional bearer-token auth (Settings.api_token, off by default) — the right-sized auth story for an educational/prototyping project; skip full OAuth2/OIDC unless a concrete multi-tenant hosting need appears (the existing OAuth-discovery routes are stubs purely to stop MCP Inspector's auth probing from blocking, not real auth).
• Basic rate limiting — a natural follow-on to the existing duration_s cap, same underlying "don't let one client tie up resources indefinitely" concern.
• SocketCAN/real-hardware guide — can_interface/can_channel already pass through to real interfaces (see Docker and Deployment), but there's no dedicated walkthrough or test for it yet.
• Tool-call metrics alongside the existing /healthz — skip a Prometheus dependency unless there's real demand.

Likely next — project polish

• Fix the single-container Dockerfile / compose cross-process mismatch — see the callout in Docker and Deployment. The single Dockerfile should run mcp-can demo as one process; compose should either provision a shared vcan0 or collapse to one combined service.
• Verify the PyPI release pipeline actually works end-to-end (no tag has been pushed yet) — a verification task before it's a fix task.
• A real integration test running simulator + server together in-process (the demo command's own pattern) plus an end-to-end MCP tool-call test via a test client, extending the existing test_server_app.py/test_cli.py patterns.

Explicitly deprioritized for now

Full OAuth2/OIDC, OpenTelemetry tracing/metrics, J1939, CAN FD — all listed above as "not near-term" for the same reason: disproportionate scope/maintenance for this project's current size and educational/prototyping audience. Revisit if real demand shows up.