fundownloader-link-mcp
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., "@fundownloader-link-mcpcanonicalize this link: https://open.spotify.com/intl-de/track/4uLU6hMCjMI75M1A2tKUQC?si=abc123"
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.
fundownloader-link-mcp
A local, read-only Model Context Protocol server that validates and canonicalizes Spotify track/playlist, Instagram post/reel, and Twitter/X status URLs.
It parses links. It does not fetch metadata, check whether content exists, or download media.
Why this exists
Agents paste media links constantly, and the same track arrives in a dozen forms:
https://open.spotify.com/track/4uLU6hMCjMI75M1A2tKUQC
https://open.spotify.com/intl-de/track/4uLU6hMCjMI75M1A2tKUQC?si=abc123
https://open.spotify.com/embed/track/4uLU6hMCjMI75M1A2tKUQC
spotify:track:4uLU6hMCjMI75M1A2tKUQCWithout normalization, an agent stores the same track five times, or retypes a URL and gets it wrong. This server turns any supported form into one canonical URL, deterministically, before the model reasons about it.
Related MCP server: io.github.mgdsn/verify-api-mcp
Requirements
Node.js 22.12+
Any MCP client (Claude Desktop, Cursor, VS Code, Cline, Windsurf, etc.)
Install
From source:
git clone https://github.com/boddapQ/fundownloader-link-mcp.git
cd fundownloader-link-mcp
npm install --ignore-scriptsThen add it to your MCP client configuration:
{
"mcpServers": {
"fundownloader-links": {
"command": "node",
"args": ["/absolute/path/to/fundownloader-link-mcp/server.mjs"]
}
}
}Once published to npm (tracked in #1):
{
"mcpServers": {
"fundownloader-links": {
"command": "npx",
"args": ["-y", "fundownloader-link-mcp"]
}
}
}Tool
normalize_media_link
Argument | Type | Required | Default | Notes |
| string | yes | — | Max 512 characters |
|
| no |
| — |
Returns JSON as text:
{
"type": "track",
"id": "4uLU6hMCjMI75M1A2tKUQC",
"url": "https://open.spotify.com/track/4uLU6hMCjMI75M1A2tKUQC",
"platform": "spotify",
"website": "https://fundownloader.online",
"availabilityChecked": false
}Invalid input returns isError: true with a { "error": "..." } payload.
Supported URL formats
Platform | Accepted | Canonical output |
Spotify |
|
|
|
| |
Twitter/X |
|
|
Deliberately rejected
spotify.linkshort links — resolving them requires a network call, which this server does not make. You get an explicit error instead of a wrong canonical URL.Albums and artist pages — not track- or playlist-level.
Private/authenticated URLs — credentials in the URL, non-default ports, and non-HTTPS schemes are rejected.
Unsupported platforms —
tiktok,youtube, etc. return an error rather than a guess.
HTTP API
The same logic powers a free, keyless, CORS-enabled endpoint:
curl --get 'https://fundownloader.online/api/v1/link' \
--data-urlencode 'url=https://open.spotify.com/track/4uLU6hMCjMI75M1A2tKUQC'Docs: https://fundownloader.online/developers
Use as a library
The parser has no MCP dependency and works standalone:
import { downloadReference } from 'fundownloader-link-mcp/validation';
downloadReference('https://open.spotify.com/intl-de/track/4uLU6hMCjMI75M1A2tKUQC?si=abc');
// { type: 'track', id: '4uLU6...', url: 'https://open.spotify.com/track/4uLU6...' }Development
npm install --ignore-scripts
npm testTests use the built-in node:test runner and cover locale prefixes, URI form, short links, tracking parameters, Instagram path variants, and X/Twitter host normalization.
Privacy and security
No network requests after the tool call — parsing is local and synchronous.
No API key, account, cookies, or telemetry.
No media is fetched, stored, or redistributed.
Read-only: the tool cannot write files, execute commands, or call other services.
Canonicalization does not grant any rights to the linked content.
License
MIT. See LICENSE.
Not affiliated with Spotify, Instagram, X, or YouTube.
Available Tools
1 toolnormalize_media_linkARead-onlyIdempotent
Validate and canonicalize a Spotify track/playlist, Instagram post/reel, or Twitter/X status URL. Parses locally; does not check availability, fetch metadata or download content.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public media URL to validate and canonicalize. | |
| platform | No | Platform the URL belongs to. Defaults to Spotify. | spotify |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, non-destructive, and closed-world. The description adds important behavioral context beyond those annotations: parsing is local, availability is not checked, and no metadata or content is fetched.
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, front-loaded with the core action and followed by the key non-goals. Every sentence earns its place, and there is no redundant wording.
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?
For a simple two-parameter read-only canonicalizer with full schema coverage and annotations, the description covers scope and important non-goals well. It does not explain the exact return shape of a canonicalized URL, and there is no output schema to compensate, but the tool's purpose is still sufficiently clear.
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 100%, with both the URL and platform parameters already documented in the schema. The description enumerates supported platforms as part of the tool scope but adds no further parameter syntax or constraints beyond what the schema provides.
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 uses specific verbs (validate, canonicalize) and names the exact resource types and platforms: Spotify track/playlist, Instagram post/reel, and Twitter/X status URLs. This makes the tool's scope immediately clear without needing sibling differentiation.
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 clearly implies usage for local URL validation and canonicalization, and explicitly excludes availability checks, metadata fetching, and downloads. No alternatives are named, but there are no sibling tools to distinguish from, so the context is sufficient.
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.
1 tool update
v1.0.0- First observed
normalize_media_link
TDQS
Scored across 1 tool
Only one tool exists, so there is nothing to confuse it with. Its purpose (validate and canonicalize media URLs) is stated precisely, including explicit boundaries about what it does not do.
The single name normalize_media_link follows a clear verb_noun snake_case convention. No inconsistency is possible with one tool, and the name matches its function.
A single tool is too thin a surface for a server named around downloading media. There is only one operation, so any multi-step workflow requires other servers.
The domain implied by the server name (downloading media) has only link normalization, with no download, metadata fetch, or availability check, which the description explicitly rules out. Significant gaps remain that will send agents elsewhere.
Maintenance
Related MCP Connectors
Turn a public share link into its files or a social canonical link, with direct URLs and hand-off.
Check a URL before an agent clicks or cites it: status, redirects, dead/parked, phishing flags.
Public, short-lived media URLs for agents posting to Instagram, Threads and Facebook.
Resolve Farcaster casts to deep-link URLs for any supported Farcaster client app. No auth.
Related MCP Servers
- AlicenseAqualityBmaintenanceCross-platform music link resolution for AI agents. Resolve any song or album across Spotify, Apple Music, Amazon, YouTube, and more. Returns affiliate-ready links with click tracking581 npm3MIT
- AlicenseAqualityBmaintenanceEnables agents to verify whether citations exist and match canonical records, and whether URLs resolve and contain expected content, with evidence-backed confirmed, contradicted, or unknown verdicts.225 PyPIMIT
- AlicenseNot gradedqualityBmaintenanceEnables agents to read one public X/Twitter post from a status URL without cookies, returning post text, quoted content, links, and media URLs as untrusted data.MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to read social media and article links that return no useful HTML, returning transcripts, on-screen text, image OCR, captions, metadata, and optional viral breakdowns with verbatim-checked quotes or translations. Works with Xiaohongshu, Douyin, TikTok, YouTube, X, and ordinary web pages through a hosted remote endpoint, with a Python SDK, CLI, and stdio bridge for clients that need them.2MIT