SLIM MCP Server
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., "@SLIM MCP ServerSummarize this article: https://example.com/article"
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.
SLIM MCP Server
Make Claude read the web in AI-native format
MCP (Model Context Protocol) server that allows Claude to fetch web content in SLIM format - optimized for AI comprehension with ~90% token reduction.
Quick Start
1. Install
npm install -g @slim-protocol/mcp-server
# or use npx directly (no install needed)2. Configure Claude Desktop
Add to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"slim": {
"command": "npx",
"args": ["@slim-protocol/mcp-server"]
}
}
}3. Restart Claude Desktop
That's it! Claude can now read web pages.
Related MCP server: Web Reader
Usage
Just ask Claude to read any URL:
"Read this article and summarize it: https://example.com/article"
"What are the key points in this documentation: https://docs.example.com"
"Analyze this YouTube video: https://youtube.com/watch?v=..."
"What's the discussion about in this Reddit thread: https://reddit.com/r/..."Claude will automatically use the SLIM tools to fetch and understand the content.
Tools
slim_fetch
Fetch web content in SLIM format.
Input:
url(string, required): The URL to fetch
Example:
Claude uses slim_fetch with url="https://en.wikipedia.org/wiki/Artificial_intelligence"slim_fetch_with_options
Fetch with advanced options.
Input:
url(string, required): The URL to fetchincludeImages(boolean, optional): Include image metadata (default: true)includeVideos(boolean, optional): Include video metadata (default: true)
Supported Content
Platform | Content Type |
Websites | Articles, blogs, documentation |
YouTube | Video metadata + transcripts |
Posts, comments, threads | |
Bluesky | Posts, profiles |
Any URL | Generic web content |
What is SLIM?
SLIM (Slim Web Representation) is an AI-native content format with hierarchical levels:
L1: Identity (title, type, author, date)
L3: Structure (sections, headings, navigation)
L5: Key Points (insights, topics, summary)
L7: Full Content (complete text)
This structure allows Claude to understand content efficiently without processing raw HTML, CSS, and JavaScript.
Configuration
Environment Variables
Variable | Default | Description |
|
| SLIM proxy URL |
|
| Request timeout in ms |
|
| Enable debug logging |
Custom Proxy
{
"mcpServers": {
"slim": {
"command": "npx",
"args": ["@slim-protocol/mcp-server"],
"env": {
"SWR_PROXY_URL": "https://my-proxy.example.com",
"DEBUG": "true"
}
}
}
}Development
# Clone
git clone https://github.com/slim-protocol/mcp-server
cd mcp-server
# Install
npm install
# Run in dev mode
npm run dev
# Build
npm run build
# Test
npm testTroubleshooting
"Tool not available"
Make sure Claude Desktop is restarted after config change
Check config file location and JSON syntax
Try running manually:
npx @slim-protocol/mcp-server
"Request timed out"
Some pages are slow to load. Try:
Using a different URL
Increasing timeout via
SWR_TIMEOUT_MS
"Proxy error"
Check internet connection
Verify proxy URL is correct
Try the URL in browser first
License
MIT
Links
Available Tools
2 toolsslim_fetchA
Fetch web content in SLIM format - an AI-optimized representation that Claude understands natively.
Use this tool when you need to read and understand web pages, articles, documentation, or any online content.
SLIM provides:
L1: Page identity (title, type, author)
L3: Document structure (sections, headings)
L5: Key points and insights
L7: Full content (if needed)
The content is optimized for AI comprehension with ~90% token reduction compared to raw HTML.
Supported platforms:
Any website or article
YouTube videos (transcripts + metadata)
Reddit posts and threads
Bluesky posts
Documentation sites
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to fetch. Can include or omit the protocol (https:// will be added if missing). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It reveals SLIM's output levels (L1, L3, L5, L7), token reduction benefit, and supported platforms, which adds meaningful context beyond the schema. It does not cover error handling or default behavior, but the provided transparency is substantial.
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 front-loaded with purpose and usage, then uses compact bullet lists for SLIM levels and supported platforms. Each section earns its place, though it is longer than strictly necessary, which keeps it from a 5.
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?
Even without an output schema, the description explains what the response contains (SLIM levels) and which content types are supported. It lacks explicit indication of the default output level and does not compare to the sibling tool, but for a single-parameter tool this is adequately complete.
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 schema describes the single URL parameter fully, including protocol auto-completion, at 100% coverage. The description does not add parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.
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 opens with "Fetch web content in SLIM format" – a specific verb plus resource, clearly stating what the tool does. It does not explicitly differentiate this from the sibling slim_fetch_with_options, so it stops short of a 5.
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?
It provides clear guidance: "Use this tool when you need to read and understand web pages, articles, documentation, or any online content." However, it does not mention when not to use it or when to prefer slim_fetch_with_options, so it lacks exclusions and alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
slim_fetch_with_optionsA
Fetch web content in SLIM format with advanced options.
Same as slim_fetch but with additional control over what content is included.
Use this when you need:
To exclude images or videos for faster/smaller responses
Specific SLIM levels only
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to fetch | |
| includeImages | No | Include image descriptions and metadata (default: true) | |
| includeVideos | No | Include video metadata and transcripts (default: true) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the benefit of faster/smaller responses when excluding media, but also claims support for 'Specific SLIM levels only' without any corresponding parameter in the schema. This misleading hint, combined with a lack of detail about errors, return format, or limitations, leaves significant behavioral ambiguity.
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 reasonably compact, front-loading the core purpose in the first sentence and using a bulleted list for use cases. The 'Same as slim_fetch' sentence is useful for orientation, not redundant. It could be tightened, but each sentence serves a 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?
The tool has 3 parameters, all well-documented in the schema, but no annotations or output schema. The description provides sufficient context for simple use but introduces an unsupported 'SLIM levels' feature and omits details about response format, error handling, or rate limits. Given these gaps, the description is minimally viable but not thorough.
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 100% coverage with descriptions for all parameters, so baseline is 3. The description adds marginal value by explaining the performance benefit of excluding images/videos, but it does not clarify the 'SLIM levels' concept or provide extra meaning for the 'url' parameter. The schema already handles the heavy lifting.
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 tool 'Fetch web content in SLIM format with advanced options', using a specific verb and resource. It distinguishes from sibling 'slim_fetch' by noting 'Same as slim_fetch but with additional control over what content is included', making its unique role explicit.
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 explicit use cases via a bulleted list: 'To exclude images or videos for faster/smaller responses' and 'Specific SLIM levels only'. It references the sibling tool as the baseline, though it does not explicitly state 'use slim_fetch for basic needs', which would be clearer. Overall, context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v1.0.0- First observed
slim_fetch - First observed
slim_fetch_with_options
TDQS
Scored across 2 tools
The two tools are nearly identical: slim_fetch_with_options is explicitly described as the same as slim_fetch but with additional options, making the boundary between them unclear. An agent could use either in most cases, and might not know which one to select without reading the fine print.
Both tool names share the consistent 'slim_fetch' prefix, with the second adding '_with_options' as a descriptive suffix. This follows a predictable pattern, though the second name is slightly more verbose than a strict verb_noun convention.
With only 2 tools, the server feels thin for a general-purpose fetch tool. The count is borderline but acceptable for a narrow utility that does one thing well, though it could benefit from a separate tool for raw HTML or batch fetching.
For its stated purpose of fetching web content in SLIM format, the two tools cover the core functionality: basic fetch and fetch with advanced controls. Minor gaps include lack of explicit support for custom headers or authentication, but these are likely handled through the options parameter.
Maintenance
Related MCP Connectors
Enable language models to perform advanced AI-powered web scraping with enterprise-grade reliabili…
Web scraping for AI agents. Converts URLs to clean, LLM-ready Markdown with anti-bot bypass.
Clean Markdown and AI-readability scoring for any URL. Built for AI agents.
Cloud scraping & crawling API for AI agents. Turn any URL into clean, LLM-ready markdown.
Related MCP Servers
- AlicenseAqualityDmaintenanceA Model Context Protocol server that lets Claude query arbitrary webpages with token-efficient, structure-aware retrieval, reducing token costs by fetching only relevant sections.3MIT
- AlicenseAqualityDmaintenanceEnables Claude and other LLMs to read and parse web content, with smart fallback strategies to bypass access restrictions (e.g., paywalls, Cloudflare) and output Markdown.513 npm45MIT
- AlicenseNot gradedqualityDmaintenanceEnables token-efficient web page fetching by converting HTML to Markdown with tiered access (outline, section, search) to minimize LLM context usage.7 npmApache 2.0
- FlicenseAqualityCmaintenanceReduces token consumption by 73-87% by cleaning web and API data before it reaches the LLM context window. Supports fetching URLs, searching the web, optimizing JSON, and more.61-