MCP Integrates AI with Your QMS

QMS work is the kind of work AI is great at. Drafting requirements from a design doc. Expanding a risk into its mitigations. Keeping traceability links consistent across hundreds of records. It's also the kind of work where you absolutely cannot afford an agent to silently overwrite the wrong record.

Lightworks resolves that tension at the protocol level.

Reads Are Free, Writes Go Through Review

Reads go directly against your databases. Any agent on any plan can answer questions like "what's the current state of REQ-12?" or "which risks mention authentication?" without paying for anything. The discovery tools (list_databases, get_database, list_records, get_record) are open to every Lightworks workspace.

Writes are a different story. Every record an agent creates, updates, or deletes lands on a pull request branch, gets reviewed by a human, and merges into main through GitHub. With all the signatures, comments, and history that implies. The audit trail isn't bolted on. It's the only path writes can take.

That's the difference between an AI integration that's interesting and an AI integration that survives an FDA inspection.

Every Write Lands on a Branch

The write tools enforce a three-step dance.

1. create_pr opens a fresh API PR branch and returns a prId.
2. create_record, update_record, and delete_record each take that prId and stage their changes on the branch.
3. finalize_pr opens the GitHub pull request for review.

If the agent goes off the rails mid-task, cancel_pr closes the branch silently. Nothing reaches main without an explicit human merge approval, which Lightworks captures as a 21 CFR Part 11 compliant electronic signature, cryptographically bound to the commit.

Idempotency Is a Feature

The write tools have deliberate idempotency rules.

update_record and delete_record are idempotent. Re-running the same call lands in the same final state, which is how agents recover from a flaky network without doubling the work. Deleting a record that no longer exists returns a 404 with no side effects.

create_record is deliberately not idempotent. Every call mints a new record ID, because two requirements that happen to share a title are still two requirements. That choice belongs to the human reviewer, not the agent retrying its last request.

Ten Tools, Three Groups

Discovery. Read, available on every plan.

• list_databases. List QMS databases in the connected repo.
• get_database. Fetch a single database's schema by path. Example: reqs or parent-db/child-db.
• list_records. List records directly under a database. Sub-database records are queried separately.
• get_record. Fetch a single record's properties and markdown body.

Records. Write, paid plans, token scoped with write:databases.

• create_record. Stage a new record on a PR branch.
• update_record. Merge property changes into an existing record.
• delete_record. Remove a record on a PR branch.

Pull requests. Write, paid plan.

• create_pr. Open an API PR branch and return its prId.
• finalize_pr. Open the GitHub pull request for review.
• cancel_pr. Close the branch and discard staged changes.

Two Minutes to Connect

In your Lightworks workspace, head to Settings → MCP Server and click Create an MCP token. For Claude Desktop, drop this into claude_desktop_config.json:

{
  "mcpServers": {
    "lightworks": {
      "url": "https://app.lightworks.md/api/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN"
      }
    }
  }
}

Cursor, Claude Code, and VS Code each have their own one-paste config under Connect a client on the same page.

What This Unlocks

The MCP server is the foundation for a class of agent workflows we've wanted to build since day one. Design inputs auto-drafted from meeting notes. Traceability gaps surfaced as PR comments. Post-market complaints flowing into CAPA records as fast as a human can review them.

None of that works without a write surface that respects the regulatory shape of the data. Now there is one.

Point an agent at your QMS and tell us what you build.