Capability matrix

What each surface can do

Capability	Web app	MCP	CLI	Repository
Ask questions	Yes, in chat	Yes, `ask_question`	Probe only, `ontology test`	No
Read the ontology	Yes, Explorer and export	No	Yes, `ontology pull`	Yes, it is the files
Edit the ontology	Yes, on any project. Supported for app-managed projects	No	Edit local files, then `upload` when the workflow permits	Yes, on git-managed projects
Look up the warehouse schema	Yes, the Schema page	Yes, `get_source_schema`	Yes, `schema pull`	No, the snapshot is gitignored
Triage issues	Yes, the review queue	Yes, read and set status	No	Where the fix lands
Publish	Yes, the Publish button, on any project	No	`ontology upload`, when the API key permits it	A merge triggers the GitHub App or a pipeline upload

Ask questions

Web app: Yes, in chat
MCP: Yes, ask_question
CLI: Probe only, ontology test
Repository: No

Read the ontology

Web app: Yes, Explorer and export
MCP: No
CLI: Yes, ontology pull
Repository: Yes, it is the files

Edit the ontology

Web app: Yes, on any project. Supported for app-managed projects
MCP: No
CLI: Edit local files, then upload when the workflow permits
Repository: Yes, on git-managed projects

Look up the warehouse schema

Web app: Yes, the Schema page
MCP: Yes, get_source_schema
CLI: Yes, schema pull
Repository: No, the snapshot is gitignored

Triage issues

Web app: Yes, the review queue
MCP: Yes, read and set status
CLI: No
Repository: Where the fix lands

Publish

Web app: Yes, the Publish button, on any project
MCP: No
CLI: ontology upload, when the API key permits it
Repository: A merge triggers the GitHub App or a pipeline upload

Possible is not the same as recommended

Several technically permitted operations sit outside the supported production workflow. Credentials and product controls determine what is enforced.

Action	Possible	Recommended	Why
Edit in the app on a git-managed project	Yes	No	The next import replaces the complete ontology, so unpublished in-app work is lost and no conflict is raised
Publish from the app on a git-managed project	Yes. On a GitHub-synced project it commits the tree back	No	It commits the whole tree, so it can quietly revert a repo change made in parallel
Run `ontology upload` at a GitHub-synced project	Yes	No	Cassis syncs that repository itself, and the next import replaces whatever you uploaded

How publishing differs by setup

GitHub, with the app: A merge to the default branch touching the Path directory imports automatically from a webhook, and Cassis posts a sync check on the commit. Nothing to run.
Any other provider: A merge publishes nothing on its own. A pipeline job running cassis ontology upload on the default branch is what makes it live. See Set up CI.
App-managed: The Publish button. Pending edits become an immutable version.

Important cross-surface rules

MCP never returns ontology content: No tool on the MCP server returns the ontology or edits it. An answer names the objects it used, and get_project_status reports the published version, pending changes, and the git binding, but the definitions themselves are not on the wire. An agent that needs to read the ontology reads it from a checkout.
The CLI asks questions to prove a change, not to serve people: cassis ontology test runs a question through the same agent against your local files, one full run per question. cassis eval run is the regression side of the same job.
Triage is a status, never a fix: update_issue_status is the MCP server’s only write, and it requires the editor or admin role. It records an outcome; the ontology change is a separate edit.
Every publish replaces the ontology: All three paths replace the complete ontology, which is why a project should have one editing path. See Choose how your ontology is managed.

Operating guidance is not an enforced boundary. If your team needs the app to stay usable on a git-managed project, restrict who may write with domain permissions. API keys should be scoped so agents and CI can perform only the operations they own.