Giving an AI employee a new skill with MCP connectors, and what keeps it safe

When a new colleague joins, you do not hand them the master key on day one. You give them a labelled key to the one cupboard they need, you show them which shelf to use, and if something goes wrong you can see what they took out. If they leave, you change that lock, not every lock in the building.

Giving an AI employee a new skill on Wetel works the same way when the skill lives in another system: a calendar, a project-tracking tool, a booking system your team already runs. If that system offers an MCP server, you register it once as an MCP connector, and a step in the AI employee’s workflow calls one named tool on it. No plugin to write, no code deployed on Wetel’s side.

This post is for the developer wiring it up and the operations lead who has to be comfortable with it: what a connector is, how a workflow calls a tool, what keeps each call safe, how to test it, and what is not built yet.

What is an MCP connector?

A connector is your MCP server’s address plus the credential to reach it, registered once in your workspace. The Model Context Protocol (MCP) is an open standard: a server publishes a list of tools, each with a name, a description and an input schema, and a client calls them. Wetel is the client.

You register a connector with a signed-in dashboard login (not an API key), giving it a name, the server’s URL and the server’s key:

mutation CreateMcpConnector($input: CreateMcpConnectorInput!) {
  createMcpConnector(input: $input) {
    id
    name
    serverUrl
  }
}

{
  "input": {
    "name": "Library Catalog",
    "serverUrl": "https://tools.example.com/mcp",
    "apiKey": "REPLACE_WITH_YOUR_MCP_SERVER_API_KEY"
  }
}

That apiKey is the labelled key. Wetel swaps it for a securely stored reference, and no query ever returns it again, this response included.

How do I see what tools a connector offers?

Ask it, with listMcpTools(connectorId). It returns each tool’s name, description and input schema. This is always a live call: Wetel connects to your server and asks it fresh every time, with no cache in between. If a tool you just added is missing, look at your own server first (not redeployed yet, or the tool not registered in its tool list).

Run it once right after you create a connector and before you wire anything up. A guessed tool name is the easiest mistake to avoid.

How does a workflow call a tool?

Through a tool node that a person adds to the workflow, naming the connector, the one tool to call and how to build its arguments. The tool is called at that step, with the arguments that step builds.

Here is the worked example from the reference: a scheduling workflow that has already pulled a requested date out of the conversation into requestedDate, then checks availability:

{
  "id": "check_availability",
  "type": "tool",
  "label": "Check Appointment Availability",
  "config": {
    "connectorId": 12,
    "toolName": "check_availability",
    "argsTemplate": "{\"date\": \"{{requestedDate}}\", \"durationMinutes\": 30}",
    "outputVar": "availability_result",
    "timeoutMs": 8000
  },
  "position": { "x": 250, "y": 200 }
}

• connectorId is the cupboard, and it only resolves to a connector in your own workspace.
• toolName is the shelf: exactly one tool on that server.
• argsTemplate builds the JSON arguments from earlier steps. Values are escaped for you, so a stray quote or newline in an extracted value does not break the JSON.
• outputVar is where the result lands, as plain text, for a later step to use. Wetel also writes a structured copy alongside it, which helps when your server returns JSON and you want only the readable part in the reply. Workflow best practices shows both patterns.

flowchart LR
  E["llm step pulls out the date"] --> T["tool step: one named tool<br/>on one connector"]
  T -- success --> R["response step replies<br/>with the result"]
  T -- failure --> F["response step: a polite<br/>fallback reply"]
  T -. records .-> N["nodeTrace: the request sent<br/>and the outcome"]

What keeps each call safe?

Six things sit around every tool call. Together they are the difference between a labelled key and a master key.

1. The key is stored by reference and never shown back

The server key you give at registration is never returned by any query, in any response. That cuts both ways: the API also gives you no way to read back or compare a key you set earlier, so keep your own record of which key is active, in your own secrets store.

The key cannot be changed in place either. To rotate it, delete the connector, create a new one, and point every tool step that used the old id at the new one, then republish. Do it as one coordinated change.

The reach of that key is decided by your own server. For a demo, use a scoped-down, disposable key, not a production one.

2. The address is checked before every call

Outbound calls are checked against private and internal addresses, so a connector cannot be used to reach inside a network it should not touch. For MCP connectors the server’s URL is re-checked on every call, not only when you register it, so a hostname that later starts pointing somewhere private is caught. Redirects are re-checked hop by hop rather than followed blindly.

3. Every call has a time limit

timeoutMs defaults to 10 seconds and cannot go above 30. A value below 1 second is raised to 1 second, and zero, a negative number or anything that is not a number means “use the default”, never “wait forever”. Keep in mind that the conversation waits while the tool runs, so a slow tool slows the whole turn.

4. A failure goes where you decide

By default every edge out of a tool step fires whether or not the call worked, and an unhandled failure fails the run. Add one edge labelled success and one labelled failure, and a timeout, a connection failure or a malformed argument sends the run down failure instead, with the error message in _lastNodeError for a later step. A failure edge needs a matching success edge, or the workflow will not publish.

5. The customer never sees the raw error

When a tool call fails, the person in the conversation gets a generic reply. The real error is in the run’s trace and in a live NodeFailedEvent, for your team to read.

6. There is a record of what was sent

Each run’s nodeTrace includes, for every tool step, renderedRequest: the arguments actually sent, on success and on failure. It goes through a best-effort pass that hides recognisable secrets (tokens, keys under names like apiKey or password). Best effort is not a guarantee, so never type a secret into an argsTemplate; the connector’s own key is the place for it.

How do I test a connector before customers use it?

Four steps, in order:

1. List the tools with listMcpTools and copy the exact tool name and argument names from the schema.
2. Run the workflow as a draft from a test session (sendMessage with testDraft: true). Treat the tool call as real: point it at test data.
3. Read the trace. workflowRuns(sessionId) lists the runs; in each nodeTrace, check the tool step’s renderedRequest and its output. See observability.
4. Break it on purpose. Stop the server or send a bad value, and check that the failure path replies the way you want.

If what you are calling is a plain REST endpoint rather than an MCP server, a custom action is the simpler route: no MCP server to run, the same outbound-address checks, and a testCustomAction call that makes one real request and tells you whether the credential, URL or body is wrong. The docs describe no equivalent one-shot test for a connector, which is why steps 1 to 4 matter. Do not build an MCP server just to wrap a REST endpoint.

What does a tool call cost?

Tool calls are counted in your workspace’s usage as credits, and for tool calls the credit figure is exact rather than an estimate. Wetel does not publish a per-call price, and it reports usage rather than billing it today; Pricing & Plans explains credits and where to read them.

Who is in charge?

People, at every step. A signed-in person in your workspace registers the connector and holds its key. A person adds the tool step and decides where its failure path goes. Nothing reaches customers until someone publishes the workflow, and the trace lets the team see afterwards what was called and with what. If a tool’s result should change something important, put an approval step before it so a workspace owner signs off first.

What is live today, and what is not built yet?

Live today:

• Registering MCP servers as connectors, live tool listing, and tool steps that call one named tool with templated arguments.
• Keys stored by reference and never returned; address checks before every call; time limits; success/failure routing; a generic reply to the customer and the real error in the trace.

Not built yet:

• No schema check on arguments. Nothing compares argsTemplate with the tool’s input schema when you save. A mismatch shows up only when the call fails.
• No drift detection. If your server renames a field or adds a required one, nothing scans your connectors ahead of time. Treat a schema change on your server as a breaking change, and re-run listMcpTools plus a test call.
• No array arguments from one variable. If a tool takes a list and the user named several values, branch into one call per value and merge the results in a later step.
• No in-place key change. Rotate by delete and re-create.
• No reference check on delete. Deleting a connector a published workflow still uses breaks that step at run time; check your workflows first.
• A full worked example against a real third-party MCP server is still being written; the docs page for it is marked coming soon.

For the difference between a tool, a workflow and a skill, see tools, workflows, skills and agents.

Related reference docs

• MCP Connectors: what a connector is, when to use a custom action instead, and the known limitations
• Tool node: every config field, the timeout rules and the gotchas
• Success/failure edges: routing a failed call to your own reply
• listMcpTools: listing a connector’s tools and their schemas
• createMcpConnector: registering a connector, and why the key is write-only
• testCustomAction: the one-call test for the custom-action alternative
• Workflow best practices: reading tool results and matching values to ids
• Observability and debugging: nodeTrace and renderedRequest

To register your first connector, start with the MCP connectors guide.