Skip to main content
Glama
gosswerner1-max

LazyRelay MCP Server

by gosswerner1-max
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

list_scheduled_posts

Read-onlyIdempotent

List upcoming and recent posts for a LazyRelay account with status and live confirmation. Filter by status or account and set detail for full records.

Instructions

This account's upcoming and recent posts with their status (draft, needs_approval, pending, posted, failed) and whether each is confirmed live. Returns a short summary of each post; set detail to true for the full records. Filter by status or account to keep it small. The total in the answer is the number of posts returned after filtering and the limit, not the number of posts that exist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoAt most this many posts, default 50
detailNoReturn the full records instead of the short summary
statusNoOnly posts with this status
socialAccountIdNoOnly posts for this account

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.4
    • addedInput schema / properties / detail
      Added value: +{
+  "description": "Return the full records instead of the short summary",
+  "type": "boolean"
+}
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "At most this many posts, default 50",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / socialAccountId
      Added value: +{
+  "description": "Only posts for this account",
+  "type": "string"
+}
    • addedInput schema / properties / status
      Added value: +{
+  "description": "Only posts with this status",
+  "enum": [
+    "draft",
+    "needs_approval",
+    "pending",
+    "posting",
+    "posted",
+    "failed"
+  ],
+  "type": "string"
+}
  2. First observedv0.1.3

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description still adds genuine non-obvious context: the meaning of the returned total (post-filter, post-limit, not a global count) and the summary-vs-detail behavior, which an agent could otherwise misread.

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?

Front-loaded with what is returned and to whom, then progressively adds detail on the detail flag, filtering, and the total caveat. Slightly dense in the enumeration of statuses, which the schema enum already carries, but no wasted sentences.

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 description correctly carries the return-value burden by explaining the summary/detail distinction and the total-field semantics. For a 4-param, zero-required list tool this is nearly complete; only pagination/ordering behavior beyond limit is unstated.

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 meaning beyond the schema by explaining that the limit interacts with the reported total and that detail=true upgrades records to full form. It reinforces the status/account filtering rather than merely restating it.

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 ('This account's upcoming and recent posts') and names its scope precisely, including the status values and the 'confirmed live' dimension. An agent can tell this is the read/list view of scheduled posts apart from siblings like schedule_post or create_draft.

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?

Gives practical advice ('Filter by status or account to keep it small') but never states when to prefer this over alternatives such as get_analytics_summary or list_posting_slots, nor any exclusions. Usage is implied by the list verb rather than guided.

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

Deploy Server

Other Tools