pinterest-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action: single-item reads (pin, board, user), list operations (boards, pins), analytics, and creation (board, pin). The descriptions clarify use cases, e.g., list_boards for finding board_id before create_pin, so there is no real ambiguity.
Naming Consistency5/5
All tools follow the same 'pinterest_{verb}_{noun}' pattern with lowercase snake_case. Verbs are consistently get, list, or create, and nouns are clear resources. No mixed conventions or vague names.
Tool Count5/5
Eight tools is well-scoped for a Pinterest management server. It covers authentication check, reading user/boards/pins, analytics, and creating boards/pins—enough to perform the advertised workflow without redundancy or bloat.
Completeness4/5
The set covers the core workflow: list boards to get IDs, create boards and pins, fetch pin data, and retrieve analytics. Missing update/delete operations are a minor gap, but the described use case (publishing live pins and measuring traffic) is fully supported.
Average 4.3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey safety traits. It adds 'Safe read', indicating a read-only operation, which is helpful. But it omits other behavioral details like error handling, permissions, or return format, leaving the full burden partially unmet.
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 extremely concise, consisting of two short sentences that front-load the primary action. Every word contributes value, with no redundancy or filler.
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?
This is a simple single-parameter tool with no output schema or annotations. The description explains its core function adequately. It could be more complete by detailing what 'details' include, but the minimal complexity makes this 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 schema already fully describes pin_id as 'The pin id' (100% coverage). The description's 'by id' reinforces the parameter but adds no new meaning beyond the schema, 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 'Fetch one pin's details by id' uses a specific verb and resource, clearly indicating the tool fetches a single pin's data. The phrase 'one pin' distinguishes it from sibling tools like list_pins and 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single pin by ID, which contrasts with listing all pins. However, it does not explicitly mention when to use this tool over alternatives or provide exclusions, so guidance is implicit rather than explicit.
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?
No annotations are provided, so the description bears the full burden. 'Safe read' discloses the non-destructive nature, which is valuable. However, it does not describe what specific details are returned, error behavior, or any other behavioral traits, leaving some ambiguity.
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 extremely concise: two short phrases that convey the essential purpose and safety. Every word is functional, with no redundancy or fluff.
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 single-parameter, read-only getter, the description sufficiently covers the operation. While it lacks detail on the return payload, the phrase 'board's details' implies the core output. The absence of an output schema is not critical given the straightforward nature of the 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?
The schema has 100% coverage with 'The board id' for the single parameter. The description adds no additional format, type constraints, or usage notes, but with full schema coverage the baseline 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 action ('Fetch'), the resource ('one board's details'), and the method ('by id'). It distinguishes itself from sibling tools like list_boards, which retrieves multiple boards, and get_pin, which targets a different resource.
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 implies the use case: when you have a specific board ID and need that board's details. It provides clear context but does not explicitly mention alternatives or when not to use this tool, which is acceptable for a simple singleton getter.
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 full burden of behavioral disclosure. It states 'Safe read' and 'paginated', which are valuable safety and behavior traits, but it doesn't cover auth requirements, rate limits, or output details beyond the board_id hint. This is adequate but not rich.
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 two sentences long, with the first sentence immediately stating the purpose and the second providing usage guidance. Every word earns its place, and it is front-loaded and easy to scan.
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 simple list tool with two optional params and no output schema, the description covers the core purpose, safety, pagination, and use case. It doesn't spell out the exact response fields, but the board_id reference gives enough context for an agent to infer the return shape.
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%, so the parameters (bookmark, page_size) are already fully described. The description adds no extra meaning to the parameters; it only repeats 'paginated' which is redundant. Baseline of 3 is appropriate when the schema does the heavy lifting.
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 'List the account's boards' with a specific verb and resource, distinguishing it from siblings like pinterest_get_board (singular) and pinterest_list_pins. It also mentions pagination, which is implied by the tool's name but reinforced in the description.
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?
It explicitly says 'Use before creating a pin to find the board_id you want to pin to — the create-pin call needs it', which gives a concrete when-to-use scenario. It doesn't explicitly state when not to use it, but the guidance is clear enough for an agent to decide between this and alternatives.
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 provided, the description carries the full burden. 'Safe read' explicitly signals a non-mutating operation, and 'optionally scoped' explains scoping behavior. It does not cover pagination details, but the schema already documents the bookmark parameter, and for a read-only list tool this level of disclosure is adequate.
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 short, front-loaded sentences. Every word adds value: the core behavior, the optional scoping, and a safety hint. No filler or repetition.
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 straightforward listing tool with only optional parameters and no output schema, the description is nearly complete. It conveys the resource type, scoping possibility, and safe-read nature. It does not spell out the return structure, but 'List pins' makes it evident.
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% (all three parameters have descriptions), so the baseline is 3. The description adds meaningful context for board_id ('optionally scoped to a single board') but adds nothing for bookmark or page_size beyond their schema descriptions.
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 action ('List pins') and a resource ('the account'), optionally scoped by board_id. This distinctly differentiates it from siblings like pinterest_get_pin (single pin) and pinterest_list_boards (boards vs pins).
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 phrase 'List pins on the account' implies general listing, and 'optionally scoped to a single board via board_id' gives conditional usage. It does not explicitly name alternatives, but the sibling set and the verb 'list' make the use case clear for enumerating 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?
With no annotations provided, the description carries the full burden. It explicitly states 'Safe read' and that it works on 'one of our own pins,' which discloses the ownership requirement and read-only nature. It doesn't detail rate limits, error conditions, or return format, but for a simple analytics read, the provided transparency is above average.
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, no waste. The first sentence front-loads the core purpose, the second adds a crucial usage context. Every phrase 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?
Given the tool's simplicity and 100% schema coverage, the description covers purpose, safety, and a key usage context. However, it lacks a description of the return shape (e.g., a list of metric-value pairs), which matters since there is no output schema. Still, the overall completeness is high for a read-only analytics tool.
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 description coverage is 100%, so the baseline is 3. The description adds meaningful semantics by listing the exact default metrics (impressions, saves, pin clicks, outbound clicks, video views) and explaining the significance of outbound clicks in the Etsy context. This goes beyond the schema's bare parameter names.
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 returns engagement metrics (impressions, saves, pin clicks, outbound clicks, video views) for a single owned pin, distinguishing it from sibling tools like get_pin (which likely returns pin details) and list_pins. The verb is implied ('get') but the resource and scope are specific.
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 gives context on when to use the tool: to measure native Etsy-driver traffic via outbound clicks, which is the traffic-lever signal. It doesn't explicitly state exclusions or alternatives, but the sibling list is limited and the analytics-focused purpose is clear. This is more than implied usage; it's a strong contextual cue.
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 full burden. It explicitly states 'Safe read', which is a key behavioral trait. It also specifies the returned data fields. While it does not cover potential errors or prerequisites, it is adequate for a simple read-only tool.
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 two sentences, each serving a clear purpose: what the tool does and when to use it. No unnecessary words or repetition.
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 no-parameter, no-output-schema tool, the description fully explains the return values (username, id, account type) and provides a use case. It is complete for the tool's simplicity.
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, so the schema is empty. Per guidelines, a baseline score of 4 applies. No additional parameter explanation is needed.
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 with a specific verb ('Get') and resource ('current Pinterest account's basic info'), naming the exact fields returned (username, id, account type). It is distinct from sibling tools like get_pin or list_boards, which operate on different resources.
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 gives explicit guidance on when to use the tool ('before any write' to confirm credentials). It does not mention alternatives or when not to use it, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses live visibility ('Live, immediately visible on the profile if privacy=PUBLIC'), authorization requirements ('agent_id must hold social'), and failure conditions ('or the call is refused'). These go far beyond the schema and give the agent critical behavioral expectations.
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 two sentences, front-loaded with the primary purpose, and includes only high-value details about visibility, prerequisites, and failure. No waste.
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 5-parameter tool with no annotations or output schema, it covers purpose, prerequisites, side effects, and refusal behavior. It does not mention the return value, but given the lack of output schema, this is a minor gap rather than a critical omission.
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 100%, so baseline is 3. The description adds meaning for agent_id by specifying it must hold 'social' permission, and clarifies the consequence of task_id requirements. It does not repeat all parameters but enriches two key ones.
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 new Pinterest board on the account.' This clearly distinguishes it from sibling tools like pinterest_create_pin, and the read-only tools (get/list). No ambiguity about what the tool does.
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?
It provides clear context for when to use the tool by stating prerequisites: 'Requires agent_id (must hold 'social') and task_id (task must be cleared for the with_nate brand — Done and carrying an approved output).' It does not explicitly name alternatives or exclusion criteria, but the purpose and requirements make usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It reveals that the pin is immediately live, has no draft state, requires specific permissions, demands a public http(s) image URL (local files fail), and warns about click-through analytics depending on the 'link' field. This goes well beyond a generic 'creates a pin' statement.
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 three focused sentences, each carrying necessary information: what the tool does, prerequisites, and critical constraints. It is front-loaded with the main action and avoids redundancy or filler, making it easy to scan.
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?
Despite having 8 parameters, no output schema, and no annotations, the description covers the core purpose, prerequisites, key parameter constraints, and success semantics ('once this returns success, the pin is on the account'). This is sufficient for an agent to invoke the tool correctly without needing additional context.
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 descriptions already cover 100% of parameters, so baseline is 3. The description adds marginal value by emphasizing the 'social' permission requirement for agent_id (not in schema) and reasserting the live-pin consequence. It mostly echoes schema details for image_url and link, but the added prerequisite justifies a score above baseline.
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 'Publish a real, immediately-live pin to one of our boards,' which uses a specific verb ('publish') and resource ('pin') while also indicating the scope ('to one of our boards'). This clearly distinguishes it from sibling read/list tools and the separate pinterest_create_board tool.
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 explicit prerequisites: agent_id must hold 'social' and task_id must be cleared for with_nate. It also states the 'no draft state' behavior and directs the 'link' field to the destination URL, giving practical usage context. It does not explicitly name alternative tools, but the conditions and examples imply when this tool is appropriate.
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 MCP server](https://glama.ai/mcp/servers/N-Graves/pinterest-mcp/badges/card.svg)](https://glama.ai/mcp/servers/N-Graves/pinterest-mcp)

Score Badge

Copy to your README.md:

[![pinterest-mcp MCP server](https://glama.ai/mcp/servers/N-Graves/pinterest-mcp/badges/score.svg)](https://glama.ai/mcp/servers/N-Graves/pinterest-mcp)

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'

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