Direct answer

Add an MCP Server to Cursor

To add an MCP server to Cursor, open or create the file .cursor/mcp.json in your project, or the global MCP config in your home folder, and add one entry: a server named zambo with the URL https://zambo.dev/mcp. Restart Cursor and the tools appear in the agent tool list. Nothing is installed locally and no API key is needed. This page covers project versus global config, the first test call, and what the connection adds.

Updated October 20, 2026.

What an MCP server is, in plain words

MCP, the Model Context Protocol, is a standard way for an AI app to plug in outside tools. Inside Cursor, the effect is easy to picture. Without a server, the agent can work on your code and reason about what you show it, and that is where its world ends. With an MCP server connected, the same agent can also reach outside the editor during a session: check live information, run audits, work with data and documents, save facts for the next session, and leave a checkable record of those outside calls. The server is a service at one web address. Cursor reads its tool list from that address and offers the tools to the agent.

For a hosted server like Zambo, the verifiable work layer for AI, there is no local side to manage: no package to install, no process to start before you open the editor, no key to paste into a settings vault. The entire connection is one entry in one JSON file. If you have never added an MCP server before, Cursor is a friendly place to learn, because the config is visible, editable, and easy to remove. This page goes from zero to a working, tested connection, using the Zambo endpoint at https://zambo.dev/mcp as the worked example throughout.

Before you start: what you need

You need Cursor open on a project, the server address copied exactly, and a decision about scope, which the next section explains: project level or global. The address is https://zambo.dev/mcp. The file you will touch is .cursor/mcp.json in your project, or the global MCP config in your home folder. If the project file does not exist yet, you will create it, which is normal: many projects have no MCP config until the first server is added. A plain text editor inside Cursor is all the tooling this takes.

Also prepare one small test job: a current price to look up, a page of your own to audit, a live fact about your own project you can check in seconds. Testing is not an optional extra for a first connection. A JSON file can save perfectly and still hold a wrong URL, and the editor will not always tell you. The honest test is the agent calling a tool, a real result coming back, and its receipt verifying. That loop takes under a minute once the entry is in place.

Step by step: add the Zambo MCP server to Cursor

{
  "mcpServers": {
    "zambo": {
      "url": "https://zambo.dev/mcp"
    }
  }
}

The snippet is the whole install. Note what is absent: no command, no arguments, no environment block. Those belong to locally run servers, which Cursor starts as processes on your machine. Zambo is hosted, so the entry is a name and a URL, and the service at the other end is maintained by its provider. When Zambo adds a tool, a restarted Cursor session simply sees it, with no update step on your side.

Project config or global config: which one should you choose?

The project file, .cursor/mcp.json, scopes the server to that repository. Choose it when the server belongs to the project: a client build where the agent needs audits and lead tools, a repo whose whole team should get the same setup by cloning, or any work you may hand over, because the config travels with the code. Teammates opening the project get the same tool surface you had, which removes a whole class of it worked in my editor problems before they start.

The global MCP config in your home folder scopes the server to you, across every project you open. Choose it while you are learning, or when the server is part of your personal workflow everywhere: memory, checks, and receipts you want in a scratch project as much as in the main repo. A common path is to start global for a week, then copy the entry into the two or three projects where it earns its place and drop it from the rest. Neither choice is permanent: moving the entry is a cut and a paste, and the server itself never notices the difference.

Your first tool call, and how to check it

After the restart, start an agent session and ask for your prepared test job in plain words, naming Zambo as the source. The agent should call the tool, and the result should carry current data you can verify plus a receipt link. Open the receipt, then run the free check at zambo.dev/verify, no signup needed: a match confirms the saved result was not changed after the fact, and proves the path from Cursor to the server at zambo.dev/mcp works end to end.

Want to see that loop before editing any JSON? The live demo runs one real Zambo call and hands you its receipt in about 10 seconds, no setup at all. And once real sessions start producing records, a day of them can be reviewed at zambo.dev/today, receipt by receipt, the way you would review a pull request.

What you can do once Cursor is connected

Tools. The connected client can call Zambo tools directly in the session: web and data checks, current prices instead of training data guesses, site audits, document and file work, lead finding with the leadsignal tool, and the everyday jobs that used to mean opening five tabs and copying results back into the conversation by hand. Ask for the job in plain words and let the client pick the tool, then read the result the way you would read any work product, critically and in full.

Memory. Zambo memory holds only facts you explicitly save, through memory_remember, and brings them back through memory_recall. Save a preference, a project rule, a price, or the current state of a long job once, and any AI connected to the same Zambo account can recall it later. The store does not import your conversations and it does not guess: if a fact is in there, someone put it there on purpose, and you can review and correct it the same way.

Handover. When a job is finished, package it as a handover: one link carrying the goal, the steps in order, the outputs, and any open items. The person receiving it opens the link with no account and clicks Accept or Flag. You cannot accept your own handover, which is exactly what makes the acceptance recorded on it worth showing later.

Receipts. Every tool call returns a verifiable receipt for its saved result. Anyone can check a receipt free at zambo.dev/verify with no signup, and the check confirms the saved result was not changed after the fact. It does not prove the result was right, and this page will not pretend otherwise. It proves what ran and what came back, unaltered, which is the half of accountability that a confident summary cannot supply on its own.

Default surface or full surface in the editor

The plain URL loads 35 tools on the default surface, the set most Cursor sessions actually use: web and data checks, audits, file and document work, lead finding, memory, continuity, and handover. In an editor the agent is already juggling file tools, terminal tools, and your codebase context, so a focused external set is worth real money in pick quality. Sessions choose faster, choose right more often, and stay easier for you to follow while they work.

All 153 tools load by changing the URL in the entry to https://zambo.dev/mcp?full=true. Because the setting lives in a file, you can make it per project: full in the one repository whose job needs a specialist tool, default everywhere else. That per project control is the cleanest way to use the full catalogue. Leaving full on globally is the common mistake, and its symptom is familiar: the agent pauses longer, picks odder tools, and you blame the model for a toolbox decision you made in a JSON file.

Using the connection well on real projects

The uses that stick are the ones tied to the rhythm of coding. Reach outside without breaking flow: when a session depends on a live price, a current page state, or a published fact, the agent calls the tool in place instead of you leaving the editor to hunt a tab and paste results back. Save the project facts the session earns: the architecture decision, the naming rule, the deploy gotcha, saved with memory_remember in one sentence each, recalled with memory_recall next session, and equally recallable from Claude, ChatGPT, or Grok connected to the same account, because the store lives on your account, not in the editor.

And close work with proof. A Cursor session that says the refactor is done is grading its own homework. The receipts for its Zambo calls say what actually ran, and a handover link packages the job, goal, steps, outputs, receipts, open items, for a client or teammate to accept or flag. You cannot accept your own handover, which is what makes their acceptance on the record meaningful. None of this replaces reading the diff and running the tests. It replaces trusting a summary, which is a different and much weaker thing.

Troubleshooting: when the server does not show up

• The tools do not appear in the agent tool list. Restart Cursor after saving, then check the file location: .cursor/mcp.json in the project you actually have open, or the global MCP config in your home folder.
• The config file seems to be ignored. Validate the JSON: one trailing comma or a missing brace silently breaks the whole file. Keep the zambo entry inside mcpServers, spelled exactly as in the snippet.
• The URL looks right but calls fail. Compare the paste character by character against https://zambo.dev/mcp. Extra paths, a trailing word, or the full surface parameter typed wrong are the usual causes.
• Tool picks look noisy. Check whether the entry uses https://zambo.dev/mcp?full=true. For everyday projects, edit it back to the plain URL for the 35 tool default surface.
• A call hits a usage limit, or you want the server gone. Receipt checking stays free at https://zambo.dev/verify/, a Day Pass covers a heavy day, and removing the server is deleting its entry and restarting: nothing was installed, so nothing else remains.

What it costs

Connecting the server costs nothing to set up, and checking a receipt is always free. When the connection becomes part of a real working day, a Day Pass at $0.99 covers 24 hours of full access: enough to connect in the morning, run real jobs through the day, save the facts that matter, and hand the finished work over with its record attached. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402. Read that pricing as the price of solving the connection problem properly, with tools, memory, and proof in one place, rather than as a charge for the paste itself, which takes a minute and costs nothing.

Honest limits

Frequently asked questions

Related

• Add memory to Cursor that survives the editor session
• Best MCP server for Cursor, chosen by job
• Add an MCP server to Claude Code, step by step
• Add an MCP server to ChatGPT, step by step
• Cursor proof of work: check what the agent session did
• MCP server with receipts for every tool call