Projects and status

ping

Health check. Verifies the server is reachable and the credential is valid. No parameters.

status: "ok"
server: "cassis"

list_projects

Lists the projects accessible to the authenticated user. No parameters. This is how a client discovers the project_id the other tools take.

An API key scoped to one project does not need it: the tool is left out of that key’s tool list, and every other tool defaults to the key’s project. A client that calls it anyway gets that one project.

projects:
  - id: 019d6555-12bd-757c-bae9-fc826018ad76
    name: "Formula 1"
    data_source:
      is_executable: true
      sql_dialect: "POSTGRESQL"
  - id: 019e2c10-4a1f-70d2-9b3e-52ac70f114c8
    name: "Finance sandbox"
    data_source: null

A connected source with is_executable: false is schema-only, for instance an uploaded DDL file: SQL is generated in that dialect but never run, and query results are always null.

get_project_status

The project’s context state in one call: which version is published, whether a merge synced and published, and whether anything awaits publication. Parameters: project_id (optional with an API key scoped to one project, which it defaults to).

Field	Notes
`published_version`	`{version, label, published_at, git_commit_sha, latest_git_commit_sha, git_pr_number}`. The head `ask_question` answers from. Null when nothing is published yet. `git_commit_sha` is the commit the version was published from; `latest_git_commit_sha` is the newest commit known to hold the same content
`has_unpublished_changes`	Whether the unpublished context differs from the published head. Always true before the first publish
`git_sync`	`{provider, repo, base_path}` when Cassis itself syncs a git repository, meaning the GitHub app integration. Null otherwise
`data_source`	`{is_executable, sql_dialect}`. Null when no data source is connected
`error`	Set instead of the keys above when the request fails

A null git_sync does not prove the context is not kept in git. It only means Cassis is not the one syncing it. A repository synced by your own pipeline with the CLI reports null here, and the repository is still the source of truth. See Connect a git repository.

Using it to confirm a merge landed

Compare published_version.latest_git_commit_sha with the commit you merged, or git_pr_number with the pull request. A GitHub App import records the merged commit. From cassis-cli 3.0.0, a CLI upload records the commit it was uploaded from, with a null git_pr_number, so the same comparison confirms a pipeline publish. An upload whose files match the published version creates no version, but it moves latest_git_commit_sha to its commit, so a checkout that changed nothing in the context still matches. git_commit_sha keeps naming the commit the version was first published from. From a shell, cassis status --watch polls the same state until it matches local HEAD.

There is no tool that returns the context itself. The tools here cover the state around it, and get_source_schema covers the warehouse layer beneath it. A schema update is planned and applied in the app or with cassis schema plan; the MCP deliberately has no tool for it.