Docs MCP Server

The Wetel docs MCP server lets a coding assistant that speaks the Model Context Protocol (Claude Code, Cursor and other MCP clients) look things up in this developer portal instead of guessing. Before it writes a call, the assistant can read the operation’s exact GraphQL document, every input field with its type and allowed values, and the published sample in your language. Before it hands you a workflow graph, it can check the graph with the same checks as the JSON to Flow visualizer.

It reads the same generated files as these pages: the OpenAPI file, the code samples, a small search index of the docs and the workflow node reference. The files sit in the docs site checkout, so the server needs no network connection.

This is a different thing from MCP connectors, which let a Wetel agent call your tools. This server only helps your coding assistant write code against Wetel.

What it never does

• It never calls the Wetel API. It cannot create, change or delete anything in a workspace, and it does not need an account.
• It never takes a credential. No tool has a key or token parameter, and a tool input that looks like an API key, a JWT or a private key is refused without being repeated back. The samples it returns read their credential from an environment variable such as WETEL_API_KEY; set that in your own shell.
• It opens no network connection unless you set WETEL_DOCS_BASE (below). A test checks this on every change.
• It writes nothing. Lookups go through maps loaded at start-up; no tool input becomes a file path or a URL. Inputs are length-capped and outputs are size-capped.

Run it

The server is not published to npm yet, and there is no hosted version. Today you run it from a checkout of the Wetel docs site repository (ask your Wetel contact for access if you do not have one). It needs Node.js 20.11 or later.

cd wetel-site/dev-portal/mcp
npm ci                  # installs the MCP SDK and zod only, into this folder
npm test                # optional: the server's own tests

Pull the repository now and then: the server answers from the files in your checkout, so it is as current as your last pull.

Claude Code

claude mcp add wetel-docs -- node /path/to/wetel-site/dev-portal/mcp/server.mjs

Add --scope user to make it available in every project, or --scope project to share it through the project’s .mcp.json.

Cursor and other MCP clients

Most clients read an mcp.json (Cursor: .cursor/mcp.json in the project, or ~/.cursor/mcp.json):

{
  "mcpServers": {
    "wetel-docs": {
      "command": "node",
      "args": ["/path/to/wetel-site/dev-portal/mcp/server.mjs"]
    }
  }
}

Reading the live site instead of your checkout

Set WETEL_DOCS_BASE to read the same files from the published site rather than from the checkout. It must be a plain https origin; the server follows no redirects and caps the size of each file.

{
  "mcpServers": {
    "wetel-docs": {
      "command": "node",
      "args": ["/path/to/wetel-site/dev-portal/mcp/server.mjs"],
      "env": { "WETEL_DOCS_BASE": "https://wetel.dev" }
    }
  }
}

Tools

Every tool is read-only. Results are JSON text.

Tool	What it returns
list_operations	Each catalogued operation: name, kind, capability, summary, credential, availability. Optional capability filter.
get_operation	One operation: signature, credential and headers, GraphQL document, example variables, every input field (type, required, enum values, description), example responses and their error codes.
generate_sample	The published sample of an operation, or of the hello-ticket quickstart program, in curl, typescript, php, csharp or python.
search_docs	Docs pages and headings that match a keyword query, with their URLs.
list_node_types	Every workflow node type with its required config and how its edges are chosen.
get_node_reference	One node type: required and documented config fields, edge labels and rules, gotchas, reserved variable names.
validate_workflow	The JSON to Flow visualizer’s findings for a graph: severity, code, node id, message and a fix.

list_operations

{ "capability": "api-keys" }

{
  "count": 3,
  "operations": [
    {
      "name": "revokeNamedApiKey",
      "kind": "mutation",
      "capability": "api-keys",
      "summary": "Revoke one named API key. Immediate and permanent; other keys are not affected.",
      "auth": "Dashboard JWT",
      "availability": "live"
    }
  ]
}

(Shortened: the real answer lists all three operations, the endpoint and the capability list.)

get_operation

{ "name": "approvals" }

The answer includes the document, the example variables and each input field, for example:

{
  "path": "statuses",
  "type": "[ApprovalStatus]",
  "required": false,
  "enumValues": ["APPROVED", "CANCELLED", "EXPIRED", "PENDING", "REJECTED"]
}

An unknown name is refused with the closest names: Unknown operation "sdkStrat". Did you mean: sdkStart?

generate_sample

{ "operation": "sdkStart", "language": "python" }

Returns the same file as the reference page and the downloads, unchanged. Samples are generated, never hand-written, so they cannot drift from the reference.

search_docs

{ "query": "matchAnyOf", "limit": 5 }

Returns pages such as the LLM node with the matching headings. The search is a simple keyword score over titles, headings, descriptions, a short excerpt and the code terms each page names; open the returned URL for the full text.

list_node_types and get_node_reference

{ "type": "await_reply" }

{
  "type": "await_reply",
  "requiredConfig": ["promptTemplate", "saveAs"],
  "edges": {
    "mode": "labelled",
    "requiredLabels": ["answered"],
    "optionalLabels": ["unanswered"]
  }
}

(Shortened: the answer also lists every documented field, the edge sections and the gotchas of the Await Reply page.)

validate_workflow

Pass the graph as an object or a JSON string: { "nodes": [...], "edges": [...] }, a workflow row (publishedNodes, publishedEdges) or a GraphQL response that contains one. With the ticket triage recipe graph minus its switch’s default edge:

{
  "nodes": 15,
  "edges": 18,
  "errors": 2,
  "valid": false,
  "findings": [
    {
      "severity": "error",
      "code": "SWITCH_MISSING_DEFAULT",
      "nodeId": "triage",
      "message": "Switch has no \"default\" edge: publish refuses this, and a turn that matches no case would fail.",
      "fix": "Add one outgoing edge labelled \"default\" for turns that match no case."
    }
  ]
}

The checks are a copy of the visualizer’s own code, kept byte-identical and pinned. They catch what publishing refuses (missing fields, missing or extra edge labels, unreachable nodes, reserved variable names) and a few likely mistakes. They are not the whole story: publishing runs the platform’s own checks, and workflowDiagnostics adds findings that need the API. The code values here are this server’s own labels, not the workflowDiagnostics codes.

Related

• AI coding assistant skills: a SKILL.md that teaches an assistant the API’s shape; use it together with this server.
• Interactive API reference and Downloads: the same content for people.