Skip to main content
Glama

List records

list_records
Read-only

List submission records (leads) of the current team, newest first. Each item includes the examinee (name / email / customData if captured), the submitted answers, UTM metadata and a compact report result (status / score / level / outcome). Optionally filter by form, report status, and submitted-at range. Reference a respondent by examineeId, never by a masked email; email addresses and phone numbers written into the answers come back masked too. Use get_record for one record's full detail.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number (1-based), default 1
limitNoItems per page, default 20, max 100
sinceNoOnly records submitted on/after this ISO datetime, optional
untilNoOnly records submitted on/before this ISO datetime, optional
formIdNoFilter by form UUID, optional
statusNoFilter by report generation status, optional. awaiting_gate: the form gates the report behind a respondent verification step and the respondent has not passed it yet, so the AI report has not been generated.

Output Schema

NameRequiredDescriptionDefault
pageNo1-based page returned
itemsNoThe page of submissions (newest first)
limitNoPage size actually used
totalDocsNoTotal submissions matching the filter

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / items / items / properties / metadata / description
      Previous value: -"Channel attribution { utmSource, utmMedium, utmCampaign, utmTerm, utmContent, referrer }"New value: +"Channel attribution { utmSource, utmMedium, utmCampaign, utmTerm, utmContent, referrer, params } — params holds the URL parameters (hidden fields) declared on the quiz"
  2. Changed1 schema field changed
    • changedInput schema / properties / status / description
      Previous value: -"Filter by report generation status, optional"New value: +"Filter by report generation status, optional. awaiting_gate: the form gates the report behind a respondent verification step and the respondent has not passed it yet, so the AI report has not been generated."
  3. Changed1 schema field changed
    • changedInput schema / properties / status / enum
      Previous value: -[
      -  "pending",
      -  "processing",
      -  "completed",
      -  "failed"
      -]New value: +[
      +  "pending",
      +  "processing",
      +  "completed",
      +  "failed",
      +  "awaiting_gate"
      +]
  4. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the readOnlyHint/destructiveHint annotations, it discloses non-obvious behavior: default ordering (newest first), field masking of emails and phone numbers written into answers, and the requirement to reference respondents by examineeId rather than masked email. That masking rule is exactly the kind of trap an agent needs warned about. It does not discuss pagination totals or rate/size limits, keeping it short of a 5.

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?

Three tightly packed sentences, front-loaded with what the tool returns, followed by filtering and the sibling pointer. Every clause carries information, though the parenthetical field enumeration is dense enough to slow reading slightly.

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 six-parameter, zero-required read tool with an output schema, the description covers return contents, ordering, filters, and the masking/ID caveats an agent must respect. The only missing piece is pagination/limit behavior, which the schema already annotates adequately.

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 all six parameters are already documented, and the description only restates the filter axes (form, report status, submitted-at range) without adding format or edge-case guidance. Pagination parameters are not mentioned at all. Baseline 3 is appropriate when the schema carries the semantics.

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?

States a specific verb and resource ('List submission records (leads) of the current team, newest first') plus the exact shape of each item (examinee, answers, UTM, compact report result). It also names the sibling it is not ('Use get_record for one record's full detail'), so an agent can discriminate without opening the schema.

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?

Clear context for the summary-list use case and an explicit alternative route to get_record for full detail. There is no explicit exclusion, and the description loosely equates 'records' with 'leads' while a sibling list_leads exists, which leaves some ambiguity about which list tool to pick when the user says 'leads'.

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