Tailwind App

rebuild_schedule

Destructive

Use this ONLY when the user has explicitly asked to regenerate their entire posting schedule from scratch: DELETES every SmartSchedule timeslot the account has and generates slotsPerDay new ones on each of the 7 days, spread between 5am and 11pm in the account's timezone. This is the dashboard's "Generate new SmartSchedule" button. Free, but it cannot be undone — the times the user had are gone, including any they set by hand.

Confirm with the user before calling, and tell them their current times will be replaced. Do NOT reach for this to fix a few bad times: to spread a clustered schedule, or to change specific times, use update_timeslot, delete_timeslot and create_timeslot, which leave the rest of the schedule alone. There is no way to ask for a particular part of the day — the generator spreads slots across the whole 5am-11pm window, so it cannot satisfy "mornings only".

Evergreen (SmartLoop) slots are the one exception and survive untouched; everything list_timeslots shows is replaced. Pins already scheduled keep the times they were given and are not deleted. Two rebuilds cannot run at once: a second one while the first is still going is refused, so do not retry on a timeout without checking list_timeslots first. If a rebuild fails outright, call list_timeslots before deciding what to do: the delete and the insert are separate steps, so a failure part-way can leave the account with no posting times at all, and re-running the rebuild is what restores them. 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.

Input Schema

Name	Required	Description	Default
`accountId`	Yes	Numeric Tailwind account ID returned by list_accounts
`slotsPerDay`	Yes	How many posting times to generate per day, 1 to 50. The total becomes this times 7. Ask the user rather than guessing; the dashboard's own default is 5.

Output Schema

Name	Required	Description
`rebuilt`	Yes	Whether the schedule was replaced
`slotsPerDay`	Yes	Slots generated per day
`timeslotCount`	Yes	Total slots the schedule now holds
`timezoneSource`	Yes	user = generated in the account's own timezone; fallback = the account has none set and America/New_York was used, which is worth telling the user

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover destructive/non-idempotent, but the description adds far more: irreversibility including hand-set times, the evergreen SmartLoop exception, pins retaining their times, mutual exclusion of concurrent rebuilds, the refusal-on-timeout behavior, and the partial-failure mode where delete and insert are separate steps leaving the account with no times.

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 gating rule and the destructive effect, then failure modes, then account selection — a sensible ordering. It runs long (~250 words), but nearly every sentence carries non-obvious operational information; only the dashboard-button analogy is expendable.

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 prerequisites, confirmation requirement, exceptions (SmartLoop, pins), concurrency, timeout handling, and recovery after partial failure — everything an agent needs to call this destructive tool safely. Return values are covered by the output schema, so no gap remains.

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 already 100%, so baseline is 3; the description adds real meaning by explaining that slotsPerDay drives a whole-window spread with no way to target a sub-window of the day, and by reinforcing the ask-the-user rule for accountId. It stops short of restating ranges, which the schema already handles.

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 verb and scope ('regenerate their entire posting schedule from scratch'), quantifies the effect (deletes every SmartSchedule timeslot, generates slotsPerDay new ones on each of 7 days between 5am-11pm), and distinguishes itself from update_timeslot/delete_timeslot/create_timeslot by name.

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 gating ('ONLY when the user has explicitly asked'), explicit exclusions ('Do NOT reach for this to fix a few bad times'), named alternatives for those cases, an explicit limitation ('cannot satisfy "mornings only"'), and an account-selection rule when list_accounts returns multiple.

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?