We’re building Ever Works in public. Some things may be incomplete, missing, or broken while we continue improving the platform.We’re building Ever Works in public — expect a few rough edges.
Product
Everything the dashboard does is an authenticated REST call, which means everything is also yours to automate. The developer kit is the set of official ways in: the REST API and its OpenAPI document, the MCP server that turns that API into tools an assistant can call, the CLI for terminals and CI, Skills that package know-how for Agents, a plugin SDK for new capabilities, and templates you can fork. Each one is a client of the same platform, signed in as you.
Six pieces, all documented, all working against the same account and the same credential model.
Works, Missions, Ideas, Agents, Tasks, plugins and billing sit behind one REST API described by an OpenAPI document. Authenticate with an ew_live_ key, receive HMAC-signed webhooks for generation and deployment events, and fire inbound triggers that open a Task.
127 whitelisted API operations as typed tools, plus six Knowledge Base tools, register_work and ping. Run it over stdio on your machine, over streamable HTTP from the published container, or use the hosted endpoint at mcp.ever.works.
npm install -g ever-works-cli installs the ever-works binary: auth, work, plugins and kb command groups, with a non-interactive subset that drops straight into CI. MIT-licensed, Node 20 or newer.
A Skill is a SKILL.md file — YAML frontmatter plus instructions — that any Agent can bind. Pull from the public ever-works/skills catalog or write your own with companion scripts and references, then call one in a task chat by typing its slug after a slash.
Add a capability the platform does not have — a model, a search engine, a deploy target — against the @ever-works/plugin SDK and its 33 typed capability interfaces: one manifest, one class, JSON-schema settings. 102 plugins already ship this way.
Fork a built-in base into your own GitHub account, or register any GitHub repository as a template of your own. Every Work generated from it lands in your Git as ordinary code you can keep editing.
Against the hosted API at api.ever.works, or your own install on port 3100.
Open Settings → API Keys, click Create API Key, name it after the client and give it an expiry. The full ew_live_ key is shown once — put it straight into your secrets manager.
curl https://api.ever.works/api/works -H "x-api-key: ew_live_…" lists the Works on your account. If that returns what you expect, every other route is open to the same credential.
Build the MCP server from the repository and add an mcpServers entry pointing at its stdio entrypoint, with your key and API URL, to claude_desktop_config.json, your project .mcp.json, or any MCP-compatible client’s config. Restart the client, call ping, and it answers pong.
ever-works work register --repo … turns a repository carrying .works/works.yml into a queued Work in one non-interactive call. Subscribe a webhook and your pipeline hears about every generation and deployment that follows.
The kit assumes some of its callers are not people. These are the entry points written with an agent on the other end.
GET /.well-known/agent.json publishes what the platform can do and where to call it, so an agent can discover Ever Works without a human pasting instructions.
POST /api/register-work with a repository URL and a GitHub token creates the account if needed, reads .works/works.yml, and returns a status URL and the assigned subdomain — idempotent per identity and repository.
POST /api/v1/chat/completions speaks the chat-completions wire format, so any client that takes a custom base URL can talk to Ever Works. Send x-work-id and answers come from that Work’s Knowledge Base, with citations.
The kb tools and CLI commands address documents by path as well as id, so brand/voice is an argument. Lock a document once and no agent run can quietly rewrite it.
The kit is a set of clients over one API, and it is worth knowing where each one stops before you build against it.