Skip to main content
Glama

findPages

Editor-curated marketing pages. Call listAvailableBlocks first to learn the available layout-block types. Title is required in default-locale. Use _status="draft" until reviewed, then _status="published" to go live NOW. To publish (or unpublish) at a FUTURE date, use the schedulePost tool with publishAt/unpublishAt — do NOT set a future publishedAt (the page stays a draft until the scheduled time, then auto-publishes). HOMEPAGE convention: set slug="home" (hardcoded in frontend route, both default + IT locale need slug="home"). System-pages use systemPageKey field — read-only in MCP. After page creation, link them in menus collection (slug="header-main") so they appear in navigation. pages 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), layout (blocks, localized), systemPageKey (enum: faq (FAQ index)|search (Search results)|posts-archive|glossary-archive|not-found (404 — page not found)|server-error (500 — server error)|+7), publishedAt (date), 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). Layout blocks (39): hero, trustMarquee, statement, cardGrid, quotes, splitKi, codeFiles, splitMcp, capabilities, splitSprachen, coreScrolly, stackChips, fundament, teamAbout, faqBlock, cta, factsBand, pageHeader, featureList, compareTable, race, contactSplit, geoMap, eigenbau, legal, textContent, archive, mediaBlock, gallery, formBlock, newsletterBlock, snippetEmbed, testimonialsBlock, mediaText, cards, searchClient, html, styledHtmlBlock, datasetCitation. Use listAvailableBlocks for per-block field schemas.

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.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden; it does disclose draft-table behavior and public read access, which is useful. However it says this tool's MCP capabilities include create/update/delete and warns about permanent deletes, which contradicts the find-only schema and can mislead an agent about side effects; pagination and return behavior are also absent.

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 very long for a find operation and is not front-loaded around listing/retrieving pages; it opens with block lookup and expands into publishing, field lists, and 39 layout blocks. Those details may belong to write tools but are waste here.

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 10-param find tool with no output schema or annotations, the description should focus on read behavior and response expectations, but instead it is dominated by write/publish/delete guidance. It provides some draft and public-read context, yet is not complete enough about how findPages returns or paginates results.

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 coverage is 100%, so the baseline is 3; the description adds a useful semantic note for draft (without draft:true only published main-table state) and some locale/localization context. It does not add much for where/select/depth/sort beyond the schema.

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

Purpose2/5

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

The opening identifies the resource (editor-curated marketing pages) but never states a find/list verb up front; the only explicit 'find' appears inside a list of MCP capabilities that also claims create/update/delete. That muddles whether findPages is read-only and fails to distinguish it from sibling findX collection tools.

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?

Most usage guidance is for writing/publishing (draft status, schedulePost, homepage slug, menus, getWritingGuidelines) rather than for when to call findPages versus findPosts/findFaqs/etc. The one find-specific rule—draft:true vs published state—is useful but does not give explicit when/when-not guidance.

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