Syncanix with Django
Make a Django project agent-ready: what discovery reads, how to run it, and how to ship the chat surface and MCP server.
Django routes live in urls.py modules stitched together with include(). Discovery follows the includes and their prefixes, and understands Django REST Framework conventions on top.
What discovery reads
Discovery is static โ it reads your source, not your traffic. It composes full request paths across files, so mounted prefixes are part of every extracted route:
# project/urls.py
urlpatterns = [path("api/", include("orders.urls"))]
# orders/urls.py
urlpatterns = [
path("orders/<int:pk>/", views.OrderDetail.as_view()), # โ GET /api/orders/<pk>/
path("orders/<int:pk>/refund/", views.refund), # โ POST /api/orders/<pk>/refund/
]The extractor reads path(), re_path(), and legacy url() patterns, follows include() prefixes across modules, and understands DRF โ router-registered ViewSet CRUD and generic-view verb inference (a ListCreateAPIView yields GET and POST).
Run discovery
From the repository root, run the init command. It detects the framework automatically, asks for consent before any LLM enrichment, and writes a deterministic catalog:
$ npx syncanix init
โ detected framework
โ scanned routes
โ wrote .syncanix/catalog.json
โ review your capabilities in the dashboardReview the catalog
The catalog at .syncanix/catalog.json lists every capability discovery found โ method, path, and the enriched description your users will see. Review it like code before uploading: it is the contract your chat surface and MCP server expose.
Ship the surface
Once the catalog is uploaded, embed the widget for in-app chat and connect the per-tenant MCP server for Claude, ChatGPT, and Cursor. Every write action stays permission-gated, confirmed, and audited.