Quick answer: There are five practical ways to let an AI read a live web page. For a one-off, use the assistant's built-in browsing or just paste the page content. For repeatable access, connect a tool: GPT Actions in a custom GPT, an MCP server for Claude and other MCP clients, or a fetch tool in your own app's code. Which one you pick depends on whether you are an end user doing this once or a developer wiring it into a product.
"Can ChatGPT read this link" is one of the most common questions people ask about AI assistants, and the honest answer is "sometimes, and it depends how." Built-in browsing is hit or miss on any given page, and a raw link in a prompt is not the same as the model actually seeing the content. Here is the full range of options, from zero setup to full developer integration.
The five options at a glance
| Option | Who it is for | Setup | Best for |
|---|---|---|---|
| Built-in browsing | End users | None | Quick one-off lookups |
| Paste the content | End users | None | A page that browsing chokes on |
| GPT Actions | Custom GPT builders | Low | A reusable custom GPT |
| MCP server | Claude / MCP client users | Low | Reliable fetch in Claude |
| Fetch tool in your app | Developers | Medium | Products and agents |
Option 1: Built-in browsing
Both ChatGPT and Claude can browse the web on their own for many queries. You paste a URL or ask a question, and the assistant fetches pages to answer.
This is the least-effort option and it works well for mainstream pages. Where it struggles: JavaScript-heavy sites that render content client-side, pages behind bot protection, and anything the assistant decides not to fetch. You also do not control the fetch, so when it fails you often just get "I could not access that page" with no lever to pull.
Use it for casual, one-off reading. Do not build a workflow on it.
Option 2: Paste the content
The most reliable low-tech method is to bring the content to the model instead of sending the model to the content. Copy the page text, or the relevant section, and paste it into the chat.
The model reads exactly what you give it, with no fetching to fail. The downside is obvious: it is manual, it does not scale, and long pages eat your context window. For a single important document it is unbeatable for reliability. For anything recurring, move to a tool.
Option 3: GPT Actions in a custom GPT
If you are building a custom GPT and want it to read live pages on demand, you give it an Action: an API the GPT can call, described by an OpenAPI schema. When the model decides it needs a page, it calls your Action, gets the content back, and reasons over it.
This turns "read a web page" into a repeatable capability your GPT has, instead of something you do by hand each time. We cover the full build in add web browsing to a custom GPT, including the schema and auth setup. The rest of this post covers the options that GPT Actions do not: Claude, other MCP clients, and your own code.
Option 4: MCP for Claude and other clients
The Model Context Protocol (MCP) is an open standard for connecting AI clients to tools and data. Claude Desktop, Cursor, and a growing list of clients speak it. Instead of a custom Action per assistant, you point the client at an MCP server and its tools become available to the model.
link.sc runs an MCP server at mcp.link.sc that exposes search and fetch tools. Adding it to a client is a few lines of JSON:
{
"mcpServers": {
"linksc": {
"url": "https://mcp.link.sc",
"headers": {
"Authorization": "Bearer lsc_..."
}
}
}
}
Once connected, you can ask Claude to read a page and it calls the fetch tool, which returns clean content regardless of how the page is built. The full walkthrough, including client-specific config, is in connect Claude to the web with the link.sc MCP server. MCP is the cleanest option when your assistant of choice supports it, because one server works across every MCP client instead of per-assistant plumbing.
Option 5: Give your own app a fetch tool
If you are building your own product on an LLM, you own the tool-calling loop. You define a fetch_url tool, and when the model calls it, your code fetches the page and returns the content as the tool result. The model then answers from real, current data.
The one hard part is the fetch itself: rendering JavaScript, rotating proxies, and turning messy HTML into clean text the model can actually use. That is what link.sc does in a single call, so your tool implementation stays short:
import requests
def fetch_url(url: str) -> str:
"""Tool the model can call to read a live web page."""
resp = requests.post(
"https://link.sc/v1/fetch",
headers={"Authorization": "Bearer lsc_..."},
json={"url": url, "format": "markdown"},
timeout=30,
)
return resp.json()["content"]
Wire that into your framework's tool interface (function calling, LangChain tools, an agent's toolset) and the model gains reliable web reading. For the broader pattern of wiring live data into an agent, see give your AI agent internet access.
You can test the underlying call from a terminal before you write a line of app code:
curl https://link.sc/v1/fetch \
-H "Authorization: Bearer lsc_..." \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com/article", "format": "markdown"}'
Which one should you pick?
- Reading one page right now: built-in browsing, or paste it if browsing fails.
- Building a custom GPT: GPT Actions.
- Using Claude, Cursor, or another MCP client: MCP.
- Building your own product or agent: a fetch tool in your code.
The pattern underneath all five is the same. An LLM only knows what is in its context. Reading a live page means getting that page's content into context, whether you paste it, the assistant browses it, or a tool fetches it. The more you want it to be reliable and repeatable, the further down this list you go, and the more it pays to hand the fetching to something built for it.
link.sc covers three of these five options (MCP, your own fetch tool, and even a custom GPT Action) with one API and one key, so you are not gluing together a different fetcher for each assistant. Check pricing; the free tier is enough to wire it all up and test.
Give any assistant reliable, clean access to live web pages. Try link.sc free.