Skip to main content
Glama

List captures

list_captures
Read-onlyIdempotent

List the user's recent VoiceLabs captures (dictations, recordings, uploads) with their transcripts, most-recent first. Paginated via limit (1-200) and offset. Read-only.

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo

Output Schema

NameRequiredDescriptionDefault
limitYes
totalYes
offsetYes
capturesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered and the trailing 'Read-only' is largely redundant. The description does add non-annotation behavior: result ordering (most-recent first) and the pagination contract. It says nothing about rate limits, maximum page depth, or what happens with a huge offset.

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 short, front-loaded sentences with no filler, and the scope/ordering comes before the pagination mechanics. The final 'Read-only' clause is redundant with the readOnlyHint annotation, so it is the one phrase that does not fully earn its place.

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?

With an output schema present, return values need not be described, and annotations cover safety; what remains is scope, ordering and pagination, all of which are stated. The only shortfall is the undocumented offset semantics and defaults against a 0%-covered schema.

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 0%, so the description must compensate: it supplies limit's bounds (1-200) and names offset for pagination, which is real added meaning. However it omits the defaults (50 and 0) and never explains what offset actually counts, leaving one of two parameters only half-specified.

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?

Specific verb (List) plus resource (VoiceLabs captures) and scope (the user's recent ones), with the content types enumerated (dictations, recordings, uploads) and the payload described (transcripts). No sibling tool overlaps this resource, so an agent can select it unambiguously.

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

Usage Guidelines3/5

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

The description implies the usage context ('the user's recent captures', 'most-recent first') and explains pagination, but never states when to reach for this tool versus another (e.g. search-style retrieval) or any exclusions. Usage is inferable but not spelled out.

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