Skip to main content
Once you have published a server and a key, connecting a client takes two values: the server’s endpoint URL and an active key. This page has the endpoint and transport details, the authentication header, ready-to-paste configs for common clients, and the reference for every tool a connected client can call.

Endpoint and transport

A published server has a single endpoint, shown on its Overview and Connect tabs:
Endpoint
The server speaks the Model Context Protocol over Streamable HTTP: JSON-RPC requests sent as HTTP POST with Content-Type: application/json and Accept: application/json. It is stateless — each request stands alone — so there is no session to open or tear down. MCP clients handle the protocol for you; you only supply the URL and key, and the client discovers the available tools and calls them.

Authentication

A client authenticates with the server’s key (prefix mx_mcp_), sent as an X-API-Key header:
Request header
Clients that send credentials as a bearer token can use Authorization instead:
Bearer alternative
The key is all a client sends. The server already knows its organization from the endpoint URL, so do not add an X-Organization-ID header — an MCP client authenticates with the server key alone. This is different from the ModuleX REST API, which uses an mx_live_ key plus X-Organization-ID; see API authentication for that surface.

Client configuration

Copy the config for your client from the server’s Connect tab, or use the templates below. Each uses the environment variable MODULEX_MCP_KEY for the key so you keep the secret out of the config file where the client supports it.
Add the server to your MCP client configuration:
Claude Code
Set the key in your environment:
Set the key
See the Claude Code MCP docs for where the config lives.
Replace the example URL with your server’s endpoint (from its Overview tab) and the placeholder with a real key. The modulex label is the name the client shows for the server — change it freely.

The published tools

A connected client lists the server’s tools automatically. What it sees depends on which tools you enabled when publishing: a fixed set of built-in tools, plus one tool per published workflow.

Built-in tools

The built-in tools cover your organization’s Files and Knowledge. Enable the ones you want per server.
Enabled built-in tools are available to every active key on the server. File writes count against your organization’s existing Files quotas, and Search knowledge consumes credits like any managed retrieval.

Workflow tools

Each workflow you publish becomes one tool:
  • The tool name and description come from the workflow’s published metadata.
  • The input schema is the workflow’s published inputs, so the client knows what arguments to pass.
  • Calling the tool runs the deployed workflow with those inputs and returns its result. This consumes credits exactly as running the workflow in the app does.
Publish and deploy workflows from the builder; a client sees the current set the next time it lists tools.

Troubleshoot a connection

Confirm the endpoint URL is the server’s own (from its Overview tab), that the key is active and not expired, and that the client is configured for Streamable HTTP. Rotate the key from the Keys tab if you are unsure it is current.
Calls that run a workflow or search Knowledge are billed. If your organization is out of credits or its plan does not permit the usage, the call returns an error result. See Usage gating & limits.
Only deployed workflows that the server publishes appear. Deploy the workflow and confirm it is included in the server’s published tools, then re-list tools in the client.

Next steps

Publish an MCP server

Create servers, choose tools, and manage keys and limits.

ModuleX MCP overview

What ModuleX MCP is and how it differs from custom MCP servers.

Deploy a workflow

Deploy a workflow so it can be published as an MCP tool.

Credits & metering

How workflow runs and Knowledge search are metered.