Connect Cursor to your business data: a 5-minute setup

What five minutes buys

AXL publishes its remote MCP server at one HTTPS address. Add that address to Cursor, approve the AXL consent screen in your browser, and the tools appear. You do not create or copy a key. The exact clicks are on the Cursor setup page.

What arrives is not a handful of endpoints. It is most of the admin panel, described so a model can search it.

A thousand tool definitions would crowd the context and make the model less accurate. Instead, the server exposes a small discovery set and lets Cursor search for the operation it needs.

Around 110 common jobs include a working recipe. A schema may say that a field is a string; a recipe can warn that one update call replaces every tag already on the contact.

What changes when the data is in the editor

Two things, and neither of them is glamorous. It removes a context switch, and it removes the excuse.

Take the first row seriously. Building a page that lists a customer's purchases, you no longer write a fixture from the field names and hope. You ask for one real order with its payment rows and shape the component against what the platform sends.

The second effect is quieter and worth more. Useful questions go unasked because the answer costs twenty minutes of clicking. When it costs a sentence, people ask the follow-up too.

Six questions worth asking in the first week

Start with reads. A wrong answer costs nothing, and it is how you learn what the agent misunderstands about your business.

• Bought, never started

  Contacts with a paid order last month and no course progress. Then ask for it as a saved segment, so the answer outlives the conversation.

• One real record

  A live contact or order with the fields you plan to render. Better than a fixture, and it exposes the custom fields nobody documented.

• Where the funnel leaks

  Deals by stage against orders by product, or payments started and never completed. The joins the built-in reports do not offer.

• What that automation does

  Read a scenario node by node before anyone edits it, including the branch somebody added years ago that nobody remembers.

• Why this customer lost access

  Orders, refunds, licences and the history timeline for one person, answered in one pass instead of four screens.

• A whole offer, as drafts

  Product, price, landing page and confirmation email, built and left unpublished. The first write worth trying, because you review it all before it is live.

Five of those six were always answerable. They just cost enough that nobody bothered. That is the real change.

Start read-only, and mean it

The consent screen is the one screen that deserves your attention. What the client receives is an ordinary admin access token scoped to one account, and that has a consequence people miss: the agent has exactly the permissions of the admin who signed in. Not more, and not a separate machine identity with its own rules. If you administer several accounts, switch before you approve.

So read-only is not a checkbox on the connection. It is a staffing decision. If you want an agent that can look but not touch, create a second admin whose role carries read rights only and connect as that admin. Ten minutes in the team settings, and it is the highest-value thing on this page. Do it before anyone points an agent at production.

Twenty-one sensitive operations are unavailable regardless of who signs in. They include billing writes, API-token creation, permission changes, and creating administrators. A missing tool is a stronger boundary than a warning in a prompt.

Publishing and sending remain separate. The agent can build a page or stage a broadcast, but going live requires another request.

Where the five-minute claim breaks down

The connection is five minutes. The list below is not, and pretending otherwise is how people end up distrusting the whole thing by Thursday.

• •The account decision. Which admin, with which rights, in which account. Ten minutes if your roles are already sensible. An afternoon if nobody has looked at them, which is the common case.
• •The first answer that looks right and is not. Most reads need an explicit list of the fields you want, and a filter condition the platform does not implement is dropped in silence. You get a clean response with the wrong rows in it, never an error. Cross-check the first filtered answers against the platform's own count.
• •Concurrency. A machine caller gets three requests in flight at once; the fourth comes back 429 with a retry header. Sequential calls are fast and fine. A fan-out across fifty contacts is not, and the agent has to be told so.
• •Deploys. The transport holds no session, so a client connected before we ship reconnects once afterwards. It looks like an expired login and it is not.
• •Vocabulary. The agent knows the API. It does not know that "cohort" means something specific here, or that half your contacts are tagged by a convention nobody wrote down. The first week is mostly you learning which phrasing lands on the right operation. The platform's knowledge base, 200+ articles, is searchable through the same connection, which helps more than it sounds like it should.

Is it worth doing at all

We build one of these, so weigh the paragraph accordingly. It pays off when the data sits in one account rather than across four tools, because then the agent answers from one source instead of becoming another integration in a chain. It pays nothing if you connect it, ask two questions and never open the thread again.

The people who get something out of it put a real, boring question to it in the first week and then check the answer by hand. That habit turns a connection into a tool.

The steps are on the Cursor connector page. The same server works from every other supported client, and what was taken off the AI surface is listed in the guardrails reference.

FAQ