Skip to main content
Glama

List published posts

list_posts
Read-onlyIdempotent

Fetch published Substack posts from a connected publication, newest first, with paging, limits, and sorting by date or title.

Instructions

List published posts, newest first.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many to return. 1 to 100, default 25.
offsetNoSkip this many, for paging.
order_byNopost_date
publicationNoWhich connected publication to act on, matched loosely against its hostname (for example 'example.substack.com' or just 'example'). Defaults to the first connected publication.
order_directionNodesc

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.0.1
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv2.1.1

TDQS

C2.8/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description's only addition ('newest first') restates an existing schema default, and it omits pagination behavior, whether results are scoped to one publication by default, and any result-size limits.

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?

A single short sentence, front-loaded with the verb and resource. Nothing wasted, nothing buried.

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

Completeness2/5

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

For a 5-parameter list tool with no output schema, the description does not explain result shape, total counts, whether paging is required for full coverage, or that publication defaults to the first connected one. An agent could call it, but lacks the context to use paging or scoping correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description mentions only ordering ('newest first'), which the schema already declares via order_by=post_date and order_direction=desc defaults. It says nothing about limit/offset paging or the publication selector, despite only 60% schema description coverage.

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 clear verb+resource ('List published posts') plus the default ordering. The 'published' qualifier implicitly separates it from list_drafts and list_scheduled_posts, but no sibling is named explicitly, so the agent must infer the boundary rather than being told.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance and no alternative is mentioned. With closely related siblings like search_posts, list_drafts, and list_scheduled_posts in the toolset, the absence of routing guidance leaves selection to guesswork.

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