Skip to main content
Glama

PostWire

Plan and schedule a week of posts

plan_week
Destructive

Writes one post per day for 1 to 7 days from a single topic, each day from a different angle and each platform in its own native format, and queues them to be published publicly at the given hour on each day starting tomorrow, through the connected accounts. Text only: platforms that require a video or photo (TikTok, YouTube, Instagram) are refused. Every platform must already be connected. Each day counts as one AI draft toward the daily AI limit. Days that do not fit in the plan's monthly post limit are saved as held (never published on the current plan) and are scheduled automatically when the plan is upgraded; the result then also gives that plan, its price and a checkout link. Returns the queued and held items with their id, time and a preview of each platform's text; any of them can be canceled before it runs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoHow many days, starting tomorrow. Default 5.
hourNoHour of the day to publish, on the timezone's clock. Default 10.
topicYesWhat the week is about, e.g. "our new autumn menu and the farmers behind it".
brand_idNoBrand whose accounts to use; omit for the default brand.
timezoneNoIANA timezone of that hour, e.g. "America/Lima". Default UTC.
platformsYesText-capable platforms to post to each day, e.g. ["linkedin","bluesky"].
brand_voiceNoOptional tone or style notes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=true), the description discloses extensive behavioral traits: posts are published publicly, each day counts toward an AI limit, days exceeding the monthly post limit become 'held' and auto-schedule on upgrade (with pricing/checkout returned), and queued items can be canceled. These details give the agent a realistic expectation of side effects and resource costs.

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 description is a single dense paragraph but front-loads the core action and packs every sentence with relevant facts (refusals, connection requirement, AI limit, held-item handling, return format, cancellation). It is not padded, though breaking it into structured points would improve readability further.

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?

With no output schema, the description fully covers what the tool returns (queued and held items with id, time, preview) and explains the upgrade behavior and cancellation option. It covers prerequisites, constraints, side effects, and limits, leaving nothing essential missing for an agent to call and interpret the tool correctly.

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%, but the description adds semantic value beyond the schema. It clarifies that 'platforms' excludes video/photo-required options (TikTok, YouTube, Instagram) despite being in the enum, and explains that 'days' interacts with monthly post limits (excess becomes held). This goes beyond basic type/range 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 the tool's action (writes and queues posts), its resource (one post per day for 1-7 days across multiple platforms), and its scope (published publicly starting tomorrow). It also distinguishes itself from siblings by explicitly refusing video/photo-required platforms, making its purpose 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?

The description provides a key prerequisite ('Every platform must already be connected') and a constraint ('Text only: platforms that require a video or photo are refused'), which helps agents decide when this tool is appropriate. However, it never mentions alternative tools or explicitly states when not to use it (e.g., when video content is needed), leaving that inference to the agent.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.