# Limits and errors

Every cap and every failure mode in one place, across the MCP server and the CLI.

## Asking questions

- **Question timeout** 5 minutes. A question that takes longer returns an error and closes the chat turn.

- **Result rows** Up to 100 rows inline, with `truncated` marking a capped result set. For more, narrow the question or ask for aggregates.

- **Zero rows** Not an error. The query ran and matched nothing.

- **Null results** The SQL was not executed. On a schema-only project that is always the case: see [Connect a warehouse or upload DDL](/setup/warehouse/).

- **Not answerable** The approved plan cannot run against the current ontology or data. Retrying the same question will not help. See [ask\_question](/reference/mcp/ask-question/).

- **Model overloaded** When the model is briefly overloaded or rate-limited, the tool returns a plain-language message rather than a raw error. Retry in a moment.

## MCP server

- **Source schema detail** `get_source_schema` details at most 20 tables per call. Call it again for more, or use [`cassis schema pull`](/reference/cli/schema/) for a full local snapshot.

- **Error convention** Every tool reports a failure as an `error` key in place of its normal fields, rather than raising.

- **Roles** Reads need an active account in the project’s organization. `update_issue_status` needs the editor or admin role. Chats are author-only over MCP: an org admin can read a colleague’s chat in the web app but not through the server.

- **Idle sessions** A session with no activity for 30 minutes expires. A client that reconnects initializes a fresh session, so long-running agents are unaffected.

- **Credential expiry** Expired or revoked credentials return HTTP 401. OAuth clients re-run the flow automatically; an API key has to be replaced.

- **Unreachable project** Querying a project the authenticated user cannot access returns an error rather than an empty result.

## CLI

| Code | Meaning |
| --- | --- |
| `0` | Success. For `check`, advisory warnings never change this. For `test`, every probe completed, whatever the outcome |
| `1` | The thing failed on its own terms: validation findings, failed eval cases, a duplicate eval case, a case id that does not exist, a failed detection run, or `verify` stopping at a failing step |
| `2` | Usage error: missing API key or project, no ontology directory, an unreadable file, or a tree over the size limits |
| `3` | Transport or API error: unreachable API, invalid key, inaccessible project, another run already active, out of credits, or a timeout |
| `130` | Ctrl-C during `eval run`. The run is cancelled server-side |

- **Tree size** Commands that send the local tree accept up to 20,000 ontology files (YAML plus `domains/**/README.md`) and 100 MB total, sized for roughly 10,000 modeled tables. Beyond that the CLI fails fast with exit 2 before uploading anything. If you hit it, check `--base-path`. On cassis-cli older than 1.5.1 the client stops at the previous ceiling of 2,000 files and 5 MB, whatever the server accepts.

- **DDL size** `cassis schema push` sends the file inline, and the API rejects a DDL over 10 MB. A whole-warehouse export above that has to be pushed schema by schema, which a push handles: it updates only the schemas in the file. See [Review data-source changes](/curate/data-source-changes/).

- **Eval run timeout** 30 minutes by default, `--timeout` to change it. The run continues server-side if the CLI stops waiting.

- **Detection run timeout** 10 minutes for `schema push`, same behavior.

- **Probe duration** `ontology test` is one full agent run per question, roughly 30 to 90 seconds each.

## Imports and publishing

- **Failure is safe** On malformed YAML or a missing required field, Cassis keeps its previous ontology. Nothing is half-imported.

- **Idempotence** Re-importing or re-uploading identical content creates no new version.

- **Complete replacement** Every import and publish replaces the complete ontology. This is why a project should have one editing path: see [Choose how your ontology is managed](/start/choose/).

Failure-by-failure fixes for the git loop are in [Troubleshoot git and publishing](/build/troubleshooting/).