Running your community from Claude: what an MCP server actually does
An MCP server lets an AI assistant read and change your community the way an admin would. Used well, it turns an hour of clicking into one sentence. Used carelessly, it is a key to the building. Here is how to use it well.
Short answer: an MCP server for a community platform is a connector that lets an AI assistant such as Claude call your platform's tools directly, so you can say "list members who joined this month and haven't finished lesson one" and get the answer without opening an admin panel. It works through an API key you create, so its power is exactly the scopes you grant. Give it read access first, add write access only for jobs you have tested, and review anything it drafts before it goes live.
What is MCP, in plain words?
MCP stands for Model Context Protocol, an open standard for connecting AI assistants to outside tools and data. A platform publishes an MCP server that describes its tools ("list courses", "create an event", "get a member"), and any compatible assistant can discover those tools and call them when your request needs them.
The practical difference from a chatbot is that the assistant is no longer guessing about your community. It reads your real courses, members and events, and it can take real actions. That is the whole value, and also the whole reason to be careful.
Claude Desktop, Claude Code, Cursor and Zed support MCP natively today. Because it is an open standard, other assistants can connect too as they add support.
Which community jobs are worth handing to an assistant?
The best jobs are tedious, multi-step and easy to check. Reporting is the obvious start: "Which courses have the lowest completion this quarter, and at which lesson do people stop?" or "Who are my ten most active members this month?" These are read-only, so nothing can go wrong, and they show you quickly whether the connection is useful.
Next come drafting jobs, where the assistant prepares and you approve. "Draft a five-lesson course outline from this PDF and save it as an unpublished draft." "Create next Thursday's office hours event at 6pm Eastern with a 30-person cap." "Write a welcome post for this week's new members and show it to me before posting."
Last come bulk operations: tagging every member who completed a course, adding a set of courses to a learning track, updating lesson descriptions in one pass. These save the most time and need the most care. Run each one on a small set first and check the result in the admin panel before you let it loose on everything.
A starter set of prompts
Try these in order, moving to the next only when the previous one behaves as expected. "Which community am I connected to, and how many members does it have?" (confirms the connection). "Summarize enrollments and completions for my three largest courses." (read-only reporting). "List upcoming events with their RSVP counts and waitlists." (read-only, events). "Draft a quiz of five questions for lesson two of my onboarding course, but do not publish it." (a write, kept as a draft). "Show me members who joined in the last 14 days and have not posted yet." (a list you can act on personally).
Notice the pattern: each prompt states what the assistant may and may not do. Saying "do not publish" or "show me before posting" costs four words and is the cheapest safety step you have.
The safety rules that actually matter
Rule one: scope the key. An API key should grant only what the job needs. A reporting assistant needs read scopes, not write. If a key does not include a scope like read:members, the assistant cannot see member emails at all. Start narrow and widen deliberately.
Rule two: one key per job, so you can revoke one without breaking the others. Name keys after what they do ("Claude reporting", "course drafting") and rotate or revoke any key you no longer use.
Rule three: never paste a key into a chat, a shared document or a screenshot. It belongs in your assistant's configuration file and nowhere else. Treat it like a password, because it is one.
Rule four: review before publish. Anything an assistant creates that members will see, from a course to an announcement, should start as a draft. Your name is on it, not the model's.
Here is the rule to screenshot: read scopes for curiosity, write scopes for tested jobs, drafts for anything members will see.
Hosted endpoint or local package: which setup do you need?
There are two common ways to connect. A hosted MCP server is a URL your assistant talks to over the internet, with your API key sent in a header. That suits assistants that let you configure a URL and headers, such as Claude Code and Cursor.
A local package runs a small connector on your own computer and relays requests to the platform. Claude Desktop runs local servers from its configuration file, so this is the reliable route there. For HiveLearn that is the npm package hivelearn-mcp, started with npx, which needs Node.js installed.
One trap catches many people: Claude Desktop's "Add custom connector" screen only takes a URL, with nowhere to put your key. The tools appear, but every request fails with "Missing API key". Use the configuration file instead.
When you should not connect an assistant at all
If your community is small and you already know every member by name, the admin panel is probably faster than writing prompts. If you handle sensitive data (health details, minors, legal matters) and have not checked your own privacy obligations, wait. And if nobody on your team will review what the assistant drafts, keep it read-only. An assistant amplifies the habits you bring to it, good or bad.
How HiveLearn's MCP server works
HiveLearn runs an MCP server at mcp.hivelearn.app with 96 tools covering courses, members, events, quizzes, certificates, resources, learning tracks and AI course generation. The same tools are available through the local npm package hivelearn-mcp for Claude Desktop. The setup page at /mcp builds a copy-ready configuration for Claude Desktop, Claude Code and Cursor.
The safety model follows the rules above. Keys are hashed on the server and the full key is shown once at creation; you can rotate or revoke it at any time. Each key has scopes, and the key decides which community it can reach, so an assistant cannot read or write another community's data. Every tool call is tracked per key in your admin panel. AI course generation needs its own scope, generate:ai_courses, which is never included by default. And there are no delete tools: the worst an assistant can do is unpublish, and content is never permanently removed through MCP.
Every MCP tool is backed by the public REST API at /api-docs, so the same key works for scripts as well. See the pricing page for which plan includes API keys.
Keep reading
Build yours on HiveLearn
Courses, community, events, and payments in one platform. Start free. No credit card, no time limit on Starter.
Or run the numbers first