Skip to main content
Glama
posterly-mcp-server

posterly-mcp-server

by awpthorp

list_publishing_pauses

Read-onlyIdempotent

Check whether publishing is paused in a workspace, see which visible brands are paused, and confirm if you can pause, resume, or publish missed posts. Read-only.

Instructions

Is publishing paused? Shows whether the workspace is paused, which brands are paused (only brands you can see), and whether you may pause, resume, or publish missed posts. Read-only. Change it with manage_publishing_pause.

Input Schema

NameRequiredDescriptionDefault
workspace_idNoWorkspace ID from whoami. Defaults to your default workspace.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.55.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered; the description still adds meaningful behavior beyond them: result scoping ('only brands you can see') and the fact that the response includes capability flags for pausing, resuming, and publishing missed posts. It does not describe error or empty-state behavior, so it stops short of 5.

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 tight sentences, front-loaded with the question the agent is likely asking, then the returned information, then the read-only constraint and the mutation alternative. No filler.

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?

There is no output schema, and the description compensates by enumerating what comes back: workspace pause state, per-brand pause state, and permission flags. Combined with the schema's parameter documentation and the annotations' safety profile, an agent has everything needed to call it correctly.

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?

The single workspace_id parameter has 100% schema description coverage, including the 'from whoami' and default-workspace semantics, so the schema carries the load. The description adds nothing about the parameter, which is acceptable at this coverage level but is baseline only.

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 resource plus the exact question it answers: 'Is publishing paused? Shows whether the workspace is paused, which brands are paused... and whether you may pause, resume, or publish missed posts.' It also explicitly separates itself from the mutation sibling manage_publishing_pause, so an agent can choose between them without opening either schema.

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?

Clear routing: this is the read path, and 'Change it with manage_publishing_pause' names the alternative and the condition that selects it. What's missing is any precondition guidance about when the pause state matters (e.g., checking before create_post or before resuming publishing).

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