Connectwayworks × your assistant
One endpoint. One bounded agent.
Connecting wayworks to an assistant takes a few minutes and happens once per agent. An administrator mints a token, you paste two lines into the assistant you already use, and from then on the work is answerable from the window you already have open — inside whatever that agent was permitted to do, and nothing else.
not a login.
an agent, with limits
Before you worry
Nothing to install. Nothing to roll out.
The usual first question is whether this means another piece of software for IT to deploy. It does not. Everything below happens inside an app your people already have, and the part that needs care is a permissions decision rather than an installation.
It is a config file, not an app
Two lines in a settings file your assistant already reads. No installer, no admin rights on the laptop, no software going through review.
An agent is not an account
There is no username and password for this. An administrator creates an agent, grants it named capabilities, and it can do those and nothing else.
The tab count goes down
This does not add a place to check. It removes the reason to open the other ones, because the question can be asked where you already are.
The mechanic
How access actually works.
Worth two minutes before the setup, because it is the part that makes the rest safe — and the part most people assume wrongly.
- ONEAn administrator creates the agent
In the workspace, under Administration › MCP Agents. The agent is given a name, a set of capabilities, and a list of people it is allowed to act as. Those three things are the whole of its authority.
- TWOIt issues a token, once
The token looks like
lmcp_…and is shown exactly once — only a hash is kept, so it cannot be read back later. If it is lost it is rotated, not recovered. - THREEYou paste the endpoint and the token
Your assistant sends the token on every call as an
Authorizationheader. That is what identifies the agent, which is what decides what the next call is allowed to do. - FOUREvery call is checked and written down
Each call is capability-checked, scoped to your organisation, and appended to an audit log. An agent cannot grant itself more than the person who created it had to give.
shown once.
rotated, never recovered
Pick the one you use
Wherever you already ask.
wayworks is added the way these apps add any connector — an open standard rather than a private integration — so the setup is nearly the same everywhere. Pick yours;
the others are none of your concern. Replace
<AGENT_TOKEN> with the lmcp_… token, and
yourcompany with your own workspace.
Claude Desktop reads claude_desktop_config.json; Claude
Code reads .mcp.json in the project. The block is the same in both.
most common
{
"mcpServers": {
"wayworks": {
"type": "http",
"url": "https://yourcompany.wayworks.space/mcp",
"headers": { "Authorization": "Bearer <AGENT_TOKEN>" }
}
}
}On the desktop app the file is under Settings › Developer › Edit
Config, then quit and reopen the app completely — it reads the file on start,
not live. In Claude Code, claude mcp list confirms it connected.
- Where the file lives
~/Library/Application Support/Claude/claude_desktop_config.jsonon macOS,%APPDATA%\Claude\claude_desktop_config.jsonon Windows. - Claude on the web
Custom connectors in the browser expect the server to handle sign-in itself rather than take a token you paste. Until that is available, use the desktop app or Claude Code — both take the header above.
VS Code keeps MCP servers in a small JSON file — one for the workspace, one that follows you. for developers
{
"servers": {
"wayworks": {
"type": "http",
"url": "https://yourcompany.wayworks.space/mcp",
"headers": { "Authorization": "Bearer <AGENT_TOKEN>" }
}
}
}Put this in .vscode/mcp.json for the workspace, or run MCP: Open
User Configuration from the command palette
(⇧⌘P) for the one that follows you
between projects. MCP: Add Server walks through the same thing with
prompts.
never commit the token.
it is a credential
Cursor reads .cursor/mcp.json in the project, or the
same file in your home directory for every project.
for developers
{
"mcpServers": {
"wayworks": {
"url": "https://yourcompany.wayworks.space/mcp",
"headers": { "Authorization": "Bearer <AGENT_TOKEN>" }
}
}
}Windsurf, Zed and most other editors use this same shape. If yours asks for a transport, it is Streamable HTTP; if it also offers SSE, prefer HTTP, because SSE is deprecated.
Codex reads ~/.codex/config.toml. Newer builds speak
remote MCP directly. for developers
[mcp_servers.wayworks] url = "https://yourcompany.wayworks.space/mcp" bearer_token = "<AGENT_TOKEN>" experimental_use_rmcp_client = true
If your Codex build does not speak remote MCP, use the bridge under Anything else instead — it works with every version.
Some clients can only start a program on your own machine rather
than call a URL. mcp-remote bridges the two.
universal fallback
{
"mcpServers": {
"wayworks": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://yourcompany.wayworks.space/mcp",
"--header", "Authorization:${AUTH_HEADER}"],
"env": { "AUTH_HEADER": "Bearer <AGENT_TOKEN>" }
}
}
}- The one gotcha
mcp-remotesplits--headeron spaces. Keep no space afterAuthorization:and pass the value through the environment variable exactly as above, or the connection returns 401. - It needs Node
Version 18 or newer, because
npxfetches the bridge on first run.
The part that matters
An agent is not a user with a bigger token.
This is the question every security review asks, so here is the answer before it is asked. Connecting an assistant does not open a new door into the business. It opens a bounded one, and it writes down what goes through it.
- Capabilities, named one by one
An agent holds a list of capabilities, not a role that quietly grows. A tool it has no capability for returns a policy denial rather than a result — and the denial says which capability was missing.
- It can only act as named people
Anything touching a person's own data — their leave, their payslip, their timesheet — must name that person on the call, and the agent may only name people on its own allowed act-as list.
- It cannot exceed the person who made it
No agent escalates beyond its grantor's authority. Every call is checked against your policy and scoped to your organisation.
- Consequential things still ask
Reading is quiet. Payroll has a preview that consumes nothing. Destructive and outward-facing actions are meant to be confirmed by a person, and the record shows who.
- Everything is attributed
Who asked, what ran, what changed and when — appended to a log that cannot be edited, kept beside the work rather than in a chat thread.
- Least privilege is the default advice
An admin agent with an empty act-as list can act as anyone in the organisation. Treat it as a root credential, keep it to one machine, and mint a narrower agent for anything shared.
If it does not work
Four things, in this order.
- 401 on connect
Almost always the header. Check there is no space after
Authorization:in a bridged config, that the token startslmcp_, and that nothing was truncated on paste. - The tools do not appear
Quit the assistant completely and open it again — not the window, the app. Config is read on start.
- "needs as_user"
You asked for something personal without saying whose. Name the person on the call; the agent can list the people it is allowed to name.
- "requires capability"
Working as designed. The agent was not granted that one — an administrator can add it, or you can mint a different agent for that job.
— and if none of that is it, write to us and we will look
Where that leaves you
Connect it, then ask it something.
The setup is a few minutes and the habit is the rest. Most people start by asking the thing they would otherwise have gone looking for — where did it get to, who is waiting, what changed since Friday — and stop opening the other tabs within a week.
— one endpoint, one bounded agent