The same data is reachable a couple of ways: running the binary yourself at a terminal, or connecting an AI app you already use to a local or remote MCP (Model Context Protocol) server. Which one fits depends on where you’re sitting, not on the product.

​
By situation

Writing a script, or building an agent or integration that calls these CLIs itself? See Developers.

​
Honest limits

The remote Moodle MCP server is read-only. submit is only available from moodle mcp serve, the local stdio server, because uploading files needs them to already be on the machine the server runs on.
Ed Discussion’s create_thread and reply_thread MCP tools are disabled by default on every Ed MCP surface. Enable them with EDSTEM_ALLOW_POSTING=1 (stdio) or the Worker variable MCP_ALLOW_POSTING=1 (a self-deployed Worker); the hosted server grants posting scope at OAuth consent instead. Posting request and response formats have been checked only against mocked Ed responses, not the live API.
OnTrack has no MCP server in this release. Every OnTrack integration goes through the ontrack binary directly — a hosted or local MCP client cannot reach OnTrack. If your AI app needs OnTrack data, it has to run the CLI itself, the same way a coding agent does.

MCP servers

Exact endpoints, auth methods and which one to connect for Moodle and Ed Discussion.

Developers

Scripting the CLIs, agent skills, and MCP internals.