Tailwind App

delete_pin_spacing_rule

DestructiveIdempotent

Use this when the user wants to stop spacing Pins by a rule: removes the account's DEFAULT Pin Spacing rule, or the CUSTOM rule that applies to one url. Free. Confirm with the user before calling, and say which rule is going away and what replaces it.

Removing DEFAULT means URLs without a rule of their own are no longer spaced at all; custom rules stay. Removing a CUSTOM rule makes Pins to that URL follow the account default, if there is one. For a linked URL, the CUSTOM rule removed is its base URL's, which also governed the base and every URL linked to it; linkedToUrl names that base. Fails when no rule of that type applies, and a CUSTOM delete never removes the default. This call does not move Pins already on the schedule. If the user did not say which Pinterest account to use and list_accounts returns more than one, ask the user which account to use before calling this — do not choose for them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "accountId": "<accountId>",
      "ruleType": "<ruleType>"
    },
    "name": "delete_pin_spacing_rule"
  }
}

Input Schema

Name	Required	Description
`url`	No	CUSTOM only, and required for it: the destination URL whose rule to remove. Omit for DEFAULT.
`ruleType`	Yes	DEFAULT is the account-wide rule for every URL without its own rule; CUSTOM is the rule for one url
`accountId`	Yes	Numeric Tailwind account ID returned by list_accounts

Output Schema

Name	Required	Description	Default
`deletedRule`	Yes
`linkedToUrl`	Yes	CUSTOM only: the base URL whose rule was changed when url is a linked URL; null otherwise

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare destructive/idempotent/not-readOnly; the description goes well beyond that by spelling out exactly what is destroyed (DEFAULT removal leaves unruled URLs unspaced while custom rules survive), what replaces it (CUSTOM removal falls back to the account default), and that scheduled Pins are not moved. The linked-URL cascade behavior and the failure condition are behavioral facts not available anywhere in the structured fields.

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 intent and the two rule types are front-loaded, and most sentences carry distinct information (replacement behavior, linked-URL scope, no schedule mutation, account disambiguation). It is dense and near the upper bound of useful length, with the account-selection instruction buried at the end rather than alongside the confirmation instruction.

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 destructive three-parameter mutation, the description covers trigger, confirmation protocol, account disambiguation, per-rule-type consequences, cascade behavior, failure mode, and non-effects on the schedule. With an output schema present, it correctly omits return-value explanation.

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 the baseline is 3, but the description adds real semantics: it explains the DEFAULT-vs-CUSTOM consequence chain and that a linked URL's rule is its base URL's rule governing the base and everything linked to it. The mention of 'linkedToUrl names that base' refers to a field absent from the input schema, which is a small source of confusion about whether that is input or output.

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 states a specific verb and resource ('removes the account's DEFAULT Pin Spacing rule, or the CUSTOM rule that applies to one url') and immediately frames it as the inverse of setting a rule. An agent can distinguish it from set_pin_spacing_rule, get_pin_spacing_rule, and list_pin_spacing_rules from the first sentence alone.

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?

Strong when-to-use guidance: it names the user intent ('stop spacing Pins by a rule'), requires confirmation before calling, tells the agent to ask which account when list_accounts returns multiple, and warns it fails when no rule of that type applies. It never explicitly names set_pin_spacing_rule as the alternative for the opposite operation, so routing is inferred rather than stated.

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

All Tailwind App tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?