Repository navigation
API and MCP Operations
The 20 October 2026 audit found that 27 of 29 application API routes responded in the tested setup. The 2 failing routes depended on a separate MCP service being started. The audit also identified that the service should be consolidated into the application so a single startup command can serve both surfaces.
- The app production build passed.
- All 11 test files passed.
- 27 of 29 API routes responded.
- The two routes that did not respond required the separate MCP service.
The audit summary did not include exact route names, HTTP methods, a commit SHA, or the full command transcript. Those details should be added after reproducing the audit; this page intentionally does not guess which endpoints failed.
The intended operational result is one documented startup command that starts the web application and exposes the MCP endpoints. The handshake must report the actual package/runtime version, rather than a hard-coded 1.0.0. MCP API calls should be tested through the app process without relying on an independently launched sidecar.
For a clean checkout and a disposable database:
- Run the documented install and database setup.
- Start the app using the documented single command.
- Check each of the 29 API routes and record method, status, and dependency assumptions.
- Verify the handshake version against the installed package/runtime version.
- Exercise MCP discovery and a harmless tool call through the app endpoint; confirm the expected response and persisted receipt, if applicable.
- Run typecheck, production build, and all tests in CI.
- Repeat with the MCP sidecar stopped to prove the app's MCP routes do not depend on it.
Do not include credentials, private keys, production database contents, or sensitive traces in public test logs. See the current audit and simulation boundaries.