Projects and status
Three tools for orienting: is the server reachable, which projects can this credential see, and what is published on one of them.
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 every other tool needs.
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 ontology state in one call: which version is published, whether a merge synced and published, whether anything awaits publication, and whether detected source changes are waiting for review. Parameters: project_id.
| Field | Notes |
|---|---|
published_version | {version, label, published_at, git_commit_sha, git_pr_number}. The head ask_question answers from. Null when nothing is published yet |
has_unpublished_changes | Whether the unpublished ontology 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 |
pending_source_changes | {total, breaking}. Detected source changes awaiting review. breaking counts the ones a curated object already depends on: read list_source_changes before editing the affected tables |
error | Set instead of the keys above when the request fails |
A null git_sync does not prove the ontology 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 GitHub App merge landed
When git_sync is set, compare published_version.git_commit_sha with the commit you merged, or git_pr_number with the pull request. From a shell, cassis status --watch polls the same state until it matches local HEAD. A CLI upload has null git metadata, so confirm that route from the upload job’s exit status and the published version instead.
There is no tool that returns the ontology itself. The two tools here cover the state around it, get_source_schema covers the warehouse layer beneath it, and list_source_changes covers what has moved in that layer since.