Skip to main content
Glama
jiankn

SavePinner MCP

by jiankn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

SavePinner MCP

An MCP server for parsing, validating, classifying, and normalizing Pinterest URLs. It supports local stdio and public Streamable HTTP. The tools make no outbound network requests and do not download media.

Tools

Tool

Purpose

parse_pinterest_url

Return the URL kind, canonical URL, host, and type-specific identifiers.

normalize_pinterest_url

Convert a supported URL to canonical form and remove tracking parameters.

is_pinterest_url

Check whether a value is a supported Pinterest URL.

Supported URL kinds include Pin, pin.it, profile, board, and Ideas URLs across Pinterest country domains.

Related MCP server: @striderlabs/mcp-pinterest

Run

Node.js 18 or newer is required.

npx -y savepinner-mcp

Client configuration

Add the server to an MCP client that supports local stdio servers:

{
  "mcpServers": {
    "savepinner": {
      "command": "npx",
      "args": ["-y", "savepinner-mcp"]
    }
  }
}

Remote MCP

Connect any Streamable HTTP client to the public endpoint:

https://savepinner-pinterest-url-mcp.chenxuanshimo.workers.dev/mcp

The endpoint is read-only and does not require authentication.

The public Pinterest URL validation guide explains the validation and normalization boundaries used by the tools.

Docker

Build and run the server as a local stdio container:

docker build -t savepinner-mcp .
docker run --rm -i savepinner-mcp

The runtime image executes as the unprivileged node user and does not require secrets, volumes, or network access.

Example

Calling parse_pinterest_url with:

https://de.pinterest.com/pin/987654321/?utm_source=share

returns:

{
  "kind": "pin",
  "originalUrl": "https://de.pinterest.com/pin/987654321/?utm_source=share",
  "normalizedUrl": "https://www.pinterest.com/pin/987654321/",
  "host": "de.pinterest.com",
  "pinId": "987654321"
}

Privacy and safety

  • URL processing is local to the running server.

  • The tools do not make outbound network requests.

  • The server does not download media.

  • Hostnames are checked against an exact Pinterest domain allow list.

  • Lookalike domains and non-HTTPS URLs are rejected.

The URL parser is provided by pinterest-url-normalizer.

This project is maintained by the team behind the Pinterest image downloader, a browser tool for inspecting media exposed by public Pinterest Pin URLs.

Pinterest is a trademark of Pinterest, Inc. This project is independent and is not affiliated with or endorsed by Pinterest.

Development

npm install
npm test
npm run worker:check

License

MIT

Connection diagnostics

Use the connection diagnostic guide to check transport, tool discovery, normalization and deceptive-host rejection before investigating media availability.

Available Tools

3 tools
is_pinterest_urlValidate Pinterest URLA
Read-onlyIdempotent

Return whether a value is a supported Pinterest URL without making a network request.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesA complete Pinterest or pin.it URL

Output Schema

ParametersJSON Schema
NameRequiredDescription
isPinterestUrlYes

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat those. It adds useful behavioral context by stating 'without making a network request,' which is not captured in the annotations. This conveys a key runtime behavior that helps the agent understand the tool's cost and side-effect profile.

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, compact sentence that front-loads the primary behavior ('Return whether') and adds a key qualifier ('supported Pinterest URL') and a constraint ('without making a network request'). Every word earns its place; no wasted or redundant phrasing.

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?

For a simple boolean validator with one parameter, the description is complete. It explains the core behavior, and the annotations cover safety and idempotency. An output schema exists, so return-value details are not needed. The tool's simplicity means no additional context is necessary for correct invocation.

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?

The schema has 100% description coverage for the 'url' parameter ('A complete Pinterest or pin.it URL'), so the baseline is 3. The description adds no further parameter semantics, but since the schema fully documents the single parameter, this is sufficient. No gap exists that the description must fill.

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's function: 'Return whether a value is a supported Pinterest URL.' This is a specific verb+resource combination that distinguishes it from sibling tools like parse_pinterest_url and normalize_pinterest_url, which perform different operations.

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?

The description provides clear context for when to use this tool: 'without making a network request' suggests it is a lightweight, local validation. While it does not explicitly name alternatives, this context differentiates it from parsing or normalizing, which are distinct operations. No exclusions are mentioned, but the usage scope is clear.

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

normalize_pinterest_urlNormalize Pinterest URLA
Read-onlyIdempotent

Convert a supported Pinterest URL to its canonical form and remove tracking parameters.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesA complete Pinterest or pin.it URL

Output Schema

ParametersJSON Schema
NameRequiredDescription
normalizedUrlYes

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail beyond those annotations by specifying that the tool removes tracking parameters and produces canonical form, which clarifies exactly what transformation occurs.

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, front-loaded sentence that clearly states the tool's purpose and effect with zero wasted words. It is concise, scannable, and all information is relevant.

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?

For a simple, single-parameter transformation tool with rich annotations and an output schema, the description is complete. It explains what the tool does, satisfies the behavioral expectations, and does not need to elaborate on return values because the output schema is already provided.

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?

The schema already documents the single 'url' parameter with 100% coverage, including the requirement that it be a complete Pinterest or pin.it URL. The description adds a hint about 'supported' URLs but does not significantly extend beyond the schema-provided meaning, so a baseline score of 3 is appropriate.

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's function: converting a supported Pinterest URL to canonical form and removing tracking parameters. This specific verb+resource combination distinguishes it from siblings like parse_pinterest_url and is_pinterest_url, which have different purposes.

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 when to use the tool (when you need a canonical Pinterest URL without tracking parameters) but does not explicitly mention when not to use it or name alternative sibling tools. The context is clear but lacks direct exclusions or comparison to parse_pinterest_url or is_pinterest_url.

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

parse_pinterest_urlParse Pinterest URLA
Read-onlyIdempotent

Parse a Pinterest URL and return its kind, canonical URL, host, and type-specific identifiers.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesA complete Pinterest or pin.it URL

Output Schema

ParametersJSON Schema
NameRequiredDescription
hostYes
kindYes
pinIdNo
ideaIdNo
ideaSlugNo
usernameNo
boardSlugNo
shortcodeNo
originalUrlYes
normalizedUrlYes

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already identify the operation as read-only, idempotent, and non-destructive. The description adds behavioral detail about the return payload (kind, canonical URL, host, identifiers), which is helpful. No side effects or auth requirements are relevant given the read-only nature.

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, well-structured sentence that leads with the action and resource, then lists the outputs. There is no redundant wording or unnecessary filler.

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?

With one simple parameter, a clear description, complete annotations, and an output schema, the description covers everything necessary for an agent to select and invoke the tool. The return values are enumerated, and the output schema can provide further structural detail.

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 description coverage is 100%—the 'url' parameter is described as 'A complete Pinterest or pin.it URL'. The tool description adds no further parameter detail beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 a specific verb ('Parse') and resource ('Pinterest URL') and enumerates the outputs (kind, canonical URL, host, and type-specific identifiers). This differentiates it from sibling tools like is_pinterest_url (a boolean check) and normalize_pinterest_url (canonicalization).

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—use this when you need structured components from a Pinterest URL—but it does not explicitly name alternatives or state when not to use it. The sibling tools are visible, but no direct comparison is 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.

  1. 3 tool updatesv0.1.0
    • First observedis_pinterest_url
    • First observednormalize_pinterest_url
    • First observedparse_pinterest_url
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool serves a distinct purpose: one parses URLs, one normalizes them, and one validates them as Pinterest URLs. There is no overlap or ambiguity in their roles.

Naming Consistency5/5

All tool names follow a consistent verb_object pattern: parse_pinterest_url, normalize_pinterest_url, is_pinterest_url. The pattern is predictable and uniform.

Tool Count5/5

Three tools is exactly right for a focused URL utility server. Each tool addresses a specific need without clutter or redundancy.

Completeness5/5

The tool set covers the core operations for Pinterest URL handling: validation, parsing, and normalization. There are no obvious gaps for this narrow domain.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers