Claude und Codex steuern kompletten Vertriebsprozess via MCP

Most MCP demos connect an agent to one narrow tool. We wanted Claude and Codex to finish a whole customer workflow without wiring five apps together.

I'm Dmitry, co-founder of AXL. AXL combines websites, CRM, sales pipelines, booking, payments, courses, webinars, email and messaging automation. We built a remote MCP server so an agent can work across that system from the chat its user already has open.

https://app.axl.tech/mcp Enter fullscreen mode Exit fullscreen mode Claude Code connects with one command:

claude mcp add --transport http axl https://app.axl.tech/mcp Enter fullscreen mode Exit fullscreen mode The browser opens for sign-in. You choose the AXL account, approve the connection and return to the agent. There is no API key to paste into chat.

Launch a paid photography course. Build the landing page, signup form and checkout. Create the course and lessons. Put every buyer in the CRM and prepare the follow-up emails. Give me links to review everything before it goes live. Enter fullscreen mode Exit fullscreen mode That one request crosses several parts of a normal business stack. The page needs a form. The form needs a contact record. The checkout needs a product. A successful payment needs to give the buyer course access. The follow-up emails need to know what that person bought.

AXL keeps those events on the same customer record, so the agent doesn't have to match IDs across a page builder, CRM, checkout, course platform and email tool.

AXL's admin API currently has around 1,100 operations. Sending every operation schema to the model on every turn would waste context before the work even started.

The MCP server gives the agent a small fixed tool set. The agent searches the live operation catalog, reads the contract it needs, then runs that operation. One connection covers the platform without loading hundreds of unrelated schemas into the model context.

The server uses stateless Streamable HTTP and accepts JSON-RPC over POST. It does not depend on a long-lived server session.

The browser flow uses OAuth 2.1, PKCE and dynamic client registration. The token is tied to the AXL account approved during sign-in and the user's permissions in that account.

We also remove 21 sensitive operations from the AI surface. The agent cannot use MCP to mint tokens, change administrator permissions or perform billing writes. Those operations do not appear in search results or tool schemas.

Publishing, sending messages, starting calls and spending money remain separate actions. The agent can prepare the work and return review links without quietly putting it in front of customers.

The exact rules are in AXL agent guardrails.

The standard browser authorization currently uses one broad MCP scope. It is limited to the selected account, but it is not a read-only grant. An administrator who needs read-only access can create an AXL API key with reduced rights and use it as a Bearer token.

File uploads also need one step outside MCP. The agent requests a pre-signed URL, uploads the file with a raw PUT, then completes the AXL record. A client restricted to MCP tool calls cannot finish that upload by itself.

These details are less exciting than a demo, but they matter when an agent can touch a real customer system.

MCP access has no separate fee. New AXL accounts start on a permanent Free plan with no card and no trial deadline. Usage limits apply. Calls, SMS and AXL's built-in AI use a prepaid balance.

Start with a small end-to-end test: ask the agent to build a page, submit its form and show the new lead in the CRM. That reveals more than a list of available tool names.

If you're building a broad MCP server, how are you handling permissions: one account-scoped connection, module scopes or confirmation for individual actions?