Let another agent read your workspace

You ask Claude: "Which projects for Meyer GmbH still have unbilled hours, and who worked them?" Claude asks kyte, kyte answers from your company's data, and the reply names the projects, the hours and the people. Nothing was copied anywhere, nothing was pasted in, and you never left the program you were already working in.

That is what this does: kyte hands another AI program its reading tools. The mechanism is MCP, a small protocol those programs use to pick up tools, and kyte speaks it as a command — kyte mcp.

What you need

The kyte command line. It is the same product as the app, without a window — see Install kyte for where it comes from. Sign in once:

kyte login

The browser opens, you confirm, the session is kept. After that kyte mcp needs nothing from you.

Connecting it

The other program starts kyte itself, so you tell it the command once. In a configuration file use an absolute path for a workspace folder: ~ is a convenience of the shell, and a JSON or YAML argument list is not a shell.

Claude in the terminal

claude mcp add kyte -- kyte mcp

Claude Desktop — in ~/Library/Application Support/Claude/claude_desktop_config.json:

{ "mcpServers": { "kyte": { "command": "kyte", "args": ["mcp"] } } }

Hermes — in ~/.hermes/config.yaml:

mcp_servers:
  kyte:
    command: kyte
    args: ["mcp"]

To see what it offers before you connect anything, ask it by hand:

printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | kyte mcp

What it can read

The reading tools of the apps your workspace has switched on — seventeen when everything is on:

App It can list
CRM organisations, contacts, deals, products
ERP projects, organisations, time entries, and the hours booked on a project
Processes the process definitions
Goals objectives, key results, goals, initiatives, teams, people
Knowledge the company's documents
Tasks the board

It reads as you: the same rows your role sees in the app, no more. A colleague's private notes stay private, because they are private in the database and not merely hidden in the interface. An app you have switched off is not in a foreign agent's hands either.

The other agent is told what it has

When the connection opens, kyte introduces itself to the other program's model: whose workspace this is, that it is read as that person under that person's permissions, that the data keeps itself current, that nothing here can be changed, and that changing data or building apps happens in kyte itself. You do not have to explain any of that in your prompt.

It stays current by itself

With a team server the workspace synchronises while the server is serving, not only at the start. The other agent needs to know nothing about it and never has to ask for a sync: it asks a question, and the answer is on the company's current state.

If the box cannot be reached, kyte keeps answering from the local copy and says so once in its log. Yesterday's answer beats no answer.

What it can never do

  • Write. Nothing is created, changed or deleted. Today the answer to "may a foreign agent change company data" is simply no; if that changes, it will be something you switch on deliberately, not something that arrives with an update.
  • Build. Apps and extensions are made in kyte itself — in the app or with the kyte agent, where the approval card is. That is a boundary, not a gap: see What Extend is.
  • Run commands or read your files. Only the tools above exist for it.

Where the data goes

This is the one thing that genuinely changes when you connect another program: what that program reads travels to that program's model, under that vendor's terms.

kyte's own agent sends through the Pirol endpoint, which replaces personal data before a message leaves the machine — see Personal data in a message. A foreign agent does not use that path. When Claude reads your customer list to answer a question, the customer list goes to Claude.

For many questions that is a reasonable trade. For some it is the wrong one. It is your decision — it should just be a knowing one.

One database, one program at a time

kyte's database takes a single connection. While kyte mcp serves an agent, do not have a kyte session open in another terminal — and two agents need two workspace folders, each with its own sign-in:

kyte login --db /Users/you/.kyte/claude
kyte mcp --db /Users/you/.kyte/claude

Each folder is its own workspace. Both show the same company only when both sync with a team server — see Alone, with Pirol Online, or on your own server. If a folder is busy, kyte says so and stops instead of opening a second connection.

And note that the command line's workspace is not the desktop app's: two folders on one machine. A team server is what makes them one company.

When something does not work

The other agent says kyte cannot answer right now — either the local session has run out (it lasts twelve hours) or the data folder is busy. The server stays connected in that case and offers a single tool that names the reason and the remedy, so ask the agent about it. Usually the remedy is kyte login, followed by reconnecting the server in the other program.

The agent still acts as the old user — it reads the session once, when it starts. After a kyte login, restart the other program or switch its kyte server off and on.

It sees old data — without a team server this folder stands alone, and its state is whatever is in it. With one, check the server's opening line: if it does not say it is syncing, the box cannot be reached.