Skip to main content
Glama

findPosts

Blog-style articles. content is Lexical richText (call listAvailableBlocks for richTextFeatures + inline-block list). PUBLIC AUTHOR: by default published AS the organization — set authorMode: "organization" (brand voice from the branding global). To publish AS a team member, set authorMode: "person" + teamAuthor: <team-member-id> (find the id via the team find tool — it lists members with id + name) and call getPersona(<id>) for their writing voice (style). The author field (relation to users) is the INTERNAL "created by" only — NOT the public author; it defaults to the user your key is bound to. Use categories+tags for taxonomy. SCHEDULING: to publish (or unpublish) at a FUTURE date, keep _status:"draft" and call the schedulePost tool with publishAt/unpublishAt — do NOT set a future publishedAt (the post stays a draft until the scheduled time, then auto-publishes). posts collection. Drafts: yes (publish workflow; a find WITHOUT draft:true returns the published main-table state only). Public read: yes via /api/agents. MCP capabilities: find, create, update, delete. ⚠ delete is PERMANENT (hard-delete; the admin Trash does NOT catch MCP deletes). Before writing public text here, call getWritingGuidelines with this collection and the locale (brand voice, writing rules, fixed terms, SEO rules, taken keywords, field rules). Fields: title (localized), slug (localized), excerpt (textarea, localized), coverImage (upload: media|brand), content (richText, localized), author (rel: users), authorMode (enum: organization (Organisation)|person (Person (team member))), teamAuthor (rel: team), publishedAt (date), categories (rel-array: categories), tags (rel-array: tags), relatedFaqs (rel-array: faqs), robots (enum: index (Index (default))|noindex (noindex (hide))), searchText (textarea, localized, ≤60000 chars, redacted), meta (group: title, description, focusKeyword, secondaryKeyword1-4, searchIntent, eeatInsight, image — localized).

Input Schema

NameRequiredDescriptionDefault
idNoOptional: specific document ID to retrieve. If not provided, returns all documents
pageNoPage number for pagination (default: 1)
sortNoField to sort by (e.g., "createdAt", "-updatedAt" for descending)
depthNoHow many levels deep to populate relationships (default: 0)
draftNoOptional: Whether the document should be queried from the versions table/collection or not.
limitNoMaximum number of documents to return (default: 10, max: 100)
whereNoOptional JSON string for where clause filtering (e.g., '{"title": {"contains": "test"}}')
localeNoOptional: locale code to retrieve data in (e.g., "en", "es"). Use "all" to retrieve all locales for localized fields
selectNoOptional: define exactly which fields you'd like to return in the response (JSON), e.g., '{"title": true}'
fallbackLocaleNoOptional: fallback locale code to use when requested locale is not available

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior4/5

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

With no annotations, the description still discloses meaningful behavior: draft versus published querying, public read availability, the permanent nature of deletes, and the distinction between internal author and public author semantics. It could be clearer that this tool itself is read-only, since listing 'find, create, update, delete' as MCP capabilities risks confusing the tool's actual scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a long wall of text that front-loads authoring and publishing semantics rather than the find operation. Many sentences concern create/update/delete and field definitions that are not parameters of this tool, so a substantial portion does not earn its place for findPosts.

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

Completeness3/5

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

For a 10-parameter read tool with no output schema and no annotations, the description gives useful collection context, field names, draft behavior, and public-read status. However, it does not describe the return shape or find-specific pagination/filtering behavior, and it spends much of its length on unrelated mutation and authoring details.

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 the parameter definitions already carry most of the burden. The description adds useful meaning for the draft parameter by explaining that omitting draft:true returns only the published main-table state, but it does not add semantics for the other parameters such as id, page, sort, where, select, or limit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource as 'Blog-style articles' and mentions 'find' among the collection's MCP capabilities, but it never clearly states up front that findPosts retrieves or lists posts. It also does not distinguish the tool from sibling find tools such as findPages beyond the resource type, and much of the text is about create/update/delete behavior rather than the find operation.

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 explicit guidance on when to use findPosts versus findPages, findFaqs, or the other find siblings. The only find-specific usage note is the draft behavior ('a find WITHOUT draft:true returns the published main-table state only'); most other guidance concerns authoring, scheduling, and writing guidelines rather than when to call this tool.

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