Cursor MCP Config: Remote URL Server + OAuth Callback
Set up a remote MCP server in Cursor's mcp.json, register both OAuth callback URLs correctly, and query live trending topics from Cursor and VS Code.

To set up a remote MCP server in Cursor, you add a url entry to mcp.json pointing at an HTTP endpoint, then — if the server is OAuth-protected — register both of Cursor's fixed redirect URLs with the provider: https://www.cursor.com/agents/mcp/oauth/callback for web and Cursor Agents, and http://localhost:8787/callback for the desktop app. Cursor's documentation states both must be registered for the same OAuth app, which is the step most setup attempts miss.
This guide covers the exact JSON shape for stdio versus URL servers, the OAuth callback checklist, how the same server is wired into VS Code, and a working end-to-end example: a TrendsAGI MCP server that lets a Cursor agent query live trending topics as callable tools instead of pasted search results.
Where the Cursor MCP config lives and what it looks like
Cursor keeps MCP server definitions in mcp.json. There are two entries you will use in practice: a command-based entry for local stdio servers and a URL-based entry for remote servers. A minimal file with both looks like this:
{
"mcpServers": {
"local-example": {
"command": "npx",
"args": ["-y", "some-local-mcp-server"]
},
"remote-example": {
"url": "https://api.trendsagi.com/mcp"
}
}
}
For a locally hosted server the PyPI documentation for glide-mcp 0.1.6 shows a url entry pointing at a local HTTP endpoint such as http://127.0.0.1:8000/mcp, so a URL entry does not automatically mean "remote vendor" — it means the client talks HTTP rather than spawning a process. Note that glide-mcp's own docs say only Cursor is supported as its MCP client, which is a limitation of that server, not of Cursor.
One practical warning from Cursor's own documentation: MCP docs appear in two locations, docs.cursor.com/context/model-context-protocol and cursor.com/docs/mcp, and the two may differ. When a step looks wrong, check the other page.
stdio command vs. remote URL: which to use
| Entry type | How it runs | Good for | Trade-off |
|---|---|---|---|
command + args |
Cursor spawns a local process and speaks stdio | Tools you run yourself, no network, filesystem-adjacent work | You own process lifecycle, installs and updates on every machine |
url |
Cursor connects over HTTP (Streamable HTTP for remote servers) | Hosted services, shared team tooling, OAuth-protected vendors | You must get authentication and callback registration right |
Use a command entry when the server is local and unauthenticated. Use a url entry when the server is a hosted service, when several teammates should share one config, or when the provider uses OAuth. The remote path is where callback URLs matter.
The OAuth callback checklist for Cursor (both surfaces)
Cursor's documentation lists two fixed redirect URLs for MCP authentication:
- Web and Cursor Agents:
https://www.cursor.com/agents/mcp/oauth/callback - Desktop app:
http://localhost:8787/callback
Register both in the MCP provider's OAuth app even if you only plan to use the desktop app today. Cursor's docs state both redirect URLs must be registered, and a team that adds Cursor Agents later will otherwise hit an auth failure that looks like a server bug.
- Confirm the provider is OAuth-protected. Cursor documents remote OAuth-protected MCP servers using an
api.example.com/mcpstyle URL, so protection is a server property, not a Cursor setting. - Add both redirect URLs to the provider's OAuth client configuration.
- Add the
urlentry tomcp.jsonand restart or reload Cursor. - Trigger the auth flow from Cursor and confirm the browser lands on the correct callback for the surface you are using.
- If auth fails, check surface mismatch first: a desktop flow pointing at the web callback (or vice versa) is the most common cause.
For a hosted server that handles sign-in itself, such as TrendsAGI's hosted MCP endpoint at https://api.trendsagi.com/mcp, the connection supports OAuth 2.1 sign-in or an API key passed as a Bearer token. In Claude Code the same server is added with claude mcp add --transport http trendsagi https://api.trendsagi.com/mcp; Cursor uses the JSON url entry above.
Does the same config work in VS Code?
Vultr's client setup documentation states that its MCP server works with any client supporting remote MCP over Streamable HTTP, with setup documented for Claude, Cursor, VS Code, Codex CLI, and OpenClaw. That confirms VS Code is a supported remote MCP client for at least one vendor. It does not confirm that VS Code uses an identical configuration file, file location, or schema to Cursor — that detail is not established by any source available here, so treat cross-client config portability as something to verify per client rather than assume.
The practical approach for a team standardizing on one config: keep the server URL and OAuth client details in a shared internal note, then write each client's config file separately. The values are identical; the wrapper is not necessarily.
Verify the connection before you trust the agent
After saving the config, confirm two things separately: that the server appears as connected, and that its tools are actually callable by the agent in a request. Do not stop at "connected" — a connected server with failing tool calls is a common outcome of auth mismatch or a stale token.
With the TrendsAGI hosted endpoint, a quick check outside the editor is to hit the agent tool listing:
curl -s https://api.trendsagi.com/api/agent/tools \
-H "X-API-Key: $TRENDSAGI_API_KEY"
Then run one tool call the same way, passing the arguments as the JSON body:
curl -s -X POST https://api.trendsagi.com/api/agent/tools/list_trends \
-H "X-API-Key: $TRENDSAGI_API_KEY" \
-H "Content-Type: application/json" \
-d '{"category": "Technology"}'
A successful response returns content with isError: false. If that works in the terminal but not in the editor, the problem is in Cursor's connection or OAuth flow, not the server.
End-to-end example: an agent that finds a rising trend and proposes a campaign change
TrendsAGI is a real-time trend intelligence platform that detects topics gaining attention on social platforms, measures velocity as posts per hour from stored snapshots, and explains topics with AI insights covering summary, key themes, sentiment, audience and marketing angles. Two honesty notes carry into any agent you build: velocity is a measured snapshot rate, not a forecast or a unique-user count, and recommendation confidence measures evidence completeness, not probability of success.
The same tools ship in several forms. In Python, the agent tools wrapper is read-only by default:
import os
from trendsagi import TrendsAGIClient, TrendsAGITools
client = TrendsAGIClient(api_key=os.environ["TRENDSAGI_API_KEY"])
tools = TrendsAGITools(client) # read-only
tools = TrendsAGITools(client, allow_writes=True) # adds write tools
Tool calls return a dict. Reads come back as {"result": <data>}; failures return {"error": ..., "detail": ...} instead of raising, so check for the error key before indexing:
out = tools.call("list_trends", {"category": "Technology"})
if "error" in out:
raise RuntimeError(out["detail"])
trend_id = out["result"]["trends"][0]["id"]
Now walk the workflow an agent should follow. First, find a rising topic using velocity ordering:
trends = tools.call("list_trends", {
"category": "Technology",
"sort_by": "velocity",
"limit": 5
})
trend_id = trends["result"]["trends"][0]["id"]
Second, check whether the rise is sustained rather than a spike, using analytics over a period:
analytics = tools.call("get_trend_analytics", {"trend_id": trend_id, "period": "7d"})
Third, read the AI insight so the summary you show a human is grounded in the platform's analysis, not your own paraphrase:
insight = tools.call("get_trend_ai_insights", {"trend_id": trend_id})
Fourth, pull recommendations and filter to the ones worth a human's attention:
recs = tools.call("list_recommendations", {"limit": 10, "priority": "high"})
Finally, stop. Do not let the agent change ad spend on its own. Ads connectors for Google Ads, Meta Ads (plus Conversions API), TikTok Ads, LinkedIn Ads, Microsoft Ads, Pinterest Ads, Snapchat Ads and Reddit Ads are supported, and ad changes are previewed before any explicit execution. Your agent should surface the proposed change, the evidence behind it, and wait. If a write tool is genuinely needed, it only exists when you constructed the wrapper with allow_writes=True, and the write tools are add_to_watchlist and update_recommendation. Recommendations can also be actioned through the REST API at POST /api/intelligence/recommendations/{id}/action after a human approves.
To have the agent monitor a topic between sessions, add it to the watchlist with an alert condition:
tools.call("add_to_watchlist", {
"keyword": "AI chips",
"alert_condition_type": "volume_threshold",
"volume_threshold_value": 500
})
Supported alert conditions are volume_threshold and percentage_growth.
Wiring the same toolkit into Cursor, Claude and LangChain
If you would rather run the server locally than use the hosted endpoint, install and launch it with the API key set:
pip install "trendsagi[mcp]"
trendsagi mcp # read-only
trendsagi mcp --allow-writes
For Claude Desktop, Cursor-style JSON clients, the config shape is:
{
"mcpServers": {
"trendsagi": {
"command": "trendsagi-mcp",
"env": { "TRENDSAGI_API_KEY": "<key>" }
}
}
}
If you are building your own agent rather than configuring a client, export the tools in the format your runtime expects: tools.openai(), tools.openai_responses(), tools.anthropic(), or tools.langchain(). The available read tools include list_trends, list_trend_categories, search_trend_insights, get_trend, get_trend_ai_insights, get_trend_analytics, list_recommendations, list_crisis_events, list_watchlist and get_api_usage.
Safety basics: read-only by default, writes opt-in, and usage checks
- Read-only by default.
TrendsAGITools(client)andtrendsagi mcpexpose reads only. Keep it that way unless the workflow needs more. - Writes are explicit.
allow_writes=Trueor--allow-writesenablesadd_to_watchlistandupdate_recommendation. Grant it per agent, not globally. - Check usage before scaling. Call
get_api_usagein your agent's setup step so you know where you stand before a loop starts hammering tools. Rate limit numbers are not published in the material available here; read them from your account usage response rather than assuming a figure. - Preview ad changes. Ads connector changes are previewed before explicit execution. Never wire an agent to skip the preview and the human approval step.
- Handle errors as data.
tools.callreturns{"error", "detail"}rather than raising. Log it and let the agent report the failure instead of retrying blindly.
Where a trend tool helps — and where it does not
A trend-intelligence tool is strong at questions with a measurable answer: what is rising in a category right now, how does a topic's velocity look over 24h versus 7d, what themes and sentiment surround it, which recommendations carry high priority. It is weaker at open-ended research where the answer lives in documentation or long-form reporting, and it does not replace a keyword research tool or a search engine. When the agent needs context the insight does not contain, fall back to search rather than stretching the trend data.
Frequently asked questions
Where does the Cursor MCP config file live and what is the exact JSON structure?
Servers go in mcp.json under a mcpServers object. A local server uses command and args; a remote or HTTP server uses a url entry. Both forms can coexist in the same file.
What is the difference between a local stdio server and a remote URL server in Cursor?
A stdio entry spawns a local process that Cursor talks to over standard input/output. A URL entry connects to an HTTP endpoint, including remote servers using Streamable HTTP. Use stdio for local unauthenticated tools and URL entries for hosted or OAuth-protected services.
Which OAuth redirect URLs must I register for Cursor Desktop vs. Cursor web/Agents?
Register http://localhost:8787/callback for the desktop app and https://www.cursor.com/agents/mcp/oauth/callback for web and Cursor Agents. Cursor's documentation says both must be registered for the provider's OAuth app.
How do I verify the server is connected and that its tools are callable?
Confirm the server shows as connected in Cursor, then make an actual tool call from the agent. For a hosted endpoint you can test the same tool from the terminal with a POST to its tool URL using your API key and confirm isError: false comes back.
Can the same MCP server be used in VS Code, and how does that config differ?
Vultr's client setup docs say its MCP server works with any client supporting remote MCP over Streamable HTTP, listing VS Code among them. Whether VS Code uses the same configuration file location and schema as Cursor is not confirmed by the available sources, so verify it per client.
What can the agent do with the returned data once a trending-topics tool is connected?
It can rank topics by velocity, pull 24h, 7d or 30d analytics, read AI insights on themes and sentiment, list recommendations, watch for crisis events, and propose a campaign change for a human to approve. Writes such as watchlist additions require opting in.
How we researched this
Prepared by TrendsAGI Research. Facts checked on 23 October 2026 against the sources listed below.
Capability descriptions and code use TrendsAGI's documented REST API, Python SDK and MCP server. External facts come from the sources below.
| Claim | Applies to | Source |
|---|---|---|
| Cursor's 2.0 release runs up to eight agents in parallel on a single prompt, using git worktrees or remote machines to prevent file conflicts. | 2.0 | cursor.com |
| Cursor 2.0 introduced Composer, described as a frontier agentic coding model 4x faster than similarly intelligent models. | 2.0 | cursor.com |
| Cursor uses a fixed OAuth redirect URL of https://www.cursor.com/agents/mcp/oauth/callback for web and Cursor Agents MCP authentication. | Web and Cursor Agents | cursor.com |
| Cursor uses a fixed OAuth redirect URL of http://localhost:8787/callback for MCP authentication in the desktop app. | Desktop app | cursor.com |
| When configuring an MCP provider's OAuth app for Cursor, both redirect URLs must be registered. | All plans | cursor.com |
| MCP servers can be configured in Cursor's mcp.json using a url entry pointing at a local HTTP endpoint such as http://127.0.0.1:8000/mcp. | glide-mcp 0.1.6 | pypi.org |
| Glide MCP's documentation states that currently only Cursor is supported as the MCP client. | glide-mcp 0.1.6 | pypi.org |
| Cursor MCP servers can be OAuth-protected, as shown by a remote example server configured with an api.example.com/mcp URL. | All plans | cursor.com |
| The Vultr MCP Server works with any client that supports remote MCP over Streamable HTTP, with client setup documented for Claude, Cursor, VS Code, Codex CLI, and OpenClaw. | All plans | docs.vultr.com |
| Cursor's MCP documentation appears in two doc locations, docs.cursor.com/context/model-context-protocol and cursor.com/docs/mcp, and may differ. | All plans | cursor.com |
We re-research and rewrite this page at least every four months; the updated date only changes when the facts are re-checked.
Sources
- Cursor Docs — Model Context Protocol — cursor.com
- Client Setup (Vultr Docs) — docs.vultr.com
- glide-mcp (PyPI) — pypi.org