Skip to main content
Glama

List posts

list_posts
Read-only

Recent and upcoming posts, newest first, with their status, time and where they go.

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_posts"
  }
}

Input Schema

NameRequiredDescriptionDefault
brandNoBrand name or id.
limitNoDefault 20.
statusNoOnly these statuses, e.g. ["pending"] for posts waiting for approval.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral value by disclosing sort order (newest first) and that future/scheduled posts are included, but it stays silent on truncation behavior, default result size, and whether cancelled or failed posts appear by default.

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?

A single front-loaded sentence with no filler; the ordering and returned fields are stated up front. Slight cost in clarity from the colloquial 'where they go', which is less precise than naming destinations or channels.

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 simple, three-parameter, zero-required read tool with full schema coverage and no output schema, the description covers scope, ordering, and returned fields adequately. Missing details about paging beyond the limit cap are minor rather than blocking.

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%, so brand, limit, and status are already fully documented in the schema, including the status enum and the approval-filtering example. The description adds no additional meaning about these parameters, which matches the baseline for a fully covered schema.

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 names the resource (posts) and its scope (recent and upcoming, newest first) plus the payload it carries (status, time, destination). This distinguishes it implicitly from get_post, but it never says 'list' as a verb or explicitly contrasts with get_post/cancel_post, so differentiation relies on the tool name and sibling inference.

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 only implied: 'recent and upcoming' suggests a browsing/overview call, and 'newest first' hints at recency-oriented reads. There is no explicit statement of when to choose this over get_post for a single post, no mention that brand filtering is available, and no guidance on the limit parameter or how to page past 100 results.

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