Endpoint and transport
A published server has a single endpoint, shown on its Overview and Connect tabs:Endpoint
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 (prefixmx_mcp_), sent as an X-API-Key header:
Request header
Authorization instead:
Bearer alternative
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 variableMODULEX_MCP_KEY for the key so you keep the secret out of the config file where the client supports it.
- Claude Code
- Cursor
- Codex
- Generic HTTP
Add the server to your MCP client configuration:Set the key in your environment:See the Claude Code MCP docs for where the config lives.
Claude Code
Set the key
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.
Troubleshoot a connection
The client shows no tools or fails to connect
The client shows no tools or fails to connect
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.
A tool call returns an error instead of running
A tool call returns an error instead of running
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.
A workflow tool is missing
A workflow tool is missing
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.