Quick answer: An MCP web search server exposes a search tool over the Model Context Protocol, so AI clients like Claude Desktop and Cursor can query the live web and read results without any custom integration code. You add one JSON block to your client's config, restart, and the model can search on its own. The hosted link.sc server at https://mcp.link.sc/ gives you both search and fetch with nothing to install.
If you have ever watched Claude confidently answer a question with information from two years ago, you already know why this matters. Here is the full picture: what MCP is, why search is the tool worth adding first, and the exact configs.
What an MCP server is, in one paragraph
The Model Context Protocol is an open standard for connecting AI applications to external tools. Your AI app (Claude Desktop, Claude Code, Cursor, Windsurf) is the client. A tool provider runs a server that advertises what it can do. The client asks the server "what tools do you have?", shows them to the model, and the model calls them when it decides they would help. The win is that this happens over one shared protocol instead of a custom integration per app, per tool. I wrote a longer explainer in what MCP is and why it matters if you want the background.
That is the whole idea. Everything else is configuration.
Why web search is the highest-value MCP tool
You can hook an MCP server up to your database, your filesystem, your issue tracker. All useful. But web search is the one I tell people to add first, for a simple reason: it fixes the single biggest weakness of every LLM, which is that its knowledge stops at a training cutoff.
A model with a search tool can check prices as they are today, read documentation for the library version you actually installed, and verify a claim instead of guessing. Without it, the model does what models do: it produces a plausible answer whether or not a correct one is available.
Search also compounds with fetch. Search finds the right pages, fetch reads them in full. A model with both can run a real research loop: search, pick promising results, fetch each one, synthesize. That loop is the backbone of every "agentic" workflow people are excited about right now.
Setting up a web search MCP server
You need an API key from link.sc (the lsc_... string from your dashboard; the free tier includes 500 credits a month, enough to test seriously). Then it is one config block per client.
Claude Desktop
Open your claude_desktop_config.json (Settings, then Developer, then Edit Config) and add:
{
"mcpServers": {
"linksc": {
"url": "https://mcp.link.sc/",
"transport": "http",
"headers": {
"x-api-key": "lsc_your_api_key"
}
}
}
}
Restart Claude Desktop. You should see the search and fetch tools listed under the tools icon.
Cursor
Same block, different file. Open Cursor Settings, go to MCP, and add a new server, or edit ~/.cursor/mcp.json directly:
{
"mcpServers": {
"linksc": {
"url": "https://mcp.link.sc/",
"transport": "http",
"headers": {
"x-api-key": "lsc_your_api_key"
}
}
}
}
Reload the window and the tools appear in Cursor's agent mode.
Because the server is hosted, there is no npm package to keep updated and no local process to babysit. If you prefer a walkthrough with prompts to test it, the Claude setup guide goes step by step.
What a tool call actually looks like
This part is invisible in normal use, but seeing it once demystifies MCP. The protocol is JSON-RPC 2.0, and you can poke the server yourself with curl. Listing tools does not even need a key:
curl -X POST https://mcp.link.sc/ \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
When the model decides to search, the client sends something like:
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "search",
"arguments": { "q": "postgres 17 release notes" }
}
}
The server runs the search and returns results as markdown in the response. The model reads that markdown as part of its context and carries on. No SDK, no glue code, no HTML parsing anywhere in your stack.
In the chat itself, you just write things like "search for the latest LangChain release and summarize what changed." The model handles the rest.
Security: treat tools like permissions, because they are
Giving a model tools means giving it capabilities, and it is worth thirty seconds of thought before you do.
Approve tool calls consciously. Claude Desktop asks before running a tool, per tool or per chat. Resist the urge to blanket-allow everything on day one. Read-only tools like search and fetch are low risk; tools that write, delete, or send things deserve per-call approval.
Fetched content is untrusted input. A web page the model reads can contain text that tries to steer the model ("ignore previous instructions and..."). With read-only web tools the blast radius is small, but if you combine a web fetch tool with tools that take actions, an injected page could try to trigger those actions. Keep risky tool combinations separate.
Protect your API key. The config file holds your lsc_... key in plain text. Do not commit it to a dotfiles repo. If it leaks, rotate it in the dashboard; usage-based billing means a leaked key is someone else spending your credits.
Prefer hosted servers you trust over random local ones. Every MCP server you add runs code or handles your data. A server from the vendor whose API you already use is an easier trust decision than an unmaintained package with forty GitHub stars.
Where this goes next
Once search works in your client, the obvious next step is using both tools together: ask for a comparison of two products, and watch the model search, fetch the relevant pages, and answer from what it actually read. That is the moment MCP stops being an acronym and starts being the way your tools work.
The quickstart covers the REST versions of the same endpoints if you want to build the loop into your own application rather than a chat client.
Want your AI tools to search the live web today? Create a free link.sc account and add the MCP server in two minutes.