Your automation server,
operable by an agent.
InTouch AI ships a 275-tool MCP server. Point Claude Code — or any MCP client — at it, and the agent can build, schedule, run, inspect and repair real automation on your server. Not a chat window bolted to the side. The actual engine.
And it runs the other way too: InTouch is itself an MCP client, so the tools your agents already use become tools your automations can call. Every call in either direction is a real session — scoped by the same access control, drawing on the same encrypted credential vault, written to the same audit log as a human operator. The agent gets no privileges a person wouldn’t.
Claude Code drives InTouch
The MCP server ships inside the install. It exposes the full REST surface — 275 tools, every one prefixed intouch_ — over a session it opens at startup and closes cleanly at shutdown.
Build and change automation
Create workflows and tasks, wire schedules and file triggers, install tools and skills from the InTouch Hub, define monitors, manage credentials and runtime environments — the same operations the UI performs, because it is the same API underneath.
Run it and read the result
Start a workflow, run one task, run a range, cancel a run, then pull the execution log, the run history, the active work list and the result codes. An agent that can only start things is a liability; this one can read what happened and say why.
Operate the server
Status, sessions, settings, licence state, users, groups, roles, backup and export. What any given agent may actually touch is decided by the account it logs in as — not by the protocol.
InTouch drives everything else
InTouch is also an MCP client. Configuration lives in $INTOUCH_HOME/mcp.json — the same shape Claude Desktop uses — and the built-in InTouch MCP server is registered there automatically at startup.
Add any MCP server
Drop a Gmail, filesystem, GitHub or in-house MCP server into mcp.json and reload. Its tools join the AI assistant’s tool surface immediately, translated into whichever tool format the configured provider expects — Anthropic, OpenAI or Gemini — so the choice of model never dictates the choice of tools.
Under the same wall
An external MCP tool called from a workflow is still a task in a workflow: owned, logged, alertable, and subject to the same access control as every other task. Reach does not become a hole.
Four lines of configuration
The server is a single Python file in your install, at intouch-mcp/intouch_mcp.py. Point your MCP client at it and give it an account.
{
"mcpServers": {
"intouch": {
"command": "python",
"args": ["/path/to/intouch-mcp/intouch_mcp.py"],
"env": {
"INTOUCH_URL": "https://your-server:2200",
"INTOUCH_USER": "your-agent-account",
"INTOUCH_PASSWORD": "...",
"INTOUCH_SERVER": "intouch"
}
}
}
}Give the agent its own account, not yours. The MCP server operates with exactly the permissions of the user it logs in as; anything outside them comes back as a permission error, and the attempt is on the record. On editions with role-based access control you can hand an agent one area, one track, or a single workflow — and nothing else.
Ask in your own words
“What failed last night, and why?”
“Build me a workflow that pulls yesterday’s orders, checks them against the ledger, and emails me the mismatches at 6am.”
“Run the close job from task 4 and tell me when it lands.”
“Which workflows use the expiring credential, and what breaks if I rotate it?”
Agents are getting good at building automation.
Nobody is governing what they build.
An agent that can write an integration on demand makes a catalogue of pre-built connectors worth less every month. What it cannot do on its own is prove who ran what, keep a secret out of a model’s context, stop one team touching another team’s work, or answer for a change six months later. That is the part InTouch was already built for — and now an agent can reach it directly.