Capability matrix

What each surface can do

Capability	Web app	MCP	CLI	Repository
Ask questions	Yes, in chat	Yes, `ask_question`	Probe only, `context test`	No
Rate answers	Yes, up or down on each answer, with a note	Yes, `submit_feedback`, on the whole chat	No	No
Read the context	Yes, Explorer and export	No	Yes, `context pull`	Yes, it is the files
Edit the context	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	`context 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, context test
Repository: No

Rate answers

Web app: Yes, up or down on each answer, with a note
MCP: Yes, submit_feedback, on the whole chat
CLI: No
Repository: No

Read the context

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

Edit the context

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: context 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 context, 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 `context 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 context 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 the context: No tool on the MCP server returns the context or edits it. An answer names the objects it used, and get_project_status reports the published version, the unpublished changes, and the git binding, but the definitions themselves are not on the wire. An agent that needs to read the context reads it from a checkout.
The CLI asks questions to prove a change, not to serve people: cassis context 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 outside your own chats, which ask_question and submit_feedback add to, and it requires the editor or admin role. It records an outcome; the context change is a separate edit.
Every publish replaces the context: All three paths replace the complete context, which is why a project should have one editing path. See Choose how your context 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.