SchemaSentinel

AI release intelligence for database changes.

Comment

Inspiration

SchemaSentinel came from a real frustration I had while working around enterprise database release workflows.

I kept seeing the same pattern: application code would move through review, but the database side still had hidden release risks. A SQL file might be added but not included in the .sqlproj. A migration might not have rollback evidence. A stored procedure might reference something that does not exist in the target branch. Multiple developers might touch the same database object from different branches, and nobody sees the collision until late. That is where the idea started. Originally, I had been thinking about this as a release-assistant idea for Atlassian/Rovo-style workflows. For this hackathon, I reshaped it around GitLab and MCP because merge requests are the right place to catch this kind of release risk before it becomes a production problem.

What it does

SchemaSentinel reviews GitLab merge requests for database release-readiness risk. It focuses on SQL Server / SQLProj / DACPAC-style issues that can break releases late in the pipeline:

  • SQL files added but missing from .sqlproj
  • SQL project inclusion drift
  • SQL71501 unresolved reference risk
  • SQL70001 invalid statement risk
  • DACPAC possible data-loss blocks
  • Msg 213 / column mismatch style errors
  • object collisions across active branches
  • missing deployment notes or rollback evidence

For each review, SchemaSentinel returns a simple decision:

  • READY
  • REVIEW_REQUIRED
  • HOLD

In the current demo, the primary GitLab MR returns:

Decision: HOLD
Risk Score: 80/100

SchemaSentinel also generates a GitLab-ready review comment with the top risk signals and recommended next actions. It can post that comment back to a real GitLab merge request and can optionally create a blocker work item.

It does not auto-merge or approve production changes. The goal is to give the human reviewer better release evidence before approving.

How I built it

I built SchemaSentinel with: • Node.js and Express • GitLab API integration • Google Cloud Run hosting • Docker • Official MCP SDK stdio server • MCP Inspector • a synthetic SQL Server / SQLProj-style demo repo The demo uses a real GitLab repository with three open merge requests. The database schema is fake and safe, but the GitLab workflow is real. MCP tools exposed: • get_demo_context • review_merge_request • post_gitlab_review The MCP post_gitlab_review tool successfully posted a real SchemaSentinel review comment to GitLab MR !1.

get_demo_context
review_merge_request
post_gitlab_review

The post_gitlab_review tool was tested through MCP Inspector and successfully posted a real SchemaSentinel review comment to GitLab MR !1.

Challenges I ran into

The biggest challenge was making the demo real without exposing private enterprise code. I solved that by building a synthetic enterprise-style SQL Server repo with realistic release risks. Another challenge was MCP stdio. Running through npm run polluted stdout and broke JSON-RPC. The working command is: npx @modelcontextprotocol/inspector node src/mcp/stdioServer.js I also had to separate demo UI behavior from real GitLab action behavior. The hosted page shows the release review, while the GitLab adapter and MCP tool can take real action by posting back to the MR.

Accomplishments that I AM proud of

I am proud that SchemaSentinel is not just a static mockup.

It has:

  • a hosted Cloud Run app
  • a real GitLab app repository
  • a synthetic but realistic GitLab database repo
  • three open GitLab merge requests
  • a real GitLab MR comment posted by the agent
  • real blocker work item creation
  • an official MCP SDK stdio server
  • successful MCP Inspector validation

I am also proud of the domain focus. This is not a generic “review my code” assistant. It focuses on a painful release problem: database changes that look small but can break the release train if the project file, DACPAC, migration, and rollback evidence are not aligned.

What I learned

I learned that the hard part is not just calling an API or generating a comment. The hard part is designing the right boundary between automation and human control.

For database releases, the agent should not blindly approve or merge. It should surface risk, explain why the release may be unsafe, and give practical next actions.

I also learned that MCP makes more sense when the tool does something concrete. In this case, the MCP tool does not just return text. It can review a merge request and post the review back to GitLab.

On the engineering side, I learned the importance of clean stdio behavior for MCP servers, and why direct process execution is safer than wrapping stdio tools with npm run.

What's next for SchemaSentinel

The next step is to replace the prepared demo payload with live GitLab MR inspection. I want SchemaSentinel to directly pull:

  • changed files
  • .sqlproj diff
  • SQL file additions
  • pipeline status
  • pipeline logs
  • branch comparison evidence
  • deployment notes
  • rollback evidence

After that, I would add stronger SQL analysis for stored procedures, table changes, migration scripts, and DACPAC-style deployment blockers.

Longer term, SchemaSentinel could become a database release-governance assistant for teams that run SQL Server, DACPAC, Azure DevOps, GitLab, or enterprise release trains.

The goal is simple: catch database release risk early, explain it clearly, and keep the final decision with the human reviewer.

Built With

Share this project:

Updates