pinterest-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Each convenience tool targets a distinct Pinterest resource (create pin, pin analytics, search pins, list boards, list pins, get account), and list_operations/call form a clear discovery/execution pair. The only soft spot is that pinterest_call can also perform operations that have dedicated wrappers, so an agent must decide between the generic and specific path.
Naming Consistency4/5
Tool names use a consistent pinterest_ + verb + noun pattern in snake_case, such as create_pin, list_boards, and get_pin_analytics. Minor inconsistencies exist: pinterest_call lacks a target noun, and search_my_pins mixes a possessive modifier while similar tools don't.
Tool Count5/5
Eight tools is a compact, well-scoped set for a Pinterest server. The design intentionally avoids hundreds of individual tools by providing pinterest_list_operations and pinterest_call as a generic discovery/execution pair.
Completeness5/5
The server exposes 263 of 266 Pinterest API operations through pinterest_call, making the surface nearly exhaustive. Convenience wrappers cover common pin, board, and account workflows, while pinterest_list_operations prevents dead ends by enabling operation discovery.
Average 2.9/5 across 8 of 8 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations and the description reveals no behavioral details such as side effects, required permissions, or return format. It is completely silent on what happens when the tool is called.
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 description is extremely short but is not a well-formed sentence and lacks a verb. It sacrifices clarity for brevity, so it does not effectively earn its place.
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?
With no parameters or output schema, the description is the only source of information. It fails to explain what the tool does or what it returns, leaving the agent completely in the dark about the tool's function.
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?
The tool has zero parameters and the schema coverage is 100%, so the baseline of 4 applies. No parameter descriptions are needed because there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is a noun phrase ('The authenticated Pinterest account.') with no verb, so it does not clearly state what the tool does. It fails to distinguish this tool from siblings like pinterest_list_boards or pinterest_get_pin_analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling tools. The description offers no context about its intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral aspects. It does not mention whether this operation is read-only, any rate limits, or potential side effects. This lack of transparency is a significant gap.
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 very concise and straightforward, consisting of a single sentence. It is appropriately short and focuses on the core purpose without extraneous text, though it lacks detailed structure.
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?
Given the low schema coverage and missing parameter explanations, the description is far from complete. It does not provide enough context for an agent to understand how to use the tool effectively, including pagination via bookmark, filtering via pin_filter, or page_size limits.
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?
The schema defines three parameters (bookmark, page_size, pin_filter) but provides no descriptions. The tool description does not explain what these parameters control or how they affect results. With zero schema coverage and no compensation in the description, parameter semantics are entirely unexplained.
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 resource (pins) and the scope (belonging to the authenticated account), which conveys the primary purpose. However, it does not explicitly distinguish this from sibling tools like pinterest_search_my_pins, so it does not fully achieve a perfect score.
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?
There is no guidance on when to use this tool versus alternatives such as pinterest_search_my_pins or pinterest_list_boards. The description simply states what it does without any contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses that ad_account_id defaults from an environment variable, but it does not explain that this tool may perform reads or mutations across many different operations, nor any side effects, authentication requirements, or failure behavior.
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 very short with no filler; both sentences contribute information. It is under-specified, but the conciseness itself is appropriate and the most important operational detail is front-loaded.
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 generic dispatch tool with no output schema, no annotations, and three barely documented parameters, the description is severely incomplete. It does not tell the agent how to obtain valid operation ids, how body/params should be shaped, what the response looks like, or when the generic tool should be preferred over the sibling-specific tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for the schema's lack of parameter documentation. It adds some meaning by explaining the ad_account_id default behavior, but operation_id, body, and params are left essentially undefined beyond the raw schema.
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 states a clear verb and resource: call any Pinterest operation by id. This implies a generic dispatcher distinct from the specific sibling operations, though it does not explicitly name those siblings or define what an operation id is.
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?
The description gives no guidance on when to use this tool instead of the specialized Pinterest tools, nor does it mention that available operation ids can be discovered via pinterest_list_operations. The ad_account_id environment fallback is useful but does not constitute usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden, and it does contribute one meaningful trait: the tool is scoped to the authenticated account's own boards. However, it does not disclose pagination behavior (despite the bookmark parameter), whether secret or protected boards appear by default, ordering, or response shape. The single scoping disclosure is useful, but the behavioral picture is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description has zero wasted words and is efficiently scoped, but at six words it is under-sized for a tool with a privacy filter, pagination cursor, and page size control. This reads more as under-specification than as deliberate, high-value conciseness.
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?
For a tool with no annotations and no output schema, the description is incomplete. It omits default privacy behavior, how pagination via bookmark works, and any indication of what the response contains. A listing tool with a cursor parameter and an enum filter needs more than a scope statement to be invoked correctly and confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only bookmark is documented), and the description adds nothing about privacy or page_size. The privacy enum values and page_size are partially inferable from their names and constraints, but the description does not compensate for the low coverage. Two of three parameters remain effectively undocumented by both the schema and the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (boards) and scope (authenticated account), which makes the intent reasonably clear when read alongside the tool name. However, it is a noun phrase with no explicit verb, so it describes a result set rather than the action. It does not explicitly differentiate itself from siblings like list_pins or search_my_pins.
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 is given on when to use this tool versus siblings such as pinterest_list_pins or pinterest_search_my_pins. There is no context, exclusion, or alternative mentioned. An agent must infer the distinction purely from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Reads only' and mentions the MCP_READ_ONLY context, indicating the tool is non-destructive. However, it does not disclose other behavioral traits such as rate limits, authentication requirements, or error behaviors. Since no annotations are provided, the description carries the full burden but only partially covers the safety profile.
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 concise sentence that delivers the core purpose without unnecessary fluff. It is well-structured and easy to parse, though it could include a bit more detail without becoming verbose.
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?
The description lacks important context such as the format of the analytical response, whether the tool returns a single aggregate or time-series data, and how to interpret the output. This leaves significant gaps for an agent attempting to invoke the tool effectively.
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 provides descriptions for start_date, end_date, and metric_types, while pin_id has no description but its meaning is immediately inferable. With 75% schema coverage, the baseline is 3, and the description adds no extra semantic clarity beyond what the schema already offers.
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 that the tool provides pin performance analytics ('How a pin has performed'), which distinguishes it from general pin creation or listing tools. However, it lacks specifics about which metrics are included, but the core purpose is understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternative pin-related tools like search or list. The description does not mention prerequisites, intended use cases, or conditions that would favor this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals only the scope ('your own pins') and search-by-term behavior, but says nothing about pagination, match criteria, result shape, or any side effects. For a search tool this is a meaningful gap.
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 clear sentence with no filler or repeated information. It is appropriately brief and front-loads the core action, though the brevity contributes to missing contextual detail.
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?
For a tool with 3 parameters, no output schema, and no annotations, the description is too thin. It explains the high-level purpose but omits necessary context about pagination, parameter behavior, and what a response might contain, leaving an agent to guess at invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for undocumented parameters. It adds meaning only to the query parameter via 'by term', while bookmark and page_size remain unexplained. This is only partial compensation.
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 action ('Search'), the resource ('your own pins'), and the qualifying condition ('by term'). This distinguishes it from a plain listing operation like pinterest_list_pins, though it does not explicitly name a sibling alternative.
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 the use case: when the user wants to find their own pins matching a term. However, it provides no explicit guidance about when not to use this tool or how it compares to alternatives such as pinterest_list_pins.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses meaningful behavioral constraints: 263 of 266 operations are reachable, and 131 advertising operations need an ad account. It does not explicitly say the tool is read-only or describe the three missing operations, but 'browse' and 'find an operation id' imply a non-mutating discovery role.
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 tight sentences with no filler. The purpose is front-loaded, and the usage guidance is immediately actionable. Every clause adds useful context.
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?
The description is adequate for basic use: it explains what the tool does, why it exists, and the ad-account prerequisite. But with no output schema and no annotations, important gaps remain: the return shape is not described, 'include_excluded' is unexplained, and the three unreachable operations are not identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: 'search' has a description, but 'include_excluded' has none. The tool description simply repeats the schema text for 'search' and adds no meaning for the undocumented boolean parameter, so it fails to compensate for the coverage gap.
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?
States a specific action ('Browse the Pinterest API') and a concrete outcome: 'Use this to find an operation id for pinterest_call.' It also distinguishes the advertising operations from the organic surface, making the tool's role clear relative to its siblings.
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 explicitly tells the agent when to use the tool: to find an operation id for pinterest_call. It also gives useful context that 131 advertising operations require an ad account. However, it does not explicitly state when NOT to use it or how it compares to directly using sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It usefully explains that Pinterest fetches the image server-side and that local file paths will not work, which is a non-obvious behavioral trait and common failure point. It does not cover permissions or response behavior, but the key operational trap is disclosed.
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 wasted words. The action is front-loaded, and the essential constraint about public URLs is placed immediately after.
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 creation tool, the description communicates what is being created and the most important prerequisite for successful invocation. It does not describe the return value, but with no output schema and a fairly self-explanatory create operation, the missing return info is a minor gap.
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 description adds critical meaning for image_url by requiring a publicly reachable URL. However, schema description coverage is only 43%, and the description does not clarify ambiguous parameters like board_section_id or further explain title, description, and link semantics beyond what the schema already provides.
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 opens with a specific verb and resource: 'Create a pin on one of your boards.' This clearly identifies the action and distinguishes it from sibling read/list tools like pinterest_list_pins or pinterest_get_pin_analytics.
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 establishes clear usage context — you use this when creating a pin on an owned board. It does not explicitly name alternatives or when-not-to-use cases, but the creation intent is unambiguous against the read/search/list siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pinterest-mcp-server MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/N-Graves/pinterest-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/N-Graves/pinterest-mcp-server)

Score Badge

Copy to your README.md:

[![pinterest-mcp-server MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/N-Graves/pinterest-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/N-Graves/pinterest-mcp-server)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![pinterest-mcp-server MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2FN-Graves%2Fpinterest-mcp-server%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/N-Graves/pinterest-mcp-server)

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/N-Graves/pinterest-mcp-server'

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