Tailwind App

set_pin_spacing_rule

DestructiveIdempotent

Use this when the user wants Pins to the same destination URL kept further apart (or closer together), or before scheduling many Pins to one URL with useNextOpenSlot when the account has no rule for it: creates or replaces a Pin Spacing rule, the minimum number of days Tailwind keeps between scheduled Pins sharing a URL. Free, as in the dashboard.

ruleType DEFAULT sets the account-wide rule, which applies to EVERY URL on the account that has no rule of its own; say so to the user and confirm before changing it. ruleType CUSTOM sets the rule for one url and needs url; it overrides the default for that URL. URLs match regardless of http/https and trailing slashes. A linked URL follows its base URL's rule, so a CUSTOM write through a linked URL changes the base URL's rule, which also governs every URL linked to it; linkedToUrl names that base.

Only Pins scheduled after this call are spaced by the new rule. This call does not move Pins already on the schedule; respacing them happens in the Tailwind dashboard, and a later respace or shuffle there applies the new rule to them. Call get_pin_spacing_rule first when you need to know what a URL follows today. 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>",
      "spacing": "<spacing>"
    },
    "name": "set_pin_spacing_rule"
  }
}

Input Schema

Name	Required	Description
`url`	No	CUSTOM only, and required for it: the Pin destination URL, the same value create_post takes as url. Omit for DEFAULT.
`spacing`	Yes	Whole days between Pins to the URL, 1 to 365. Tailwind recommends at least 7. Ask the user rather than guessing.
`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
`rule`	Yes
`linkedToUrl`	Yes	CUSTOM only: the base URL whose rule was changed when url is a linked URL; null otherwise
`previousSpacing`	Yes	The spacing this rule replaced; null when there was no rule of this type before

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that only Pins scheduled after the call are affected and existing scheduled Pins are NOT moved, that the dashboard is where respacing happens, that the operation is free, and that linked URLs inherit their base URL's rule. The destructive/replace semantics in the annotations are explained in concrete terms, including a warning to confirm before changing the account-wide DEFAULT rule.

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?

Front-loaded with the triggering condition and the core action before the branching ruleType details. Dense but each sentence carries operational content; the only mild redundancy is the repeated 'say so to the user and confirm' framing around the DEFAULT rule.

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?

Covers everything an agent needs for a mutation tool: prerequisites, account disambiguation, DEFAULT vs CUSTOM scope and blast radius, URL normalization, linked-URL inheritance, and the temporal limitation on which Pins are affected. Output schema exists, so return values need no 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 semantics the schema does not: DEFAULT applies to every URL lacking its own rule, CUSTOM overrides for one URL, URLs match regardless of http/https and trailing slashes, and linkedToUrl identifies the base URL whose rule is actually changed.

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?

Opens with a specific verb and resource: 'creates or replaces a Pin Spacing rule, the minimum number of days Tailwind keeps between scheduled Pins sharing a URL.' It is clearly distinguishable from get_pin_spacing_rule, list_pin_spacing_rules and delete_pin_spacing_rule, which are the only similarly named siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit about when to use it ('user wants Pins to the same destination URL kept further apart', or before scheduling many Pins to one URL with useNextOpenSlot when no rule exists), names the read-side alternative (get_pin_spacing_rule first), and adds a pre-call disambiguation step for account selection via list_accounts.

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?