Claude and Cursor are sharp until you ask them about something newer than their training cutoff. Then they guess. The clean fix is to hand them a tool that reads the live web, and the Model Context Protocol (MCP) is the standard way to plug that tool in without writing a line of integration code.
Here is what MCP actually is, why it matters for web access, and how to wire up fetch and search in about a minute.
What MCP is
MCP is an open protocol for connecting LLM applications to external tools and data. The app (Claude Desktop, Cursor, Windsurf) is the client. A tool provider runs a server that exposes capabilities. The client discovers what the server offers and lets the model call it.
The point is standardization. Before MCP, every tool needed a custom integration for every app, and every app needed custom glue for every tool. That is an N-times-M problem, and it does not scale. MCP turns it into N-plus-M: write one server, and every MCP-compatible client can use it. Think of it as a common port that any tool and any client agree to speak.
A server can expose three kinds of things. Tools are actions the model invokes, like "search the web." Resources are read-only data the model can pull in. Prompts are reusable templates. For web access, tools are the part that matters.
Why it matters for web access
The web is the single most valuable thing to give a chat client, and also the most annoying to build yourself. Fetching a modern page well means rendering JavaScript, rotating proxies, getting past bot walls, and converting messy HTML into something the model can read. You do not want that living inside your editor config.
MCP lets a provider handle all of that behind a server, and your client just sees two clean tools: fetch a URL, search the web. No SDK, no glue code, no HTML parsing on your end.
Adding the link.sc MCP server
link.sc ships an MCP server that exposes web fetch and search. Under the hood it escalates cheapest-first, from a fast HTTP client with real browser TLS fingerprints, up to a stealth headless browser, up to a hardened browser over Tor for the sites that fight back. You just call the tool.
You need an API key (lsc_...) from your link.sc dashboard. Then add the server to your client's config.
Claude Desktop. Edit claude_desktop_config.json (Settings, then Developer, then Edit Config):
{
"mcpServers": {
"linksc": {
"command": "npx",
"args": ["-y", "@linksc/mcp-server"],
"env": {
"LINKSC_API_KEY": "lsc_..."
}
}
}
}
Restart Claude Desktop and the tools appear.
Cursor. Open Settings, then MCP, then Add new MCP server, or edit ~/.cursor/mcp.json directly. The block is the same:
{
"mcpServers": {
"linksc": {
"command": "npx",
"args": ["-y", "@linksc/mcp-server"],
"env": {
"LINKSC_API_KEY": "lsc_..."
}
}
}
}
Windsurf. Same idea, in ~/.codeium/windsurf/mcp_config.json under the same mcpServers key. Reload the window afterward.
One config shape, three apps, because that is exactly the interoperability MCP is meant to deliver.
The tools you get
Once the server is connected, the model has two tools available:
| Tool | What it does | Typical use |
|---|---|---|
fetch |
Takes a URL, returns clean markdown, JSON, raw HTML, or a screenshot | "Summarize this changelog: |
search |
Takes a query, returns web results with full-page markdown | "Find the current pricing for X" |
You do not call these by hand. You ask a normal question and the model decides. Say to Claude:
Read https://docs.python.org/3/whatsnew/ and tell me the three biggest changes.
Claude calls fetch, gets markdown back, and answers from the page instead of from memory. Ask Cursor "what's the latest version of the AWS SDK for Rust and how do I install it," and it calls search, reads the results, and gives you an answer grounded in pages that exist right now.
Because the same account backs an HTTP API, you can prototype a call outside the editor to see the exact response shape:
curl -X POST https://api.link.sc/v1/fetch \
-H "x-api-key: lsc_..." \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com", "format": "markdown"}'
MCP versus a direct API call
MCP is not always the right tool, and it is worth being honest about that.
Use MCP when a human is in the loop inside an MCP client. You are chatting in Claude Desktop, editing in Cursor, and you want the assistant to reach the web on its own. Setup is a config block, and the model handles tool selection.
Use the direct HTTP API when you are building software. A backend service, a scheduled scraper, a RAG pipeline, or a custom agent should call /v1/fetch and /v1/search directly. You get explicit control over retries, caching, concurrency, and error handling, and no dependency on an MCP client being present. Running a stdio MCP server inside a headless production job is just extra moving parts you do not need.
The rule of thumb: MCP for interactive assistants, direct API for automation. Same web-access engine underneath, so you can start in Cursor and graduate to the API without changing providers.
| MCP server | Direct API | |
|---|---|---|
| Best for | Chat clients, editors | Backend services, agents |
| Setup | Config block, auto-discovery | HTTP request with a key |
| Tool selection | Model decides | You decide in code |
| Control over retries/caching | Limited | Full |
Getting started
Grab a key, paste the config block into your client, restart, and ask it to read a page. That is the whole setup.
Add web tools to Claude and Cursor in a minute. Get a key at link.sc/register or see the docs — 500 free credits a month.