How do I use whamlink-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@whamlink-mcp Publish this note as a permanent link" 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.

whamlink-mcp

by billkinddev

Overview Schema Related Servers Score Discussions

TypeScript

Remote

whamlink-mcp

An MCP server for whamlink — let any MCP client (Claude Desktop, IDEs, agents) publish a single file to a permanent, shareable link.

Setup

Get an API key: register at https://whamlink.com/app, then create a key under Keys.
Add the server to your MCP client config, passing the key via WHAMLINK_API_KEY.

Claude Desktop (`claude_desktop_config.json`)

{
  "mcpServers": {
    "whamlink": {
      "command": "npx",
      "args": ["-y", "whamlink-mcp"],
      "env": { "WHAMLINK_API_KEY": "wl_your_key_here" }
    }
  }
}

Running from source instead of npm: "command": "node", "args": ["/path/to/whamlink/mcp/dist/index.js"] (after npm install && npm run build in mcp/).

Environment

WHAMLINK_API_KEY (optional) — your whamlink API key. If unset, the server still starts; the agent can register to create an account in-session (save the returned key here to persist).
WHAMLINK_BASE_URL (optional) — defaults to https://whamlink.com.

Related MCP server: @dropthis/mcp

Tools

Tool	What it does
`register`	Create an account on the user's behalf (consent + real email). Lets a new user go zero-to-published without setting a key first.
`publish_link`	Publish HTML / Markdown / PDF / image / text → a permanent URL. Public by default; set `visibility` to `private` / `password` / `email` to gate it.
`list_links`	List your published links (id, slug, mode, visibility, URL).
`set_link_access`	Change a link's visibility, password, shared-email list, `allowNetwork`, or title.
`replace_link_content`	Replace a link's content in place — the URL stays the same.
`delete_link`	Permanently delete a link.

PDF and image files aren't supported over MCP (tool args are JSON, which can't carry binary) — use the whamlink dashboard or the multipart API for those.

Never publish secrets, API keys, or private data. Public links are unlisted but anyone with the URL can view them; use private/password/email visibility for anything sensitive.

Develop

npm install
npm run build
npm test

Available Tools

6 tools

delete_linkB

Permanently delete a published link by its id.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The doc id, e.g. doc_xxx (from list_links or publish_link)

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It mentions permanence but lacks details on permissions, error conditions, or side effects. Minimal disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It is not structured but appropriate for its simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one required parameter and no output schema, the description is adequate but lacks behavioral context (e.g., error handling, prerequisites).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description of the id parameter. The description's 'by its id' adds no new meaning beyond the schema, so baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (delete), resource (published link), and identifier (id). It distinguishes from siblings like list_links and publish_link.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for deleting a link by id but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_linksA

List the links you've published (id, slug, title, mode, visibility, size, URL).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must carry the full burden. It discloses that it returns a list with specific fields but does not mention pagination, sorting, or authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that is immediately informative with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 0 parameters, no output schema, and a straightforward read operation, the description provides all necessary information for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema description coverage is trivially 100%. The description adds value by listing the returned fields, exceeding the baseline of 4 for 0 parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and resource ('links you've published') and clearly states the returned fields. It effectively distinguishes from sibling tools like delete_link and publish_link.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. While the tool is simple and self-explanatory, there is no mention of context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

publish_linkA

Publish text-based content (HTML, Markdown, or plain text) to a permanent whamlink URL. Links are public (unlisted) by default; set visibility to private/password/email to gate them. (PDF/image files aren't supported over MCP — use the whamlink dashboard or multipart API for those.) Never publish secrets or private data.

ParametersJSON Schema

Name	Required	Description
`mode`	Yes	sandboxed_html (runs JS, isolated origin), sanitized_html (scripts stripped), markdown, or text
`title`	No
`content`	Yes	The text content to publish (UTF-8).
`password`	No
`visibility`	No	Default public. private = owner only; password = also pass `password`; email = also pass `shareEmails`
`shareEmails`	No
`allowNetwork`	No	Let sandboxed/sanitized HTML load https CDN scripts/styles

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description carries full burden. It discloses permanent nature, public default, visibility controls, and security warning. Does not mention response format or rate limits, but covers key behavioral aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded main action, then options and exclusions. No redundancy, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with no output schema and no annotations, description covers core function, supported types, visibility, and security. Lacks explanation of title parameter and return value, but overall sufficient for agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 57% (not high/low). Description adds meaning beyond schema: clarifies supported modes (text types) and visibility interaction with password/email. Does not explain title or shareEmails explicitly, but provides useful context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it publishes text-based content to a permanent whamlink URL, specifying supported types (HTML, Markdown, plain text) and explicitly ruling out PDF/images. It distinguishes from siblings (delete, list, replace, etc.) as the only creation tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (text publishing) and when not to use (PDF/images, secrets). Provides alternative (dashboard/multipart API). Covers visibility options for gating content.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

registerA

Create a whamlink account on the USER'S behalf. Only call this with the user's explicit consent and their REAL email — a verification link is sent there. Returns an API key used for the rest of this session; tell the user to set it as WHAMLINK_API_KEY in their MCP config to keep it across restarts.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`email`	Yes	the user's real email

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It discloses email verification, API key return, and persistence advice, but does not mention potential error cases like duplicate accounts or rate limits, which would be helpful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no fluff. The first sentence states the core purpose, the second covers consent, verification, API key, and persistence. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only 2 parameters and no output schema, the description covers key aspects: consent, email verification, API key handling, and setup advice. Missing minor details like duplicate handling, but overall complete for a registration tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (only email has description). The description adds emphasis on 'REAL email' and consent context, but doesn't describe the 'name' parameter beyond its required status. Additional clarity on name would improve semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create a whamlink account') and the resource ('on the USER'S behalf'), distinguishing it from sibling tools that manage links. The verb-resource pair is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly requires user consent and a real email, and provides guidance on persisting the API key. No explicit alternatives are given, but sibling tools are unrelated, so the guidance is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

replace_link_contentC

Replace a link's content in place — the URL stays the same.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`mode`	Yes
`content`	Yes

TDQS

C2.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description only notes the URL stays the same but fails to disclose side effects, reversibility, or prerequisites for a mutation operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is brief but omits critical details, making it under-specified rather than efficiently concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 required parameters and no output schema or annotations, the description fails to explain parameter roles, constraints, or tool behavior, leaving agents with significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds no explanation for parameters id, mode, or content, leaving the agent with only the schema's raw field definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool replaces a link's content while keeping the URL unchanged, distinguishing it from siblings like delete_link, list_links, and publish_link.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., delete_link, set_link_access) or 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.

set_link_accessC

Change a link's access: visibility (public/private/password/email), password, shared email list, allowNetwork, or title.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`title`	No
`password`	No
`visibility`	No
`shareEmails`	No
`allowNetwork`	No

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must disclose behavioral traits. It mentions 'change' implying mutation but lacks details on side effects (e.g., password behavior when visibility changes), immediacy of changes, or authorization requirements. The inclusion of 'title' as an access parameter is misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence listing key parameters without unnecessary words. It is front-loaded with the verb and resource. A more structured format (e.g., bullet points) could improve readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters, no output schema, and no annotations, the description is incomplete. It lacks details on return values, behavioral effects, interaction with sibling tools, and the required 'id' parameter's role. The grouping of properties is partially helpful but leaves important gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description names parameters (visibility, password, shareEmails as 'shared email list', allowNetwork, title) but does not explain constraints (e.g., password minLength, visibility enum values) or the required 'id' parameter. It adds some semantic grouping but insufficient detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'change' and resource 'link's access', listing specific properties. However, including 'title' among access properties may cause confusion. It distinguishes from siblings like 'delete_link' but not 'publish_link'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like 'publish_link' or 'delete_link'. No conditions, prerequisites, or context are provided.

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. Dates show when Glama detected each change.

6 tool updatesv0.1.3Jul 12, 2026
- First observeddelete_link
- First observedlist_links
- First observedpublish_link
- First observedregister
- First observedreplace_link_content
- First observedset_link_access

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool targets a distinct operation: account registration, link creation, listing, deletion, content replacement, and access control. There is no overlap in functionality.

Naming Consistency4/5

All tools use snake_case and generally follow verb_noun pattern (delete_link, list_links, publish_link, replace_link_content, set_link_access). However, 'register' is a single verb without a noun, breaking the pattern slightly.

Tool Count5/5

With 6 tools, the server provides a focused set covering the core lifecycle of links (create, read, update, delete, access management) plus account setup. This is well-scoped.

Completeness4/5

The set covers CRUD and access control for text links. A minor gap is the lack of a tool to retrieve a single link's full details (list_links returns all, but may not include all fields). The file upload limitation is noted, but that's a domain constraint.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

artidrop A
ai.artidrop
Publish HTML, Markdown, and multi-file sites as shareable URLs instantly via MCP.
Content Management Systems Developer Tools
42
dropthis
io.github.dropthis-dev
Publish HTML, files, or a URL to a permanent public URL, then update it — from any MCP agent.
Cloud Storage
2
SpacefastOAuth
io.github.spacefast
Publish files and folders to the web instantly: permanent URLs, immutable versions, claim links.
Cloud Storage
22
SlidelessOAuth
ai.slideless
List, share, upload, and manage Slideless HTML presentations from any MCP host.
Content Management Systems Workplace & Productivity
2

Related MCP Servers

Aigist MCP
Content Management Systems Note Taking Workplace & Productivity
marshallino16
A
license
Not graded
quality
C
maintenance
Publish and manage shareable HTML/Markdown pages with access control and comments via MCP clients.
Updated 2 months ago (2026-07-08 19:45 UTC)
MIT
@dropthis/mcpofficial
Content Management Systems File Systems Developer Tools
dropthis-dev
A
license
A
quality
A
maintenance
Publish content (HTML, files, or URLs) and get a permanent public URL from any MCP-compatible agent, with local and remote connection options.
Updated 2 months ago (2026-07-11 14:56 UTC)
29
244
MIT
Share HTML
Cloud Storage Developer Tools
lifeodyssey
F
license
Not graded
quality
B
maintenance
Enables sharing self-contained HTML files via public or access-key-protected private links. Provides MCP tools to create shares, retrieve public share metadata, and describe the service.
Updated 16 days ago (2026-08-21 13:53 UTC)
3
-
htmldrop-mcp
Content Management Systems Developer Tools CI/CD & DevOps
middleeastsoftware
A
license
A
quality
B
maintenance
MCP server for publishing HTML or Markdown to a live hosted URL via htmldrop. Provides tools to publish, list, and delete hosted sites, with remote OAuth and API token authentication.
Updated 18 days ago (2026-08-19 17:11 UTC)
3
136
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/billkinddev/whamlink-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

whamlink-mcp

Setup

Claude Desktop (claude_desktop_config.json)

Environment

Tools

Develop

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@dropthis/mcpofficial

Latest Blog Posts

MCP directory API

Claude Desktop (`claude_desktop_config.json`)