Skip to main content
Glama
markaestro

Markaestro

Official

Activate an Evergreen queue

activate_evergreen_queue

Activate a draft or paused queue to schedule future public posts; requires confirmed caption variants or returns content review required.

Instructions

Activate a draft or paused queue. This schedules future public posts. The user must have confirmed the caption variants (contentConfirmed on create_evergreen_queue or update_evergreen_queue); otherwise this answers EVERGREEN_CONTENT_REVIEW_REQUIRED.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queueIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.3

TDQS

A3.8/5.0
Behavior4/5

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

Annotations declare the mutation/safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true), and the description adds real context beyond them: activation causes future public posts to be scheduled and is gated on a content-confirmation flag, otherwise returning EVERGREEN_CONTENT_REVIEW_REQUIRED. It still doesn't say whether activation is reversible or how already-scheduled items are affected.

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 short sentences, each carrying distinct payload: the action, the scheduling side effect, and the precondition with its error code. Front-loaded with the operation and free of filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the inline error code and precondition are exactly the kind of detail an agent needs, and the public-post side effect is disclosed. Missing only secondary behavior such as reversibility or interaction with existing scheduled runs.

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 0% and the single parameter queueId is never mentioned in the description, so the description does not compensate for the gap. However, queueId is self-describing and the surrounding prose ('a draft or paused queue') gives the entity context, keeping this at a baseline 3 rather than lower.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Activate a draft or paused queue') and immediately names the effect (scheduling future public posts). It does not, however, distinguish itself from the sibling resume_evergreen_queue, since 'draft or paused' overlaps with what a resume tool would target.

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?

It gives one explicit precondition — caption variants must be confirmed via contentConfirmed on create/update — and the failure code if not. But there is no guidance on when to choose activate versus resume or pause, and no statement of the queue state required beyond 'draft or paused'.

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