Actions

Answering is half of support. The other half is doing something: looking up an order, checking remaining credits, starting a return. Actions let Murphy call your tools mid-conversation.

Murphy speaks MCP, so you point it at an MCP server instead of waiting for us to build an integration for your stack. If your API already has one, you are done. If it does not, wrapping your own API is a small amount of work and you own it.

Connecting a server

Add the server in Integrations. You give it a name, a URL, and an auth header if it needs one. Murphy discovers the tools the server exposes and shows you the list.

You then pick which tools Murphy may call. Only tools on that allowlist are callable. Everything else on the server stays invisible to the agent.

What keeps it safe

Allowlist, not blocklist. A tool Murphy was never granted cannot be reached, so the default for anything new is no.

Frozen at approval time. Tool definitions are captured when you configure the server. If the server later adds a tool, or changes what an existing one does, Murphy keeps using the definitions you approved until you approve again. A compromised or careless upstream server cannot quietly widen its own permissions.

Audited. Every call is logged as an agent event with its arguments, sitting next to the answer it produced. When a customer says Murphy did something strange, you can see exactly what it called and with what.

Config shape

Stored on the workspace:

{
  "servers": [
    {
      "name": "backend",
      "url": "https://api.example.com/mcp",
      "authHeader": "Bearer ...",
      "allow": ["get_order", "check_credits"],
      "tools": [{ "name": "get_order", "description": "..." }]
    }
  ]
}

Scoping advice

Give Murphy read tools first and live with it for a week. Reads are recoverable, writes are not. When you do grant a write, prefer a narrow tool (start_return for one order) over a general one (update_order with arbitrary fields). The allowlist is only as good as the granularity of the tools behind it.