Skip to main content

Tools & connectors

Celeris starts with a small set of built-in tools and grows into whatever you connect. What Celeris can do for you is exactly the set of tools it can reach.

A tool does a whole task​

Most of what Celeris can do is packaged as one tool per job rather than one tool per operation. Raising a pull request is a single tool that drives git and the GitHub CLI, not six steps a model has to get right in order.

That is deliberate. A step that succeeds nine times in ten succeeds about half the time when you need six of them in a row. Putting the fixed parts in code leaves one decision to make instead of six, which is why a fast model can be relied on for the work. It also means one approval instead of twelve.

Built-in tools​

Every install ships with the basics: run a command in a named working folder, read a file, search, list a folder, resolve a loose reference like "the invoices folder", and put a result on your clipboard. The reads let Celeris work out where it is before it acts.

Software-development tasks are packaged on top of these: raise a pull request, review one, fix its failing checks, upgrade dependencies, start local servers.

Connectors​

A connector links Celeris to a service you already use, such as a calendar, mail, documents, chat or an issue tracker, and brings that service's operations in as tools. Add one from Settings → Tools → Connectors.

Connectors that need an account sign you in through your browser rather than through a pasted secret. Celeris opens the provider's own consent page, you approve the access there, and the token that comes back is stored in your operating system's keychain. Tokens never reach the Celeris interface. You can revoke a connector at any time from the same settings page, or from the provider.

Every operation a connector adds is checked like any other tool, so reading your calendar runs without asking while sending mail asks first.

The Catalogs page, where you add catalog sources of your own and install from them, is a Labs feature. It is built into nightly builds and switched off until you turn it on in Settings → Labs.

MCP servers​

Celeris speaks the Model Context Protocol, so any MCP server you run appears as a set of tools. Add one under Settings → Tools → Connectors → Add MCP server. Its tools then take part in the same routing and the same approval rules as everything else.

Celeris's own MCP server​

Celeris can also expose itself as an MCP server. Turn on Celeris MCP server under Settings → Safety to let any program running as you on this computer read Celeris sessions, settings and learned context, and start tasks through the local server. It has no token, so enable it only for programs you trust, and keep Celeris running because the server does not start the app.

Tools you make yourself​

Two routes, neither of which needs you to write a connector.

A user tool wraps a shell command you already type, so deploy-staging or tail-prod-logs becomes something Celeris can call. It declares what it touches, and how far Celeris will trust it is capped, because you wrote it rather than because it says it is safe.

A skill is a reusable way to do work. Celeris can grow one with you: describe a repeated task roughly and let it try. Each attempt that misses patches a step. When the plan survives a run unchanged, it becomes a tool Celeris can call like any other.

Celeris also discovers packaged skills. A packaged skill adds know-how, such as your house style or a release checklist, and no operations. It can change how Celeris does something. It can never widen what Celeris may do.

Choosing what Celeris uses​

Disable a connector, or a single operation, whenever it is not welcome. Denying a call keeps Celeris off it for the rest of the session. Celeris also prefers the tools it has seen work on tasks like yours.

Next​