Skip to main content
Glama

List tracked prompts and their FAQ answers

list_prompts
Read-onlyIdempotent

A site's tracked prompts, oldest first, 100 per page: each with queryId, query (the tracked text exactly as stored), faqQuestion (the question the FAQPage JSON-LD carries: a language variant's trailing engine instruction removed), language (the variant's language, null for the default variant), templateId, answer (the FAQ answer verbatim, null when there is none), answerHash, answerUpdatedAt (when the answer last changed; null if it has not changed since 2026-10-26), archived, automaticChecksFrom (YYYY-MM-DD when its automatic checks start in a later month, else null), replacesQueryId (the prompt this one replaced, else null) and replacedByQueryId (the newest prompt that replaced this one, else null; a replaced prompt is archived and keeps its history). answerHash is the lowercase hex SHA-256 of the answer's UTF-8 bytes — hash exactly the answer string returned here (answers are stored with LF line endings and trimmed ends, nothing else changed) and compare to check that your page and Promvia hold the same text; it is also the expectedHash the answer writes take. Pass nextCursor back as cursor for the next page (null on the last); archived prompts only with includeArchived: true. Writing answers is set_prompt_answer or sync_prompt_answers, which need write access (prompts:write).

Input Schema

NameRequiredDescriptionDefault
cursorNonextCursor from the previous page.
siteIdNoOptional on a connected app: the site chosen with select_site is used. If given, it must be that site. With an API key it is required: a site id from list_sites.
includeArchivedNoInclude prompts you stopped tracking (default false).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / siteId / description
      Previous value: -"A Promvia site id. Get one from list_sites."New value: +"Optional on a connected app: the site chosen with select_site is used. If given, it must be that site. With an API key it is required: a site id from list_sites."
    • removedInput schema / required
      Removed value: -[
      -  "siteId"
      -]
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, the description discloses ordering, page size, pagination behavior, archived-prompt behavior, and detailed semantics for many returned fields including null conditions and replacement history. The answerHash explanation adds useful behavioral context about exact text comparison and expected write hashes.

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?

The description is front-loaded with the tool's purpose and scope, then moves into field semantics and pagination/write alternatives. It is dense and written as a long run-on enumeration, but given the absence of an output schema, most of the field detail earns its place.

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

Completeness5/5

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

The description is complete enough for a paginated read tool: it covers scope, ordering, pagination, archived behavior, returned fields, hash semantics, and the alternative write tools. With annotations covering safety and the schema covering parameters, no critical agent-facing information appears missing.

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 100% schema coverage, the schema already defines the three parameters, but the description adds practical meaning by specifying page size, oldest-first ordering, that nextCursor is passed back as cursor and is null on the last page, and that archived prompts appear only with includeArchived: true. These are useful clarifications beyond the schema, though some duplicate the schema descriptions.

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 makes clear that this tool returns a site's tracked prompts, ordered oldest first and paginated at 100 per page, with their FAQ answers and related fields. It is specific about the resource and scope, but it does not explicitly differentiate itself from sibling tools such as get_prompt_templates or other read tools.

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?

It tells the agent to pass nextCursor back as cursor for the next page and that archived prompts require includeArchived: true, giving concrete usage instructions for pagination and archived content. It also redirects answer-writing to set_prompt_answer or sync_prompt_answers, though those are not listed siblings and it does not explicitly distinguish this list tool from all other sibling reads.

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.