Skip to main content
Glama

Best times to post

get_best_times
Read-onlyIdempotent

The best hours of the week to post, for each account of a workspace, with the next times they come round (ready for schedule_at). Each account is timed for its own audience: one country, several, the whole world, or a time zone — from this request (countries, world, timezone), else the account's market, else its groups' markets together (set_audience), else where its clicks come from, else the workspace's zone; audience says which and how each country is weighed. One market is read on its own clock; several markets on UTC, with each hour also given in every market's local time, so a worldwide group gets the hours that reach most of its audience. A worldwide audience with no clicks yet is weighed by an assumed mix (audience.assumed_mix). Every source Shager has comes back, most specific first, and best is the first with enough data: account_posts (the account's own posts of the last year, scored by likes, comments, shares, saves and clicks against its typical post; needs 12 measured posts), audience_clicks (when its audience clicked the posts' short links; 50 clicks, else workspace_clicks), shager_country (when people in each of its countries click Shager short links across all customers: counts per hour only, a country only above 500 clicks from 5 workspaces in 90 days), and study (Buffer's 2026 study of millions of posts per network, read in each market's local time; none for Pinterest, Bluesky, Telegram, Mastodon or Google Business). missing says why a more specific source wasn't used. To post at each account's best time without picking it yourself, give create_post, create_posts or schedule_post schedule_at "best": Shager picks every account's next free best time (one post, a delay per account) and says what it picked in best_time.

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": {
      "workspace_id": "<workspace_id>"
    },
    "name": "get_best_times"
  }
}

Input Schema

NameRequiredDescriptionDefault
worldNoTime every listed account for a worldwide audience instead of its own market
formatNoOnly posts of this format count; SHORT also switches YouTube's study hours to Shorts
timezoneNoRead the hours in this IANA zone, e.g. America/New_York, instead of the audience's own
countriesNoTime every listed account for these countries' audience instead of its own market, e.g. ["US","IL"]
group_idsNoOnly the accounts in these groups (from list_groups)
channel_idsNoOnly these accounts (from list_channels)
workspace_idYesWorkspace id from list_workspaces

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses the fallback and data-source behavior in detail: account_posts, audience_clicks, shager_country, and study, including thresholds like 12 measured posts and 50 clicks. It also explains how 'missing' reports why a more specific source was not used.

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 purpose is front-loaded in the first sentence, and nearly every subsequent clause carries operational detail. However, the description is a dense, semicolon-heavy paragraph that would be easier to parse if structured into shorter sections.

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?

Although there is no output schema, the description explains the important return concepts: the best source, the 'missing' explanation, the next times, and how each account's audience is resolved. For a complex seven-parameter read tool, this is sufficiently complete to call it 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%, so the baseline is 3, but the description adds meaningful semantics for countries, world, and timezone by explaining the audience-resolution chain and local-vs-UTC clock behavior. It does not explain format or group/channel filtering beyond the schema, but it meaningfully enriches the most consequential parameters.

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 opens with a specific verb and resource: 'The best hours of the week to post, for each account of a workspace,' and adds the key output detail that next times are 'ready for schedule_at'. It is clearly distinguishable from analytics-oriented siblings like get_analytics or get_insights.

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?

It gives a clear operational connection to alternatives by explaining that passing schedule_at='best' to create_post, create_posts, or schedule_post lets Shager pick times automatically. It does not state explicit when-not-to-use conditions, but the intended use case is clear.

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.

Resources