Skip to main content
Glama
Sign In

Ravenpost

by st.ravenpo
OverviewDiscussionsAdmin

List posting queue slots

list_queue_slots
Read-onlyIdempotent

List the workspace posting schedule: the recurring weekly queue slots (weekday + local time) that action="queue" publishes into, plus nextFreeSlot — the next slot no post is booked into, which is where action="queue" would put a post now (null when there are no slots, or none is free in the weeks ahead). Slots are defined in dashboard Settings and are workspace-wide (shared by every connected account), so each workspace has its own schedule. weekday 0 = Sunday … 6 = Saturday, in the workspace timezone.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_queue_slots"
  }
}

Input Schema

NameRequiredDescriptionDefault
workspaceIdNoWhich workspace to act in — an id from list_workspaces. Optional with a single workspace; REQUIRED once there are several, where guessing would mean posting one client's content to another client's accounts. Ask the user which one before publishing.

Output Schema

NameRequiredDescriptionDefault
slotsNo
nextFreeSlotNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds useful behavior beyond annotations: slots are defined in Settings, shared workspace-wide across connected accounts, nextFreeSlot is null when no slots exist or none is free, and weekday numbering is in the workspace timezone.

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 front-loaded with the core purpose and then adds necessary details about nextFreeSlot, workspace scope, and weekday mapping. It is dense and slightly run-on, but every clause conveys useful scheduling semantics rather than 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?

An output schema exists, so the description need not document return shape. For a read-only tool with one optional parameter, it supplies enough context about workspace scoping, slot semantics, null nextFreeSlot, and weekday/timezone conventions to call and interpret 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?

Schema description coverage is 100%, and the sole parameter workspaceId already has a detailed schema description covering optional/required behavior and the risk of guessing. The tool description reinforces that each workspace has its own schedule, but it does not add new syntax or selection guidance beyond the schema.

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 states a specific verb and resource: it lists the workspace posting schedule, including recurring weekly queue slots and nextFreeSlot. It also clarifies that these are the slots action="queue" publishes into, which distinguishes this tool from generic post-listing or scheduling tools.

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?

The description explains the practical context: how the slots relate to action="queue", that they come from dashboard Settings, and that they are workspace-wide. It does not explicitly name alternative sibling tools or state when not to use this tool, but the usage context is clear.

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

All Ravenpost toolsInspect
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