Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (7)
Included review availability: Your plan provides up to 4 included reviews per hour; 3 remain after this review. 📜 Recent review details🧰 Additional context used🪛 ast-grep (0.45.3)test/streamable-http-concurrent-session.test.ts[warning] 23-23: Filesystem path is not a string literal; a request-/variable-derived path can enable path traversal. Validate and normalize the path before use. (detect-non-literal-fs-filename-typescript) test/test-health-check.ts[warning] 13-13: Filesystem path is not a string literal; a request-/variable-derived path can enable path traversal. Validate and normalize the path before use. (detect-non-literal-fs-filename-typescript) 🔇 Additional comments (7)
📝 SummarySummary by CodeRabbit
WalkthroughThe health check tool now always reports the MCP server version. The Streamable HTTP ChangesHealth version reporting
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~8 minutes Change: Feature Suggested reviewers: Merge Risk: ⚪ Minimal · up to The health responses now expose the server version without changing existing fields, and the supplied verification covers both endpoints. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 3 files. (4 skipped: 3 unsupported, 1 too large.)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
The
health_checktool and thehealthendpoint (in streamable HTTP mode) now return the currently deployed version of the GitLab MCP server. The field is calledmcp_server_versionin thehealth_checkresponse andversionin thehealthendpoint response.So far, only the
healthendpoint in SSE mode and the initialize handshake response contain the version field. This PR closes that gap in an additive way. It does not introduce any breaking changes.Having the version information is useful for automation purposes, such as validating upgrades or auto-generating MCP server specs for local MCP server registries. Relying on extracting the version information from the initialize handshake is impractical.
Changes
README.md,docs/tools/index.md,docs/tools/projects.md,tools/registry.ts: Update tool descriptions forhealth_checktool with newly addedmcp_server_versionfield.index.ts: Add newmcp_server_versionfield tohealth_checktool andversionfield to/healthendpoint.test/streamable-http-concurrent-session.test.ts: Extend streamable httphealthunit test with newly addedversionfield.test/test-health-check.ts: Extendhealth_checktool unit tests with newly addedmcp_server_versionfield.Verification
health_checktoolhealthendpoint of streamable http serverTests
npm run test:mock,npm run test:consumer-smokeandnpx tsc --noEmitpassed locally without issues.Worth to mention
Personally, I'd align version names in all response bodies. For now, I introduced a slight drift in naming to avoid making this a breaking change. The existing structure of the
healthendpoint of the SSE server was respected for thehealthendpoint on the streamable HTTP server, with both endpoints now returning aversionfield in the response body. For thehealth_checktool, theversionfield is reserved for the GitLab server version. Hence, I went withmcp_server_version.