Provides tools to run Lighthouse performance audits on URLs, returning audit results and technology detection.
Provides tools to convert web pages to Markdown format for further processing.
Provides tools to extract playable video sources from YouTube URLs, and other video sources.
A Model Context Protocol (MCP) server that exposes Microlink API capabilities to AI assistants. Runs over stdio transport, making it compatible with Claude Desktop, VS Code, Cursor, and any other MCP-capable client.
It turns natural-language requests into Microlink calls: take screenshots, generate PDFs, extract metadata or readable text, detect video/audio sources, run Lighthouse audits, and scrape custom fields with CSS selectors, all without leaving the assistant.
See the MCP integration page for a guided walkthrough, or the @microlink/mcp npm package.
Related MCP server: OpenUnfurl
No local installation is required. Run directly with npx:
npx -y @microlink/mcpnpm install -g @microlink/mcp
microlink-mcpDuring installation, the package prints a console reminder about the free Microlink plan (50 requests/day) and where to get an API key for higher/unlimited usage at microlink.io/#pricing.
Edit ~/Library/Application\ Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"microlink": {
"command": "npx",
"args": ["-y", "@microlink/mcp"],
"env": {
"MICROLINK_API_KEY": "YOUR_MICROLINK_API_KEY"
}
}
}
}Published package:
{
"mcpServers": {
"microlink": {
"command": "npx",
"args": ["-y", "@microlink/mcp"],
"env": {
"MICROLINK_API_KEY": "YOUR_MICROLINK_API_KEY"
}
}
}
}Local repository:
{
"mcpServers": {
"microlink": {
"command": "node",
"args": ["/absolute/path/to/mcp/src/index.js"],
"env": {
"MICROLINK_API_KEY": "YOUR_MICROLINK_API_KEY"
}
}
}
}Add to your Cursor MCP settings (.cursor/mcp.json):
{
"mcpServers": {
"microlink": {
"command": "npx",
"args": ["-y", "@microlink/mcp"],
"env": {
"MICROLINK_API_KEY": "YOUR_MICROLINK_API_KEY"
}
}
}
}Once the server is configured, talk to your assistant in plain language. It picks the right tool and parameters for you:
"Take a full-page screenshot of https://example.com in dark mode." → microlink_screenshot
"Generate a Letter-size PDF of https://example.com." → microlink_pdf
"Get the title, description, and image for https://example.com." → microlink_meta
"Convert https://news.ycombinator.com to Markdown." → microlink_markdown
"Find the playable video in this YouTube link." → microlink_video
"Run a Lighthouse performance audit on https://example.com." → microlink_insights
"Scrape every article title from this page using the .title selector." → microlink_extract with data
Tools can also be invoked directly. Every tool takes a url and returns structuredContent (see Response shape):
{
"name": "microlink_screenshot",
"arguments": {
"url": "https://example.com",
"screenshot": { "fullPage": true, "type": "png" },
"colorScheme": "dark"
}
}microlink_extract: metadata extraction + custom scraping rules (data) + multi-capability composition in one call.
microlink_screenshot: screenshot generation with element/full-page modes and browser controls.
microlink_pdf: PDF generation with page/layout controls.
microlink_video: playable video source extraction.
microlink_audio: playable audio source extraction.
microlink_insights: Lighthouse + technology detection.
microlink_meta: normalized metadata extraction with include/exclude config.
microlink_palette: image palette and contrast color extraction.
microlink_markdown: URL to Markdown conversion.
microlink_text: URL to plain text conversion.
Cross-cutting request capabilities: device/viewport emulation, click/scroll actions, JS/CSS injection, modules, wait conditions, cache controls (ttl, staleTtl, force), retries/timeouts, media mode, headers/proxy, and endpoint/auth routing.
All tools (microlink_extract, microlink_screenshot, microlink_pdf, microlink_video, microlink_audio, microlink_insights, microlink_meta, microlink_palette, microlink_markdown, microlink_text) return structuredContent with:
endpoint, requestUrl, finalUrl, statusCode, responseHeaders, microlink
microlink preserves Microlink API JSend payload (status, data, and error fields like code, id, message, more, report).
responseHeaders includes key cache/rate headers (such as x-cache-status, cf-cache-status, cache-control, x-rate-limit-*) when present.
MCP isError is set when transport fails or when microlink.status !== "success".
Parameters labeled PRO in the official Microlink docs require a paid plan.
For compatibility with some MCP clients:
boolean parameters also accept the strings "true" and "false" and are normalized before validation.
parameters that accept objects also accept JSON stringified objects (for example, screenshot: "{\"overlay\":{\"browser\":\"dark\"}}").
microlink_extractExtract structured metadata from any public URL. Returns normalized fields (title, description, author, publisher, date, image, logo, lang, url) plus any custom fields defined via CSS selectors.
Supports combining multiple features in a single request: screenshot, PDF, video, audio, insights, and palette.
For screenshot, pdf, and insights, use true for defaults or an object for options. Empty objects ({}) are treated as true.
Key parameters:
Parameter | Type | Description |
|
| The URL to extract data from (required) |
|
| Microlink API key (optional; see Authentication) |
|
| Custom CSS-selector extraction rules |
|
| Include/exclude normalized metadata fields |
|
| Microlink embed mode |
|
| Include iframe payload options |
|
| Custom Microlink function hook |
|
| Enable ping checks |
|
| Capture a screenshot |
|
| Generate a PDF |
|
| Extract video source |
|
| Extract audio source |
|
| Run Lighthouse / tech detection |
|
| Extract color palette |
|
| Enable ad blocking |
|
| Enable/disable animations |
|
| Emulate a device (e.g. |
|
| Preferred color scheme |
|
| Custom viewport dimensions |
|
| CSS selector(s) to click before capture |
|
| CSS selector to scroll to |
|
| Toggle JavaScript execution |
|
| Browser module(s) to inject |
|
| JavaScript to inject |
|
| CSS to inject |
|
| CSS media mode |
|
| Prerender strategy |
|
| Proxy configuration (PRO) |
|
| Retry count |
|
| Cache TTL |
|
| Stale cache TTL policy (PRO) |
|
| Bypass cache |
|
| Request timeout |
|
| Custom HTTP headers (PRO) |
|
| Preferred output filename (PRO) |
|
| Response filter |
|
| Wait for element before capture |
|
| Wait an additional timeout before capture |
|
| Navigation event(s): |
microlink_screenshotCapture a screenshot of any public URL and receive a permanent CDN asset URL (data.screenshot.url).
Set screenshot to true for defaults, or pass screenshot: { ... } for options. screenshot: {} is treated as true.
Key parameters:
Parameter | Type | Description |
|
| The URL to screenshot (required) |
|
| Enable screenshot with defaults ( |
|
| Capture the full scrollable page |
|
| CSS selector to capture a specific element |
|
| Output format (default: |
|
| Transparent background |
|
| Browser chrome overlay ( |
|
| Syntax-highlight theme for code pages (e.g. |
|
| Preferred color scheme |
|
| Device emulation |
|
| Custom viewport |
|
| Click before capture |
|
| Scroll to element |
|
| JavaScript to inject before capture |
|
| CSS to inject before capture |
|
| Browser module(s) to inject |
|
| Proxy configuration (PRO) |
|
| Custom HTTP headers (PRO) |
|
| Bypass cache |
|
| Cache TTL |
|
| Stale cache TTL policy (PRO) |
|
| Retry count |
|
| Request timeout |
|
| Prerender strategy |
|
| Enable ad blocking |
|
| Enable/disable animations |
|
| Toggle JavaScript execution |
|
| CSS media mode |
|
| Preferred output filename (PRO) |
|
| Response filter |
|
| Wait for element |
|
| Wait an additional timeout before capture |
|
| Navigation event(s): |
microlink_pdfGenerate a PDF of any public URL and receive a permanent CDN asset URL (data.pdf.url).
Set pdf to true for defaults, or pass pdf: { ... } for options. pdf: {} is treated as true.
Key parameters:
Parameter | Type | Description |
|
| The URL to convert (required) |
|
| Enable PDF with defaults ( |
|
| Paper size: |
|
| Landscape orientation |
|
| Page margins (e.g. |
|
| Page scale factor (0.1–2.0) |
|
| Page range (e.g. |
|
| Custom dimensions (overrides |
|
| JavaScript to inject before rendering |
|
| CSS to inject before rendering |
|
| Browser module(s) to inject |
|
| Proxy configuration (PRO) |
|
| Custom HTTP headers (PRO) |
|
| Bypass cache |
|
| Cache TTL |
|
| Stale cache TTL policy (PRO) |
|
| Retry count |
|
| Request timeout |
|
| Prerender strategy |
|
| Enable ad blocking |
|
| Enable/disable animations |
|
| Toggle JavaScript execution |
|
| Device emulation |
|
| Custom viewport |
|
| Preferred output filename (PRO) |
|
| Response filter |
|
| CSS media type |
|
| Wait for element |
|
| Wait an additional timeout before rendering |
|
| Navigation event(s): |
microlink_videoDetect and extract a playable video source from any URL. Returns the video URL in data.video.url along with type, duration, size, width, height, duration_pretty, and size_pretty.
Supports YouTube, Vimeo, Twitter/X, TikTok, Instagram, Dailymotion, and hundreds of other platforms.
Key parameters:
Parameter | Type | Description |
|
| The URL containing a video (required) |
|
| Proxy for restricted platforms (PRO) |
|
| Include/suppress page metadata |
microlink_audioDetect and extract a playable audio source from any URL. Returns the audio URL in data.audio.url along with type, duration, size, duration_pretty, and size_pretty.
Supports SoundCloud, Spotify, Mixcloud, and other audio platforms.
Key parameters:
Parameter | Type | Description |
|
| The URL containing audio (required) |
|
| Proxy for restricted platforms (PRO) |
|
| Include/suppress page metadata |
microlink_insightsGet web performance and technology-stack insights for any URL.
Set insights to true for defaults, or pass insights: { ... } for options. insights: {} is treated as true.
Key parameters:
Parameter | Type | Description |
|
| The URL to analyze (required) |
|
| Enable default insights ( |
|
| Run a Lighthouse audit |
|
| Report format (default: |
|
| Audit preset: |
|
| Lighthouse category IDs (e.g. |
|
| Detect tech stack via Wappalyzer |
microlink_metaExtract normalized metadata from any public URL. Returns: title, description, lang, author, publisher, date, url, image (with dimensions and file info), and logo (publisher favicon).
Key parameters:
Parameter | Type | Description |
|
| The URL to inspect (required) |
|
|
|
microlink_paletteExtract a color palette from images detected on any public URL. For each image returns: palette (hex colors from most to least dominant), background_color (optimal WCAG-contrast background), color (best overlay color), and alternative_color.
Color data is nested under each image field (e.g. data.image.palette). Useful for generating design tokens, theming, or accessibility checks.
Key parameters:
Parameter | Type | Description |
|
| The URL to analyze (required) |
|
| Control metadata fields returned |
|
| Enable palette extraction (default: |
microlink_markdownConvert any public URL to Markdown. Returns JSON output with Markdown content in microlink.data.markdown, useful for extracting readable content from web pages, articles, and documentation.
Key parameters:
Parameter | Type | Description |
|
| The URL to convert (required) |
|
| Microlink API key (optional) |
microlink_textExtract plain text from any public URL. Returns JSON output with plain text content in microlink.data.text.
Key parameters:
Parameter | Type | Description |
|
| The URL to extract text from (required) |
|
| Microlink API key (optional) |
This package bundles Agent Skills in the skills/
directory. Each skill is a self-contained SKILL.md that teaches an AI agent how to
accomplish a task with the Microlink MCP tools above. They follow the open Agent Skills
standard, so they work with any agent that supports it (Claude Code, Claude Desktop,
Cursor, VS Code agents, and others).
Skill | What it does | Tools used |
Screenshots & PDFs (full-page, element, device, dark mode, OG images) |
| |
URL → clean Markdown, plain text, metadata, or custom CSS-scraped fields |
| |
Rich link-unfurl / social cards from metadata, palette, and thumbnail |
| |
Lighthouse performance / SEO / a11y audits and tech-stack detection |
| |
Resolve a page to a direct, playable video or audio source URL |
|
To use a skill in Claude Code, copy its directory into .claude/skills/. For other
agents, see your tool's skills or extensions catalog. More detail in
skills/README.md.
Every tool accepts an optional apiKey parameter. The key is resolved from these sources in order of priority:
apiKey field in the tool input parameters
Authorization: Bearer <key> header from the MCP request
x-api-key header from the MCP request
MICROLINK_API_KEY environment variable
The MICROLINK_API_KEY environment variable is the recommended approach for most integrations. Get your key at microlink.io.
If an API key is present, requests are sent to https://pro.microlink.io; otherwise they go to https://api.microlink.io (free endpoint).
When the free endpoint returns 429, this MCP adds a clear hint in the tool error message: free daily quota reached (50 requests/day) and upgrade/API key guidance at microlink.io/#pricing.
microlink © Microlink, released under the MIT License. Authored and maintained by Kiko Beats with help from contributors.
microlink.io · GitHub microlinkhq · X @microlinkhq
Detect and extract playable audio sources from any URL via Microlink. Works with SoundCloud, Spotify, Mixcloud, and other audio platforms. The audio URL is in data.audio.url. Also returns type, duration, size, duration_pretty, and size_pretty. Combine with proxy for sites that require it, or with meta to suppress metadata extraction.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| meta | No | ||
| audio | No | ||
| proxy | No | ||
| apiKey | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the output structure (e.g., `data.audio.url`) and behavior (detect and extract), but does not disclose potential side effects, authentication needs, rate limits, or error conditions. Adequate but not exhaustive.
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?
Three sentences with no redundancy. First sentence states purpose and scope, second lists output fields, third gives usage tips. Every sentence earns its place; highly efficient.
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 no output schema and no annotations, the description should fully equip the agent. It covers main functionality and key parameters, but misses `audio` and `apiKey`, and lacks error handling or limitations. Partially complete; could be more 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?
Schema coverage is 0%, so description must compensate. It explains `url` (required) and mentions `proxy` and `meta`. However, it does not explain `audio` (a boolean parameter) or `apiKey`, leaving two parameters undocumented. Adds some meaning but significant gaps remain.
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?
Clearly states 'Detect and extract playable audio sources from any URL via Microlink', specifies target platforms (SoundCloud, Spotify, Mixcloud), and distinguishes from sibling tools like microlink_video by focusing on audio extraction.
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?
Provides explicit guidance on when to combine with `proxy` or `meta` parameters, offering concrete usage tips. However, it does not explicitly state when not to use this tool versus alternatives, though the sibling list implies specificity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract structured metadata from any public URL via Microlink. Returns normalized fields: title, description, author, publisher, date, image, logo, lang, and url. Use the data parameter to scrape custom fields via CSS selectors (selector/selectorAll, attr, type, evaluate). Combine with screenshot, pdf, video, audio, insights, palette, iframe in a single request. For screenshot, pdf, and insights, pass true to enable defaults or pass a config object with options; {} is treated as true. Supports device emulation (device), custom headers, proxy, JavaScript injection (scripts, modules, function), interaction (click, scroll), and caching (ttl, staleTtl, force). The CDN asset URL for any enabled media feature is in data.<feature>.url (e.g. data.screenshot.url).
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| ttl | No | ||
| url | Yes | ||
| data | No | ||
| meta | No | ||
| ping | No | ||
| audio | No | ||
| click | No | ||
| embed | No | ||
| force | No | ||
| proxy | No | ||
| retry | No | ||
| video | No | ||
| apiKey | No | ||
| device | No | ||
| filter | No | ||
| iframe | No | ||
| scroll | No | ||
| styles | No | ||
| adblock | No | ||
| headers | No | ||
| modules | No | ||
| palette | No | ||
| scripts | No | ||
| timeout | No | ||
| filename | No | ||
| function | No | ||
| insights | No | ||
| staleTtl | No | ||
| viewport | No | ||
| mediaType | No | ||
| prerender | No | ||
| waitUntil | No | ||
| animations | No | ||
| javascript | No | ||
| screenshot | No | ||
| colorScheme | No | ||
| waitForTimeout | No | ||
| waitForSelector | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes many behaviors: metadata extraction, custom scraping via 'data', enabling media features with 'true' or objects, CDN asset URLs, device emulation, headers, proxy, JS injection, interaction, caching, etc. It does not mention rate limits or auth details, but covers a wide range of behaviors transparently.
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 dense paragraph. It is informative but lacks structure (e.g., bullet points). It front-loads the core purpose but later lists many options in a run-on fashion. Could be more concise and organized.
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 has 39 parameters, no output schema, and no annotations, the description is fairly comprehensive but still misses many parameters (e.g., viewport, waitForSelector, embed, filter). It covers the most important behaviors and provides enough context for typical use, but not complete for edge cases.
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?
Schema description coverage is 0%, so the description must compensate. It explains key parameters like data, screenshot, pdf, insights, device, headers, etc., and their behavior (e.g., passing true enables defaults). However, many of the 39 parameters (e.g., adblock, animations, colorScheme, waitUntil, timeout) are not mentioned, leaving gaps.
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 'Extract structured metadata from any public URL via Microlink' and lists the normalized fields returned. It distinguishes from sibling tools by being the main extraction tool that can also enable features like screenshot, pdf, etc., while siblings are for individual features.
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 explains that this tool can extract metadata and combine multiple features in one request, implying it is for comprehensive extraction. It mentions sibling features like screenshot, pdf, etc., allowing an agent to choose this over specialized siblings when multiple outputs are needed. However, it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get web performance and technology-stack insights for any URL via Microlink. Pass insights: true for defaults or insights: { ... } for options; insights: {} is treated as true. Use insights.lighthouse (true or config object) for a Lighthouse performance audit. - insights.lighthouse.output: report format — "json" (default), "html", or "csv". - insights.lighthouse.preset: "default", "desktop", "perf", "experimental", "full", "lr-desktop", "lr-mobile". - insights.lighthouse.onlyCategories: array of category IDs to include (e.g. ["performance", "accessibility"]). Use insights.technologies (true) to detect the technology stack (frameworks, CDNs, analytics, etc.) via Wappalyzer. Both can be combined in a single request.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| apiKey | No | ||
| insights | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It explains that `insights: {}` is treated as true, details Lighthouse output formats and presets, and mentions technology detection. However, it omits aspects like authentication requirements (though `apiKey` is in schema), rate limits, or error behaviors.
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 informative but slightly lengthy. It uses bullet points and code formatting for clarity. Every sentence adds value, though some information (e.g., explicit enum values) could be more compact. Overall, well-structured and readable.
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 no output schema, the description partially explains response format (e.g., Lighthouse output as json/html/csv) and technology detection. It covers all parameters and options. However, it does not describe the overall response structure or error handling, leaving some gaps for a comprehensive understanding.
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?
Schema description coverage is 0%, so the description must add value. It thoroughly explains the `insights` parameter, its sub-objects, enums for output and preset, and array for categories. This goes well beyond the schema, providing clear semantics for each option.
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 explicitly states the tool's purpose: 'Get web performance and technology-stack insights for any URL via Microlink.' It clearly differentiates from sibling tools (e.g., microlink_audio, microlink_screenshot) by focusing on insights like Lighthouse audits and technology detection.
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 detailed usage instructions, including how to pass `insights` as boolean or object, Lighthouse options, and technology detection. However, it does not explicitly contrast with alternatives among sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert any public URL to Markdown via Microlink. Returns JSON output with Markdown content under data.markdown. Useful for extracting readable content from web pages, articles, and documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| apiKey | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the output JSON structure, but omits critical behavioral details such as authentication requirements (apiKey parameter), rate limits, error handling, or restrictions on URL accessibility.
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 three sentences long, front-loaded with the main action, and contains no fluff. Every sentence adds value.
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 lack of annotations and output schema, the description covers the primary function and output format, but misses important context about parameters, authentication, and sibling differentiation, making it adequate but not fully 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?
Schema coverage is 0%, so the description must compensate. It implies the URL parameter but does not mention the apiKey parameter at all, nor its purpose or whether it is required. This leaves the agent with incomplete parameter understanding.
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 'Convert', the resource 'any public URL to Markdown', and the use case 'extracting readable content'. It also specifies the output format. This distinguishes it from sibling tools that perform other conversions.
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 implies use for extracting readable content in Markdown format, but does not provide explicit guidance on when to use this tool versus alternatives like microlink_text or microlink_extract, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract normalized metadata from any public URL via Microlink. Returns: title, description, lang, author, publisher, date, url, image (with dimensions and file info), and logo (publisher favicon). Pass meta: false to skip metadata extraction entirely — useful when you only need a screenshot or video and want a faster response. Pass a config object to include or exclude specific fields: { logo: true, title: true } returns only those fields; { image: false } returns everything except image.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| meta | No | ||
| apiKey | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral transparency. It details the return format and behavior of the meta parameter (e.g., passing an object to include/exclude fields). However, it does not explain the apiKey parameter, rate limits, error conditions, or whether the tool is read-only.
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, well-structured paragraph. It front-loads the purpose and return fields, then explains the meta parameter with two use cases. No redundant sentences, though it could be slightly more organized with bullet points.
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 no output schema, the description adequately explains return fields and meta parameter. However, it lacks explanation of the apiKey parameter and does not help the agent decide between this and nine sibling tools, which is a gap for a tool with multiple specialized variants.
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 has 3 parameters (url, meta, apiKey) with 0% description coverage. The description thoroughly explains the meta parameter (boolean and object forms) but completely omits the apiKey parameter, leaving its purpose unclear.
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 specifies the tool extracts normalized metadata from any public URL, lists returned fields (title, description, lang, etc.), and clearly differentiates from sibling tools like screenshot or video by focusing on metadata extraction.
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 explains when to use the tool (to get metadata) and how to skip metadata for faster response. However, it does not provide explicit guidance on when not to use this tool versus alternatives like microlink_screenshot or microlink_text, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract a color palette from images detected on any public URL via Microlink. For each image, returns: palette (hex colors from most to least dominant), background_color (optimal WCAG-contrast background), color (best overlay color for the background), and alternative_color (secondary overlay color). Color data is nested under each image field in the response (e.g. data.image.palette, data.image.background_color). Useful for generating design tokens, theming, or accessibility checks from real page images.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| meta | No | ||
| apiKey | No | ||
| palette | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the output structure (palette, background_color, etc.) and nesting, but does not mention side effects, rate limits, authentication needs, or behavior on URLs with no images. Partially transparent.
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 concise (3 sentences), front-loaded with the primary purpose. Each sentence adds value, though it could be slightly more compact. No wasted words.
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 4 parameters and no output schema, the description fails to cover parameter semantics and usage context. The return structure is well explained, but missing parameter documentation and lack of output schema info leaves the description incomplete for effective tool selection.
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?
Schema description coverage is 0%, yet the description does not explain any of the parameters (url, meta, apiKey, palette). It only indirectly mentions URL. This is a critical gap; the description adds no value beyond the schema's bare structure.
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 extracts a color palette from images on a public URL via Microlink, with specific verb 'extract' and resource. It distinguishes from sibling tools (like microlink_screenshot or microlink_meta) by focusing on palette extraction.
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 suggests use cases (design tokens, theming, accessibility checks) but does not explicitly state when to use this tool versus alternatives (e.g., microlink_meta for metadata). No when-not-to-use or comparison to siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a PDF of any public URL via Microlink and return a permanent CDN asset URL. The PDF URL is in data.pdf.url. Pass pdf: true for defaults or pdf: { ... } for options; pdf: {} is treated as true. Use pdf.format to set paper size: "A4" (default), "Letter", "Legal", "Tabloid", "Ledger", "A0"–"A6". Use pdf.landscape to switch to landscape orientation. Use pdf.margin to set page margins as a string ("0.35cm") or object with top/bottom/left/right. Use pdf.scale to scale the page (0.1–2.0). Use pdf.pageRanges to select specific pages (e.g. "1-5"). Use pdf.width and pdf.height for custom dimensions (overrides format). Combine with styles, scripts, modules, mediaType, waitForSelector, and waitUntil for full control.
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| ttl | No | ||
| url | Yes | ||
| data | No | ||
| click | No | ||
| force | No | ||
| proxy | No | ||
| retry | No | ||
| apiKey | No | ||
| device | No | ||
| filter | No | ||
| scroll | No | ||
| styles | No | ||
| adblock | No | ||
| headers | No | ||
| modules | No | ||
| scripts | No | ||
| timeout | No | ||
| filename | No | ||
| staleTtl | No | ||
| viewport | No | ||
| mediaType | No | ||
| prerender | No | ||
| waitUntil | No | ||
| animations | No | ||
| javascript | No | ||
| colorScheme | No | ||
| waitForTimeout | No | ||
| waitForSelector | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool generates a PDF, returns a CDN URL, and details many options. It mentions the output path 'data.pdf.url'. However, it does not mention limitations like public URLs only or rate limits.
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 dense paragraph but front-loads the main purpose and uses clear language. It could be improved with bullet points for readability, but it is efficient with no wasted words.
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 29 parameters and no output schema, the description is incomplete. It fails to explain many parameters (e.g., ttl, data, click, force, proxy) and does not describe the full return structure beyond the PDF URL path. This leaves significant gaps for an agent.
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?
Schema coverage is 0%, so description must compensate. It explains core pdf options (format, landscape, margin, scale, etc.) and mentions several other parameters (styles, scripts, modules, etc.). However, it omits many of the 29 parameters such as ttl, data, click, force, proxy, and others.
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's purpose: 'Generate a PDF of any public URL via Microlink and return a permanent CDN asset URL.' It specifies the verb (generate), resource (PDF), and output. The sibling tools cover other media types, making this distinct.
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 clear usage guidance, including how to pass options via 'pdf' parameter and mentions combining with other parameters for full control. However, it does not explicitly state when not to use this tool or list alternatives, though siblings are different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot of any public URL via Microlink and return a permanent CDN asset URL. The screenshot URL is in data.screenshot.url. Pass screenshot: true for defaults or screenshot: { ... } for options; screenshot: {} is treated as true. Use screenshot.fullPage to capture the entire scrollable page. Use screenshot.element (CSS selector) to capture a specific DOM element. Use screenshot.type to choose output format: "jpeg" (default "png"). Use screenshot.omitBackground to remove the white background (useful with transparent PNGs). Use screenshot.overlay to add a browser chrome overlay with browser ("light"|"dark") and background (CSS color or gradient). Use screenshot.codeScheme to set the syntax-highlighting theme for code pages (e.g. "dracula", "atom-dark"). Combine with device, viewport, click, scroll, styles, scripts, modules, waitForSelector, waitForTimeout, waitUntil, colorScheme, and mediaType for full browser control.
| Name | Required | Description | Default |
|---|---|---|---|
| ttl | No | ||
| url | Yes | ||
| data | No | ||
| click | No | ||
| force | No | ||
| proxy | No | ||
| retry | No | ||
| apiKey | No | ||
| device | No | ||
| filter | No | ||
| scroll | No | ||
| styles | No | ||
| adblock | No | ||
| headers | No | ||
| modules | No | ||
| scripts | No | ||
| timeout | No | ||
| filename | No | ||
| staleTtl | No | ||
| viewport | No | ||
| mediaType | No | ||
| prerender | No | ||
| waitUntil | No | ||
| animations | No | ||
| javascript | No | ||
| screenshot | No | ||
| colorScheme | No | ||
| waitForTimeout | No | ||
| waitForSelector | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains the output structure and many options (fullPage, element, type, etc.) but does not mention authentication requirements, rate limits, error handling, or whether the operation is read-only. It adds context beyond the schema but lacks full behavioral disclosure.
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 dense paragraph that front-loads the core purpose but then lists many options in a run-on manner. It could be more structured (e.g., bullet points) but is not excessively long. Every sentence adds some information, though some list items without explanation.
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 complexity (29 parameters, no output schema, no annotations), the description is insufficient. It explains the screenshot-specific options well but omits nearly all other parameters (ttl, force, proxy, retry, apiKey, etc.), leaving large gaps for agent understanding. The 'Combine with...' mention is vague and incomplete.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaning for the screenshot object and its sub-fields, and lists other parameters like device, viewport, etc., but does not explain their purpose or behavior. The addition is incomplete for a tool with 29 parameters.
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 captures a screenshot of any public URL and returns a permanent CDN asset URL, specifying the result location. This is a specific verb-resource combination that distinguishes it from siblings like microlink_audio or microlink_pdf.
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 alternative sibling tools like microlink_pdf or microlink_extract. It does not mention prerequisites, exclusions, or context for use, leaving the agent to infer usage solely from the tool name and description of capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract plain text from any public URL via Microlink. Returns JSON output with plain text content under data.text. Useful for getting raw text content from web pages.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| apiKey | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions that the URL must be public and the output is JSON, but it does not address authentication needs (apiKey is optional), error handling, rate limits, or whether the action is destructive or read-only.
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 concise (two sentences) and front-loaded with the main action. However, it omits crucial details, so the conciseness comes at the cost of completeness. Still, no unnecessary words are present.
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 has only two parameters and no output schema, the description is partially complete: it defines the output and basic use. But it lacks context about the apiKey, error scenarios, and how this tool relates to siblings like microlink_meta or microlink_markdown.
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?
Schema description coverage is 0%, yet the description adds no meaning for either parameter. The `url` parameter is only implied, and `apiKey` is entirely unmentioned, leaving the agent with no guidance on its purpose or necessity.
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 it extracts plain text from any public URL and specifies the output structure (`data.text`). The tool name and description differentiate it from sibling tools that handle audio, video, meta, etc., making its purpose unambiguous.
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 says it is 'useful for getting raw text content from web pages,' which implies when to use it. However, it provides no explicit guidance on when not to use it or contrasts with sibling tools like microlink_meta or microlink_markdown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect and extract playable video sources from any URL via Microlink. Works with YouTube, Vimeo, Twitter/X, TikTok, Instagram, Dailymotion, and hundreds of other platforms. The video URL is in data.video.url. Also returns type, duration, size, width, height, duration_pretty, and size_pretty. Combine with proxy for sites that require it, or with meta to suppress metadata extraction.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| meta | No | ||
| proxy | No | ||
| video | No | ||
| apiKey | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description partially discloses behavior: explains output structure (data.video.url and other fields), and mentions proxy and meta usage. However, it does not cover rate limits, authentication, or error handling.
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 two sentences plus a final usage hint, efficiently conveying the purpose and key details. It is front-loaded with the main function.
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?
Despite no output schema, the description explains return fields. However, it lacks prerequisites, error scenarios, and thorough parameter coverage. With 5 parameters and high complexity, more detail is needed.
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?
Schema description coverage is 0%. The description adds meaning for `proxy` and `meta` but does not explain `video` boolean or `apiKey`. Only 2 of 5 parameters are addressed, insufficient given the lack of schema descriptions.
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 detects and extracts playable video sources from any URL via Microlink, listing supported platforms. It distinguishes from siblings by focusing on video extraction.
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 mentions combining with `proxy` and `meta` parameters, but does not explicitly state when to use this tool versus other microlink tools or when not to use it. No alternatives are given.
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.
v1.0.1microlink_audiomicrolink_extractmicrolink_insightsmicrolink_markdownmicrolink_metamicrolink_palettemicrolink_pdfmicrolink_screenshotmicrolink_textmicrolink_videoScored across 10 tools
Some tools have overlapping purposes, e.g., microlink_extract and microlink_meta both return metadata, and microlink_text vs microlink_markdown both extract text. This could cause confusion for an agent selecting which tool to use.
All tools follow the consistent pattern 'microlink_<noun>', where the noun describes the output type (e.g., audio, extract, insights, markdown, meta, palette, pdf, screenshot, text, video). No deviations.
10 tools is well-scoped for a server that extracts various content types from URLs. Each tool has a clear purpose, and the count feels appropriate without being overwhelming or too sparse.
The set covers most common extraction needs (audio, video, images, metadata, text, markdown, PDF, insights, color palette). The presence of both a general extract tool and dedicated tools might be redundant but does not create critical gaps. Missing features like OCR or language detection are minor.
Microlink MCP — wraps Microlink API (free tier, no auth required)
Turn any URL into clean Markdown and structured data. Scrape, crawl, search and extract.
Turns any URL into SEO metadata, contacts, tech stack, and AI-ready Markdown, in one call.
Link-preview metadata and clean page-to-Markdown for any public URL. No install.
