How do I use a domain intelligence MCP in Cursor?

Best move: add Bassethound as a remote MCP server in Cursor’s mcp.json, then let the agent call sniff_domain during any task.

Why it works: Cursor has MCP built in. A remote server needs one URL and no local process, so the tool lands in the agent’s toolbox and it decides when to sniff a domain.

Key takeaways

• Cursor reads MCP servers from mcp.json, either the global ~/.cursor/mcp.json or a project-scoped .cursor/mcp.json in the repo root.
• Bassethound is a remote HTTP MCP server, so you add a url entry with no local process and no npm install.
• The keyless free tier needs no API key. You paste the endpoint, Cursor connects, and calls are rate-limited.
• Once connected, sniff_domain appears as a tool the Cursor agent calls on its own when a task needs domain context.
• One call returns all five layers correlated, so the agent enriches a domain without chaining five separate lookups.

Where does Cursor look for MCP servers?

Cursor reads MCP configuration from two places. A global file at ~/.cursor/mcp.json makes a server available in every workspace. A project file at .cursor/mcp.json in the repo root scopes the server to that project and ships with the code, so your whole team gets the same tools on clone. Both use the same schema. If both files name the same server, the project entry is the one that applies in that workspace. You can also add and toggle servers from Settings > MCP without touching the files. That panel writes the same config and shows live status for each server. For Bassethound, either location works. Put it in the global file if you enrich domains across many repos. Put it in the project file if one repo (a sales-tooling or research project, say) is where domain lookups belong. After you save, Cursor picks up the change. Some builds need you to reload the MCP list or restart before a new server connects. Cursor is the vendor here, so its own docs are the source of truth for the exact paths on your platform.

What do I put in mcp.json for a remote server?

Bassethound is hosted, so you point Cursor at the endpoint instead of spawning a local process. The entry is a name and a url:

{
  "mcpServers": {
    "bassethound": {
      "url": "https://mcp.bassethound.ai/mcp"
    }
  }
}

That is the whole free-tier setup. No command, no args, no env, no key. A stdio server would need a command and an install. A remote HTTP server needs only the URL, because the crawl runs on our side. Cursor negotiates transport with the endpoint and, for the paid tier, runs the OAuth handshake in-app when the server asks for it. Keep the server name short and stable. The agent references it, and you will read it in tool-call logs. If you manage several MCP servers, add Bassethound alongside them under the same mcpServers object rather than a second file. Save, then confirm the server connects in Settings > MCP.

How does the agent decide to call sniff_domain?

Once Cursor connects, sniff_domain is a tool like any other in the agent’s toolbox, described by its schema: a domain argument and a profile argument (fast, standard, or deep). You do not wire it to a prompt. The agent reads the tool description and calls it when a task needs what it returns. Ask Cursor to “check the stack and AI-readiness of acme.com” and it selects sniff_domain, passes the domain, and picks a profile. You can steer it. Say “use the deep profile” to get the security grade and Wayback first-seen history, or “fast” for a keyless, deterministic pass in a couple of seconds. The response comes back as one correlated dossier: tech stack, infrastructure, firmographics, AI-readiness, and security, plus a top-level summary with an icp_signal. The agent then reasons over that structure in the same turn. Because it is one call, the agent skips chaining a tech-stack MCP, a DNS MCP, and a firmographics MCP and stitching their outputs together. The correlation is done before the agent reads it.

What about the paid tier and OAuth?

The free tier is keyless and rate-limited. It covers the fast and standard profiles for light, ad hoc use. When you need deep profiles at volume, paid plans raise depth and limits on the same connection. Cursor supports OAuth for MCP servers, so the flow runs in-app: the server advertises that it needs authorization, Cursor opens the consent page, you approve, and Cursor stores the token for that server. You do not paste a key into mcp.json, and there is no bring-your-own-key step, because Bassethound owns the crawl infrastructure. That is the structural difference from tools that make you supply provider keys: there is no upstream API you are paying for through us. Your config stays the same URL entry. The only change is that authorized calls unlock higher depth and higher limits. Every request is self-contained and read-only either way, so the token gates depth and volume, not state.

What can Cursor not see, and how do you check it worked?

Honesty first. Bassethound reads what a site exposes: loaded scripts, response headers, DNS and certificate records, and rendered markup when the profile calls for a render. A component that runs fully server-side, or sits behind a proxy that strips its signatures, can stay invisible. The dossier flags those gaps instead of guessing, so a low AI-readiness score can mean “not detectable from outside,” not “not present.” Read the evidence and how_detected fields before you treat a result as final. To confirm the setup itself works, open Settings > MCP and check that Bassethound shows connected with sniff_domain listed. Then run a known domain and read the output. A well-known site should return a populated tech stack and infrastructure block. If the server shows red, the usual causes are a wrong URL, a Cursor build without remote MCP support, or a network rule blocking mcp.bassethound.ai. If the tool connects but a specific domain comes back thin, that is usually the target, not the setup. Try the deep profile before you conclude a signal is missing.

Bassethound perspective

Run this inside Cursor for one reason: the agent gets correlation for free. The competing shape is fan-out. Install a tech-stack MCP, a DNS MCP, a firmographics MCP, and let the model stitch five responses into one picture. That stitching is where agents burn tokens and guess wrong, because the layers do not line up on their own. A vector store in the tech stack means little until you correlate it with the model-provider signal and the llms.txt classification, and that correlation is the product. We also skip the key. Tools that make you bring your own provider key push their cost onto you and add a setup step on every machine. We own the crawl, so the free tier is a URL and nothing else. Add it once, and every task in Cursor that touches a domain can sniff it in a single call. A fan-out vendor can match any one of our five layers. None of them hands your agent the correlation across all five, and that is the whole bet.

Sources

• Cursor documentation, Model Context Protocol: https://docs.cursor.com/context/model-context-protocol
• Model Context Protocol: https://modelcontextprotocol.io
• Model Context Protocol, example clients: https://modelcontextprotocol.io/clients