Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@URL Text Fetcher MCP Server fetch text from https://news.ycombinator.com and summarize the top story"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Tiny MCP server for LM Studio that adds two tools:
fetch_url_text(url): returns visible page text
fetch_page_links(url): returns all page links
cd /Users/lex/Learning/URL-Fetcher-LM-Studio-MCP-Server
python3.12 -m venv .venv
source .venv/bin/activate
python -m pip install -U pip setuptools wheel
python -m pip install -e .mcp.json)Use the absolute interpreter to avoid ENOENT errors.
{
"mcpServers": {
"url-text-fetcher": {
"command": "/Users/lex/Learning/URL-Fetcher-LM-Studio-MCP-Server/.venv/bin/python",
"args": ["-m", "url_text_fetcher.mcp_server"],
"cwd": "/Users/lex/Learning/URL-Fetcher-LM-Studio-MCP-Server"
}
}
}Alternative using the console script:
{
"mcpServers": {
"url-text-fetcher": {
"command": "/Users/lex/Learning/URL-Fetcher-LM-Studio-MCP-Server/.venv/bin/url-text-fetcher",
"args": [],
"cwd": "/Users/lex/Learning/URL-Fetcher-LM-Studio-MCP-Server"
}
}
}After saving, restart LM Studio if the tool does not appear.
Summarize a real page: “Use url-text-fetcher.fetch_url_text on https://httpbin.org/html. Give a two‑sentence summary.”
List links from a real site: “Call url-text-fetcher.fetch_page_links for https://www.python.org/ and return the first 10 HTTPS links.”
Answer using content:
“Fetch text from https://docs.python.org/3/whatsnew/3.12.html. What is one notable change in Python 3.12?”
"Fetch text from https://www.python.org/. What’s the latest Python release mentioned and when was it announced?"
ENOENT spawn python: Use the absolute interpreter shown above in mcp.json.
Network/SSL errors: try another URL; some sites block scripted fetches.
source /Users/lex/Learning/URL-Fetcher-LM-Studio-MCP-Server/.venv/bin/activate
python -m url_text_fetcher.mcp_serverReturn a list of all links on the page.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't mention potential behaviors like rate limits, error handling, or whether it follows redirects. This leaves significant gaps for a tool that interacts with external resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any unnecessary words. It's front-loaded and appropriately sized for its simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema, the description is somewhat complete but lacks details on behavioral aspects. Without annotations, it should provide more context about how the tool operates, such as handling of invalid URLs or network issues.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description doesn't add any details about the 'url' parameter beyond what's implied by the tool's purpose. Since there's only one parameter and its role is somewhat clear from context, this meets the baseline for minimal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Return') and resource ('list of all links on the page'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from the sibling tool 'fetch_url_text', which might also involve page content extraction, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling 'fetch_url_text' or any alternatives. It lacks context about prerequisites, such as whether the URL must be accessible or if authentication is needed, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download all visible text from a URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'visible text' which hints at HTML parsing limitations, but doesn't cover critical aspects like authentication needs, rate limits, error handling, or what 'visible' excludes (e.g., scripts, hidden elements). This leaves significant gaps for a web scraping tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (web scraping), no annotations, and an output schema (which handles return values), the description is minimally complete. It states what the tool does but lacks important context about behavioral constraints and usage differentiation, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but there's only one parameter ('url'). The description doesn't add any semantic details about the URL parameter (e.g., format requirements, supported protocols), though the simplicity of a single URL parameter means the baseline is adequate despite the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download') and resource ('all visible text from a URL'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling tool 'fetch_page_links', which likely extracts links rather than text content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of its sibling 'fetch_page_links' or any context about when text extraction is preferred over link extraction, leaving usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
fetch_page_linksfetch_url_textScored across 2 tools
The two tools have clearly distinct purposes: fetch_page_links extracts links from a page, while fetch_url_text downloads visible text from a URL. There is no overlap or ambiguity between these operations, making it easy for an agent to select the correct tool based on the task.
Both tools follow a consistent verb_noun pattern with 'fetch_' as the prefix, followed by a descriptive noun (page_links, url_text). This predictable naming convention enhances readability and usability for agents.
With only two tools, the server feels thin for its purpose of URL text fetching. While the tools cover basic operations, the scope is limited and lacks functionality like handling errors, filtering content, or supporting different content types, which could hinder agent workflows.
The tool set is severely incomplete for a URL text fetcher. It lacks essential operations such as fetching metadata, handling HTTP status codes, extracting specific elements (e.g., images, tables), or providing configuration options (e.g., timeout, headers), leaving significant gaps that will likely cause agent failures in real-world scenarios.
Read any web page as clean text for a prompt, or list every link on it.
Read a URL as clean markdown, screenshot a website, url to PDF. Web access for agents, no signup.
Web scraping for AI agents. Converts URLs to clean, LLM-ready Markdown with anti-bot bypass.
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.