# 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.

```yaml
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.

```yaml
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`](/reference/mcp/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](/build/git-connect/).

## 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`](/reference/cli/projects/) 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`](/reference/mcp/source-schema/) covers the warehouse layer beneath it, and [`list_source_changes`](/reference/mcp/source-changes/) covers what has moved in that layer since.