Skip to main content
Glama

List prompts

list_prompts
Read-onlyIdempotent

List the tracked questions (prompts) of a site with each assistant’s current verdict (named first, named, linked but not named, not named, failed), plus status, category and persona. Filter to find the work: verdict=lost where a competitor is named and the brand is not, cited where the site is linked but the brand not named, missing where it is never named; also q, category, status, competitor, stability and scanned. Paginated (page, perPage up to 200). For one question’s full answer use get_prompt.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>"
    },
    "name": "list_prompts"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoText to search for in the question.
dirNoSort direction.
pageNoPage number, from 1.
sortNocreated | text | category | rank | scanned. Default created.
statusNodraft, active or paused.
perPageNoPrompts per page, 5–200.
scannedNoyes = asked at least once; never = not scanned yet.
verdictNonamed | lost (a competitor is named, the brand is not) | cited (the site is linked, the brand not named) | missing | failed.
categoryNoOnly prompts filed under this category.
projectIdYesThe project id, from list_projects.
stabilityNoheld = named every week; volatile = sometimes; lost = named before, not for 2+ weeks.
competitorNoOnly prompts whose current answer names this competitor (its name).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety is covered. The description adds real context beyond that: the full verdict vocabulary including 'failed', the persona/category/status dimensions per row, and the perPage cap of 200. It stops short of describing ordering defaults or what an empty result means.

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?

Front-loaded and dense: purpose, then the filter semantics, then pagination, then the sibling redirect. The parenthetical verdict list in the first sentence is slightly run-on and partly duplicates the schema enum, which costs it a point.

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?

For a 12-parameter list tool with no output schema, the description does the heavy lifting by enumerating the returned fields and the filter dimensions. It is complete enough to call correctly; only sort-direction defaults and result-shape details are left implicit.

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?

Schema coverage is 100%, so the baseline is 3 and the schema already carries most definitions. The description still earns credit by grouping the filters into a task framing ('Filter to find the work') and restating the non-obvious verdict and stability semantics in workflow terms rather than enum terms.

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?

Opens with a specific verb and resource ('List the tracked questions (prompts) of a site') and immediately states what each row carries (verdict, status, category, persona). It also explicitly separates itself from get_prompt for the single-question case, so an agent can route without opening either schema.

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

Usage Guidelines5/5

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

Goes beyond generic guidance by mapping verdict values to investigative intent: 'verdict=lost where a competitor is named and the brand is not', 'cited where the site is linked but the brand not named', 'missing where it is never named'. It names the alternative tool (get_prompt) and the condition that selects it.

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