Skip to main content
Glama

AI Engine for WordPress

List posts

wp_get_posts
Read-only

List posts, pages or another post type, newest first. Returns ID, title, status, excerpt and link for each, without the full content. Filter by post_type, post_status, search text, author (user ID or slug) or a date range. Returns 10 items unless limit is set; page with offset or paged.

Input Schema

NameRequiredDescriptionDefault
afterNo
limitNo
pagedNo
authorNoFilter by author user ID.
beforeNo
offsetNo
searchNo
post_typeNo
author_nameNoFilter by author user slug (nicename). Ignored if author is set.
post_statusNo
author__not_inNoExclude posts by these author user IDs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly and non-destructive, so the bar is lower; the description adds valuable behavior: newest-first ordering, excluded full content, default result count of 10, and offset/paged paging semantics. It stops short of noting rate limits or auth requirements but covers the operation's shape well.

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 tight sentences, front-loaded with the core action and scope, followed by filtering and pagination details. No filler; each sentence carries unique, useful information.

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?

No output schema exists, so describing the returned fields is necessary and done. Combined with default-limit and pagination disclosure, an agent has enough to call it correctly; minor gaps (author__not_in, ordering param) remain.

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?

With only 27% schema coverage across 11 params, the description compensates well: it explains post_type, post_status, search, author (ID or slug), date-range (after/before), limit, offset and paged. Only author__not_in and the author_name-ignored-if-author-set nuance are left to the schema, otherwise coverage is strong.

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?

Specific verb (List) and resource (posts/pages/custom post types) with scope ('newest first') and explicit return fields ('ID, title, status, excerpt and link, without the full content'). This distinguishes it clearly from siblings like wp_get_post (singular) and wp_count_posts.

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

Usage Guidelines4/5

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

Explains how to filter (post_type, post_status, search, author, date range) and how to paginate, giving clear usage context. It does not explicitly name alternative tools or when-not to use this one, keeping it just shy of a 5.

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