A workspace can carry other MCP servers - your CRM, your site builder, anything that speaks MCP - and hand their tools to your members' AI through the workspace connector. An admin adds a server once. Either each member connects to it once, with their own account, or the whole workspace shares one key. Put the server in a toolkit and the members who hold it have its tools next to Kythene's in their AI. Every call their AI makes through them is recorded.
It's on the Team and Enterprise plans, and on self-host with a licence that includes it.
Adding a server
Owners and admins add servers, at Settings > Servers > Add a server:
Name - lowercase letters, digits and hyphens, starting with a letter. It goes in front of the server's tool names in members' AI, so
crmmakescrm__find_contact. Renaming it renames every one of them.Address - the server's MCP address, as its docs give it.
How members reach it - Each member signs in (the default) or One shared key. See below.
Add server then reads what the server offers - its tools, prompts and skills - and the server's page lists them. With Each member signs in, it first takes you to the server to sign in with your own account. If Kythene can't read it, nothing is saved.
Each member signs in, or one shared key
| Each member signs in | One shared key | |
|---|---|---|
| Who the server sees | Each member, as themselves | One account, whoever makes the call |
| Members do | Connect once, at My tools | Nothing. It's Ready there |
| The server's own logs | Name the member | Can't tell members apart |
| Kythene's audit log | Names the member | Still names the member |
Pick One shared key for a server that wants an API key or a fixed header rather than a sign-in. You give:
- Header - where the server's docs say the key goes.
Authorizationby default, where a bare key is sent asBearer <key>; a key that names its scheme is sent as typed. Some servers use another header, such asX-API-Key. - Key - Kythene reads the server with it and saves the server only if that works.
Kythene seals the key and never shows it again, on the page or in the edit form. You replace it rather than edit it, and you need to enter it again if you change the server's address or header, so a held key is never sent somewhere new.
If the server refuses the key, it goes Failing at once, and members' calls to it fail naming the server and the key. Give a new key on its page fixes it.
Switching an existing server to a shared key reads it with the key first, then signs every member out of it, after a confirmation that says how many. Switching back to Each member signs in waits for your own sign-in, and only then discards the key.
Remove deletes the key from Kythene. It can't revoke it at the server, so do that there too.
Adding a server trusts it like Kythene's own code. Its tool descriptions and everything it answers reach the AI of every member you give it to, so only add servers you'd trust with that.
Adding a server gives it to nobody. Put it in a toolkit to hand it to members; until then the server's page and Settings > Servers say Not in any toolkit, so no one gets this yet.
What a server's page shows
Each tool has a kind, which is what the server says about it:
| Kind | Meaning |
|---|---|
| Read-only | Only reads |
| Writes | Changes things, and the server says it doesn't delete or overwrite |
| Destructive | Can delete or overwrite things |
A tool the server says nothing about counts as Destructive, as MCP has it. These are hints from the server, not guarantees.
Read what it offers again refreshes the list after the server adds or changes tools. It needs an owner or admin who's connected to the server.
A server's state
| State | What it means |
|---|---|
| Active | Working. Its tools reach the AI of every member whose toolkits hold it |
| Failing | Kythene couldn't reach it the last 3 times it tried. Members' calls to it fail until it answers, and it goes back to Active by itself |
| Disabled | Switched off by an admin. Its tools and skills are withdrawn from everyone's AI, and sign-ins are kept, so Enable brings it straight back |
A server that's down only fails its own tools. Kythene's tools and the other servers carry on.
Changing a server's address signs everyone else out of it, because their sign-ins were for the old one. (On a shared key there are no sign-ins, but you give the key again.) Remove takes it out of the workspace altogether.
Connecting, for members
For a server where each member signs in, everyone connects once, at My tools, with Connect. You sign in there with your own account and come back. The server then knows it's you, so it applies your own permissions and its own records say who did what. Kythene keeps that sign-in until you disconnect. A server on a shared key shows Ready there and has nothing to connect.
If your AI tries a tool on a server you haven't connected to, it hands you a link to connect instead. Connect, then ask your AI again.
| On My tools | What to do |
|---|---|
| Connected | Nothing. Your AI uses it as you |
| Ready | Nothing. The workspace shares one key, so there's nothing to connect, and the server sees the whole team as one account. Kythene still records which of you made each call |
| Reconnect needed | The server stopped accepting your sign-in. Reconnect, sign in there again, and come back |
| Not connected | Connect it. It won't work in your AI until you do |
| Kythene can't reach it at the moment | Nothing. The server's down, and it comes back by itself |
| Switched off by an admin | Nothing you can do. It comes back when an admin enables it |
| Not in your toolkits | Nothing you can do. Ask an owner or admin if you need it |
A server that leaves your kit signs you out of it; the toolkits page has the rules.
Viewers get a server's read-only tools only. The prompts and skills their toolkits give them reach them too, since fetching a prompt or reading a skill doesn't change anything.
Prompts and skills from a server
A server's prompts reach members' AI as <server>__<prompt>, and its skills as <server>-<skill>, next to the workspace's own skills. If a server skill has the same name as one of Kythene's or the workspace's, the server's loses. The MCP reference has the detail.
The audit log
Settings > Audit log has every call agents made through the workspace's servers: who made it, which of their agents, the server, the tool or prompt, the toolkit that gave it to them, when, how long the server took, what came of it, and the arguments and result in full. Owners and admins see everyone's calls. Members see their own.
The outcome is one of three:
- OK - the server answered
- Tool error - the tool ran and said it failed. The server was fine, the call wasn't
- Server failed - the server never answered: unreachable, timed out, or refused
Filter by member, server, name, outcome and dates. Export downloads the calls you've filtered to as NDJSON (one JSON object per line). Every export is recorded in the workspace's activity, because it takes arguments and results out of Kythene.
Calls made through Kythene's own tools aren't here. Those are in the activity timeline.
How long calls are kept
12 months by default. The workspace's owner can change it to 1, 3, 6, 12, 24, 36, 60 or 84 months. A shorter period erases every call older than it, arguments and results with them, at the next daily sweep, and that can't be undone. Each change is recorded in the activity.
Because results are kept in full, the log holds whatever the servers return - contact details from a CRM, say. Keep that in mind when choosing what to add and how long to keep it.