Aeon MCP Server: Drive Your Agent from ChatGPT or Claude

An autonomous agent that runs on a schedule has an awkward gap. It does its work at 07:00 whether or not anyone is watching, which is the point. But the moment you want something now, like running the news digest early, check what yesterday's run wrote to memory, tighten one line of the strategy, you leave the chat you are already in, open a dashboard or a terminal, and find the right button.

Aeon now closes that gap with a hosted Model Context Protocol server. Add one URL as a connector, sign in with GitHub, and the agent becomes a set of tools inside ChatGPT, Claude, Claude Code or Cursor:

https://www.aeon.fun/connect/mcp

The runs still happen where they always did: on your repo's own GitHub Actions. The chat client only sends the request.

The hosted server is part of Aeon Connect, the browser-based way to start an Aeon agent. The repo started pointing to it on 2026-10-07 (#1192), and the CHANGELOG credits the server itself to aeon-connect #66 and #68. The server code lives in the Aeon Connect project, not in aeonfun/aeon. So everything below traces to what the main repo documents: the CHANGELOG, the apps/mcp-server README, the security policy and llms.txt. Usage numbers aren't published, so none are quoted here.

The server speaks Streamable HTTP and authenticates with OAuth 2.1, using dynamic client registration, PKCE and GitHub sign-in. In practice that means any client that supports remote MCP servers can add it without a config file, an API key or a local install.

The flow has three steps:

• Add the URL. In ChatGPT, Claude or Cursor, add https://www.aeon.fun/connect/mcp as a custom connector (a custom MCP server). In Claude Code it is one command: claude mcp add --transport http aeon https://www.aeon.fun/connect/mcp
• Sign in with GitHub. The client opens the OAuth flow the first time it needs the server.
• Pick the agent. A consent screen asks which Aeon repo this client may reach. That choice is the scope of everything the client can do.

If you run more than one Aeon instance, the switch_instance tool moves the session to another of your repos. It runs a fresh GitHub check every time, so switching never relies on a stale grant.

There are about 20 tools. Grouped by what they are for:

• Run things. List the agent's skills and run one with run_skill. The run is dispatched to the repo's own GitHub Actions, the same runner a scheduled run uses, with the same harness, model and secrets.
• Read things. Read recent runs, the agent's output, and its git-committed memory. This answers "what did the agent do last night" without leaving the chat.
• Change things. Edit a skill (update_skill), the agent's direction (update_strategy) and its voice (update_soul). The last two are the files covered in Give Your Agent a SOUL.md and STRATEGY.md.
• Grow things. Install a skill pack with install_pack.
• Check things. setup_status shows how the agent is configured, including which keys are set. It shows key names only, never values.

There's one small addition. When a skill step or a Connect tool fails, the agent may send one short report through send_feedback, never with secrets or private repo contents. Those reports are the kind of input the Feedback Builder skill turns into reviewable PRs.

In practice it works like this. You're in a Claude conversation about a launch and want the competitor digest before the call, not at 07:00 tomorrow. You ask for it, Claude calls run_skill, and the run starts on your Actions. The same conversation can read the output when it lands, or read memory to see what the agent concluded last week. If the strategy is wrong, you change it there too.

For a tool that can start runs on your infrastructure, the limits matter more than the feature list. They are written into the security policy.

Secret values are never readable or writable. No tool returns a key, and no tool sets one. Keys you connect through Aeon Connect go straight into the repo's encrypted Actions secrets, and Aeon Connect does not store them. setup_status can tell you that ANTHROPIC_API_KEY exists. It can't tell you what it is. That also means you can't paste a key into a chat to configure the agent, which is deliberate. A chat transcript is the wrong place for a credential.

One repo per grant, through one GitHub App. The client reaches only the repos you approved on the consent screen, through the same Aeon Connect GitHub App the browser dashboard uses. That App is installed on one repo and requests repository-level permissions only. The write tools (run_skill, update_skill, update_strategy, update_soul, install_pack) act on that repo and nothing else. The design follows the same principle as Least Privilege for an Autonomous Agent: give the agent, and now the chat client, exactly the reach the job needs.

Access expires and is easy to revoke. Unused access expires after 30 days. To cut access at once, uninstall the Aeon Connect GitHub App or remove the repo from it.

It does not make a public agent private. If the instance is a public fork, its memory/, output/ and run logs are public, MCP or not. The fix is upstream of the connector: make the instance a private repo (a generated copy, since GitHub forbids private forks of a public repo).

The hosted server is new, but Aeon has shipped a local MCP server in apps/mcp-server for a while. The earlier post aeon on the Wire: MCP and a Fleet of Forks covers it. They solve different problems:

• Add it with - Hosted (Aeon Connect): https://www.aeon.fun/connect/mcp. Local (apps/mcp-server): bin/add-mcp.
• Transport - Hosted: Streamable HTTP, OAuth 2.1, GitHub sign-in. Local: stdio.
• Works in - Hosted: ChatGPT, Claude, Claude Code, Cursor, any remote MCP client. Local: Claude Code, Claude Desktop.
• Skills run on - Hosted: Your repo's GitHub Actions. Local: Your machine, via harness-adapter/run-harness.
• Tools - Hosted: About 20 (run, read, edit, install, switch). Local: One aeon-<slug> tool per skill.
• Needs - Hosted: An Aeon repo with the Aeon Connect GitHub App. Local: A clone, Node, a signed-in harness CLI, your skill keys.

The local server reads catalog/skills.json and turns every skill into its own tool, such as aeon-digest or aeon-pr-review, each with a single optional var input. A call runs the exact SKILL.md prompt the scheduled runner uses, with the same tier, tools and model resolution, and a 30-minute timeout that matches CI. Two recent fixes are worth knowing about. A multi-line var is now folded onto one prompt line (#1204), and a failed skill run now comes back as an MCP error instead of looking like success (#1209).

Choose hosted if you want ChatGPT or Cursor, nothing to install, and runs that happen on the agent's real infrastructure. Choose local if you want every skill as a separate tool and are happy to run skills on your own machine with your own keys.

Using both? bin/add-mcp registers the local server as aeon and first runs claude mcp remove aeon, which would delete a hosted entry with the same name. The script warns when it sees one. Register the hosted server under another name to keep both:

claude mcp add --transport http aeon-cloud https://www.aeon.fun/connect/mcp

Which AI clients can connect to the Aeon MCP server?

Any client that supports remote MCP servers over Streamable HTTP with OAuth. The repo names ChatGPT, Claude, Claude Code and Cursor.

Does the Aeon MCP server run my agent on Aeon's servers?

No. Skills run on your repo's own GitHub Actions. Aeon Connect hosts the dashboard and the MCP endpoint, not the agent.

Can the MCP server read my API keys?

No. Secret values are never readable or writable over it. setup_status reports key names only.

How do I revoke access?

Uninstall the Aeon Connect GitHub App or remove the repo from it. Unused access also expires on its own after 30 days.

Do I need an Aeon agent first?

Yes. Create one in the browser at www.aeon.fun/connect, or clone the repo and run ./aeon init, then add the connector.

Until now there were two ways to talk to an always-on agent: wait for its schedule, or go to its dashboard. The MCP server adds a third, which is to ask from wherever you already are. The agent keeps its own infrastructure, memory and keys, and the chat client gets a scoped, revocable handle on it. That split is what makes it safe to plug an autonomous agent into a general-purpose assistant. The assistant can steer the agent, but it never holds the agent's keys.

Already have an Aeon agent? Add https://www.aeon.fun/connect/mcp as a connector, sign in with GitHub, pick the repo, and ask your assistant to list your skills. Don't have one yet? Start at www.aeon.fun/connect. The local server and its docs are in apps/mcp-server.

Aeon is open source, with 86 skills in the public catalog. The repo is at github.com/aeonfun/aeon and the project posts as @aeonframework.