The MCP authoring server

HiLMS speaks MCP, so an AI agent can read and write course material the way a member of staff would — under that person’s own account, their own permissions and their own name in the audit trail.

There are two ways in: over HTTP, for an agent running anywhere, and over standard input on the machine itself.

What an agent can do

Nine tools, and nothing else. It can list the courses, read the outline of one and read a lesson; it can create a course, a section and a lesson, add Markdown to a lesson, replace a lesson’s content, and set a lesson’s quiz.

It cannot publish. A course an agent creates is a draft, and only a person can publish it in the panel. It cannot add pictures, video, audio or files: media is uploaded in the panel, where its bytes are checked. It cannot touch students, enrolments, entitlements, quiz attempts, users or settings — none of that is a tool.

What it writes goes through the same doors as the editor assistants: Markdown becomes blocks through the converter, which strips raw HTML, defuses an unsafe link and reduces an image to its alt text, and a quiz goes through the same rules the block editor enforces.

Connecting over HTTP

The agent registers itself, sends its owner to an approval page in the browser, and receives a token that acts as that person.

Claude Code

claude mcp add --transport http hilms https://<your-host>/mcp/authoring

Claude Code opens the approval page in a browser. Sign in as a member of staff, read what is being asked and which host the access is being sent to, and approve. The connection is then ready; claude mcp list shows it.

Cursor, and anything else that speaks OAuth

Point the client at https://<your-host>/mcp/authoring as a streamable HTTP MCP server. It will find everything it needs on its own:

What the client asks for	Where it is
Authorization server metadata	GET /.well-known/oauth-authorization-server
Protected resource metadata	GET /.well-known/oauth-protected-resource
Register itself	POST /oauth/register
Ask its owner	GET /oauth/authorize
Exchange the code, and refresh later	POST /oauth/token

The flow is OAuth 2.1 with PKCE. Access tokens live an hour and refresh tokens thirty days, so a connection keeps working without anybody being asked again.

Who may approve

Only somebody the admin panel lets in — an administrator, an editor or an instructor. A student is refused at the approval page. This matters: approving an agent hands it everything that account can do, so the page says as much, names the host the access is being sent to, and asks for a deliberate click.

Registration is deliberately open. Any client may register itself, because an agent has no credentials before it has any — that is what dynamic registration is for. Nothing follows from registering: a registered client holds only the mcp:use scope and can do nothing at all until a member of staff approves it in the browser. The consent screen is the control, which is why it names the redirect host and why only panel users ever see it. Registration is throttled to ten new clients an hour per address.

Revoking

Every registered client is listed in the panel under Settings → API clients, marked “Agent (acts as a person)”. Revoking it there kills its tokens. Deleting the account somebody approved with takes its tokens with it: the agent acted as that person, and with the account gone it acts as nobody.

Connecting on the machine itself

For a developer working on the installation, the server also runs over standard input, with no OAuth and no browser:

php artisan mcp:start hilms-authoring

In a container, the way Laravel Boost’s own .mcp.json does it:

{
    "mcpServers": {
        "hilms-authoring": {
            "command": "docker",
            "args": ["exec", "-i", "hilms_appserver_1", "php", "artisan", "mcp:start", "hilms-authoring"]
        }
    }
}

The local server acts as the first administrator of the installation, because there is no request, no token and nobody to ask. That is a deliberate choice and not a hole: whoever can run artisan on the machine already owns it, database and all. Do not expose it to anything you would not give a shell to.

php artisan mcp:inspector hilms-authoring opens the MCP inspector against it, which is the quickest way to see the tools and try one by hand.

Configuration

config/mcp.php is not published, so its defaults apply: any redirect domain is accepted at registration, and the issuer is the application URL. Publish it with php artisan vendor:publish --tag=mcp-config if you want to narrow redirect_domains to the clients your team actually uses — the consent screen is the control either way, but a shorter list is one fewer thing for somebody to misread.