Skip to main content
Glama
gosswerner1-max

LazyRelay MCP Server

resume_post

Idempotent

Reactivate a paused post to publish it again. If its scheduled time has passed, it publishes immediately.

Instructions

Let a paused post go out again. If its time has passed it goes out right away.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe post id, from list_scheduled_posts

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.4

TDQS

A3.8/5.0
Behavior4/5

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

Annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) already establish the mutation and safety profile, so the description clears the lower bar. It adds genuine behavioral detail the annotations do not: a past-due paused post is published immediately rather than waiting for a future slot.

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?

Two short sentences, no filler, with the core action stated first and the timing nuance immediately after. Every sentence earns its place.

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?

For a one-parameter mutation with annotations covering the safety profile and no output schema, the definition supplies enough to call it correctly and tells the agent the key timing behavior. It stops short of describing error cases, such as resuming a post that was never paused.

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?

There is a single parameter with 100% schema description coverage ('The post id, from list_scheduled_posts'), so the schema already carries the semantics and cross-tool sourcing. The description adds nothing about the id, matching the baseline 3 for high-coverage schemas.

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?

The description states a specific verb+resource ('Let a paused post go out again'), clearly framing the inverse of the sibling pause_post. It does not name the sibling explicitly, but the 'paused post' scoping makes the operation 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?

Usage is implied by the word 'paused' — an agent can infer this applies only to posts previously paused via pause_post. There is no explicit when-to-use statement, no mention of what happens when called on a non-paused post, and no named alternative.

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