Customise

Customise is where you extend your agent. Everything in it is yours: the HTTPS endpoints you want it to call, the MCP servers you want it connected to, the way you want a class of task approached, and the API keys you use to reach your account from outside the app.

Kaer ships nothing into these lists. There is no built-in tool catalogue and no default skills — an empty Customise area is the correct starting state, and it fills up with entries you wrote.

The four sections

Tools, MCP servers and skills all follow the same rhythm: add an entry, see what state it comes back in, enable it, and use it. API access works differently and is covered in full in Account API.

Tools: your own endpoints

A custom tool is an HTTPS endpoint of yours that the agent can call mid-task — an internal API, a webhook, a lookup service. You describe what it does and when it should be used; the agent decides whether a given request calls for it.

Adding a custom tool

Open Customise → Tools, choose Add tool, and fill in the form.

Writing a tool that works well

The two fields that decide whether a tool is useful are the description and the usage note, and they do different jobs.

• Describe, don't instruct. The description should say what the endpoint does — "Returns current stock and next restock date for a SKU" — not what the agent should do about it. Descriptions written as commands to the agent make a tool harder to place, not easier.
• Make the usage note specific. "When someone asks whether a product is in stock, how many units are left, or when a SKU will be restocked" is a usable trigger. "For stock stuff" is not, and a vague note is the usual reason a tool either sits unused or fires at odd moments.
• Give every parameter a description. The agent fills parameters from the conversation, and one clear line — including the format, if the format matters — is what makes it fill them correctly.
• Mark a parameter required only if it really is. Required parameters the agent cannot infer will stall a call that would otherwise have worked.
• Keep the timeout tight. A tool that answers in a second should not be given fifteen; a short timeout fails fast instead of holding up a turn.
• Put your endpoint's own auth in Headers. That is what the header rows are for. Do not put a credential in the URL.

A worked example

You run a small internal stock service and want the agent to answer stock questions without you looking anything up.

Saved and enabled, a turn using it reads like this:

You    Do we still have any AC-1044-BLK, and when's the next batch in?
Blob   Using warehouse_stock…
       42 units in Bristol, next restock 12 August.

When the agent uses a tool

Only when a request actually calls for it. The agent matches what you asked against your usage note, and reaches for the tool when the two line up. It does not fire tools proactively, run them to see what happens, or use one just because it exists.

That makes the usage note the real control surface. If a tool is being used more often than you want, tighten the note; if it is never being used, the note is probably too narrow or too vague to match anything you actually say.

Test run

Entries that are working carry a Test run button. It calls your endpoint once, with parameters you supply, and shows you what came back — the fastest way to confirm the URL, headers and shape are right before you rely on the tool in real work.

MCP servers: connect your own systems

If you already run an MCP server — over your codebase, your documents, your data, your preferences — register its URL here and your agent can use the tools that server advertises.

Open Customise → MCP servers, choose Add MCP server, and provide:

A worked example: you run an MCP server over your design system at https://mcp.acme.dev/sse, authenticated with a bearer header. You allow-list search_components, get_component because those are the two you want used, and leave the server's write tools out. Ask for a component and the agent looks it up in your design system rather than guessing.

The allow-list is worth using. An empty allow-list is convenient on a server you fully trust and control, but naming the handful of tools you actually want keeps the agent's options narrow and predictable — and a server that later advertises new tools will not quietly acquire them.

Skills: how you want a task approached

A skill is your way of having a class of task done. Not what the agent can do — how you want it done, in the order you want, finishing where you say it finishes. Skills only activate when a request matches their conditions, so a skill for release notes has no effect on anything else you ask.

Open Customise → Skills, choose Add skill, and fill in:

A worked example

Name: Weekly release notes

Strategy: Pull the merged pull requests since the last release, group them into Added, Fixed and Changed, and write one line per change in plain English aimed at customers, not developers. Lead with the change users will notice most. No internal ticket numbers.

Applies when:

I ask for release notes
A changelog needs drafting

Tool order: github_prs, summarise, draft

Done when:

Every merged PR is covered
Each line reads as a user-visible change

Error playbook: if the error looks like no PRs found in range, widen the range to the last 14 days and say so in the draft.

Writing a skill that behaves

• Keep "applies when" specific. These conditions are the whole switch. Broad ones ("when I ask about work") pull the skill into turns it has no business shaping; specific ones fire exactly when you meant them to.
• Write the strategy as method, not as rules for the agent. "Group by Added, Fixed, Changed and lead with the most visible change" is method. It travels better than a list of instructions about how to behave.
• Use "done when" to stop the drift you keep correcting. If you find yourself sending the same follow-up every time, that follow-up is a done-when criterion.
• Add error rows only for errors you have actually hit. The playbook is most useful when it encodes the recovery you already know works.
• One skill, one class of task. A skill that covers three kinds of work is three skills that will all fire at the wrong moment.

Entry states: working, Flagged, Not ready yet

New and edited entries are checked before your agent can use them, and an entry ends up in one of three states.

A flagged entry always tells you what to change — it is a list of specifics, not a verdict. Fix what it names and save; editing an entry re-checks it, so you find out immediately whether the change landed.

Talk to Kaer about this

Flagged entries offer Talk to Kaer about this. It opens a chat already loaded with that entry's specifics, so you can work through it in conversation instead of guessing at the form: ask what the suggestion means, ask for a better usage note, try wording and see what comes back. It is usually faster than editing fields one at a time.

Ask Kaer to build the entry for you

You do not have to start from a blank form. Ask Kaer in the header — and Ask Kaer to help on an empty section — opens a chat where you describe what you want in plain language and work the entry out together.

This is the better path when you know the outcome but not the shape: "I've got an internal endpoint that returns order status, I want the agent to use it when someone asks where an order is." Describing the job is easier than filling in nine fields, and you can still edit the result afterwards.

Enabling, editing and removing

• Enable or disable any entry individually with its switch. A disabled entry stays in your list with everything you wrote intact — your agent simply will not use it. This is the right move when a tool's endpoint is down for maintenance, or when you want to check whether a skill is what is shaping a result.
• Edit an entry at any time. Saving re-checks it, so a change can move an entry between states — including out of Flagged once you have addressed the suggestions.
• Remove an entry you no longer want. Anything that depended on it stops using it.

Good to know

• Customise vs Connectors. Connectors are official, pre-built links to services other people run — GitHub, Slack, Google — connected by signing in and granting scopes. Customise is for systems Kaer has no connector for: your endpoints, your MCP servers, registered by you with your own credentials. Use a connector when one exists; use a custom tool or MCP server when it does not.
• Customise vs Assistants. An Assistant is a saved specialist you deliberately open and work with. A skill is a way of working that applies itself whenever a request matches its conditions, whoever you are talking to.
• Does this cost credits? Adding entries costs nothing. The agent work that uses them is metered like any other work — see Billing and Usage.
• Do custom tools work in workflows and automations? Yes. An enabled tool is available to your agent wherever it is working, including Workflows and Automations.
• Where do API keys live? In Customise → API access. Creating keys, scopes, endpoints and curl examples are all in Account API.