Cloche

List records

list_records

Read-only

Reads an app's data as the person this call acts for. With a collection named, lists one page of its records: all of a shared collection, only their own of a private one, and of an assigned one only those assigned to them unless they edit the app. Takes the previous page's next_cursor, and returns records and next_cursor, empty on the last page. With no collection, returns the collections the app declares, each shared, private or assigned with its fields and their types. Field values are written by the app's users.

Input Schema

Name	Required	Description
`app_id`	Yes	the app, as list_apps gave it
`cursor`	No	the previous page's next_cursor; omit for the first page
`collection`	No	a collection the app declares; omit to get the app's collections instead of records

Output Schema

Name	Required	Description
`records`	Yes	one page of records the person may read, when a collection was named; empty otherwise
`collections`	Yes	the collections the app declares, when no collection was named; empty otherwise
`next_cursor`	Yes	the cursor for the next page, empty on the last

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026

changedOutput schema / properties / collections / items / properties / access / description

Previous value: -"shared: everyone who opens the app reads every record. private: each person reads only their own"New value: +"shared: everyone who opens the app reads every record. private: each person reads only their own. assigned: a user reads those assigned to them, owners and editors all"

addedOutput schema / properties / collections / items / properties / assigned_to

Added value: +{
+  "description": "the field holding the assignee's id",
+  "type": "string"
+}

Changed2 schema fields changedOct 11, 2026

addedOutput schema / properties / records / items / properties / created_by

Added value: +{
+  "description": "the account that wrote the record, in the form user.id takes. Absent when someone wrote it through a share link without signing in, when the platform wrote it, and when the person cannot see who is in the app",
+  "type": [
+    "null",
+    "string"
+  ]
+}

addedOutput schema / properties / records / items / properties / updated_by

Added value: +{
+  "description": "the account that last changed the record. Absent when that is not known",
+  "type": [
+    "null",
+    "string"
+  ]
+}

AddedOct 8, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnly and non-destructive annotations, the description discloses the permission-dependent visibility semantics: shared collections return all records, private collections return only the caller's own, and assigned collections return only records assigned to the caller unless they edit the app. It also explains pagination behavior and states what is returned in each mode.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured: it first states the overall read behavior, then explains records mode, pagination, collections mode, and field provenance. Every sentence carries useful operational meaning, with no filler.

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?

Although an output schema exists, the description still usefully explains the shape of the two return modes and pagination termination. Combined with the annotations and complete parameter schema, an agent has enough context to invoke the tool correctly.

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 100%, so the schema already documents app_id, cursor, and collection. The description reinforces the collection and cursor semantics but adds little parameter-level detail beyond what the schema provides, making the baseline 3 appropriate.

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 states a specific verb-resource pair: it reads an app's data and lists either one page of a collection's records or the app's declared collections. The two operating modes are clear, though it does not explicitly name sibling alternatives such as get_app_context or list_apps.

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 clearly explains when to use each mode: pass a collection to list its records, omit it to get the app's collections, and pass cursor to continue pagination. It does not explicitly say when to prefer this tool over sibling tools, so it falls short of full alternative-routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Cloche tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.