Skip to main content
Glama
aymandakirgh

pinterest-mcp

by aymandakirgh

Delete board section

pinterest_delete_board_section
DestructiveIdempotent

Delete a Pinterest board section while keeping its pins; they move to the board root instead of being removed. Requires boards:write scope.

Instructions

Delete a board section. Pins in the section move back to the board root rather than being deleted. Scope: boards:write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
board_idYes
section_idYes
ad_account_idNoAct on behalf of this ad account. Required only for business accounts operating on a shared asset.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds the non-obvious consequence that pins are not deleted but moved to the board root. It also names the required scope (boards:write), which is valuable auth context beyond annotations.

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 short sentences, front-loaded with the action, then the side effect, then the scope requirement. Every sentence earns its place with no redundancy.

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?

Covers the operation, the side effect on pins, and the required scope. No output schema exists, but the return isn't needed because the operation is a delete. It stops short of noting prerequisites like auth or whether the board must be owned, but is largely complete for a destructive 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 only 33%, with board_id and section_id undocumented in the schema, but their names and required status make their purpose inferable. The description adds no parameter syntax or format details, and the optional ad_account_id has schema description coverage. Marginal value beyond 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?

States a specific verb+resource ('Delete a board section') that clearly identifies the operation and distinguishes it from sibling tools like delete_board or delete_pin. It doesn't explicitly name a sibling alternative, but the resource is unambiguous.

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?

Implied usage from the verb and resource, and the note about pins moving to board root gives useful post-condition context. However, no explicit when-to-use vs. alternatives (e.g., update_board_section, delete_board) is provided.

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