Skip to main content
Glama
Sign In
vish288

mcp-coda

by vish288
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Coda List Rows

coda_list_rows
Read-onlyIdempotent

List rows from a Coda table with optional filters, sorting, and cursor-based pagination. Returns row data with readable column values for AI document tasks.

Instructions

List rows in a Coda table with optional filtering and sorting.

Returns row data with column values. By default uses column names (not IDs) for readability. Use the query parameter to filter rows by column values. For a specific row by ID, use coda_get_row instead. Results are paginated — pass cursor to get the next page.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of rows to return (1-500)
queryNoFilter formula (e.g. 'Status:"Active"' or 'c-abc123:"value"')
cursorNoPagination cursor from a previous response
doc_idYesThe doc ID containing the table
sort_byNoRow sort order. One of 'createdAt', 'natural' (the table's own order), or 'updatedAt'. The API does not sort by an arbitrary column.
response_formatNo'json' for structured data, 'markdown' for readable textjson
table_id_or_nameYesTable ID or name to list rows from
use_column_namesNoUse column names (True) or IDs (False) in row values

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.1
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null
  2. Changed2 schema fields changedv0.9.0
    • changedInput schema / properties / sort_by / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "createdAt",
+      "natural",
+      "updatedAt"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / sort_by / description
      Previous value: -"Sort by column (prefix with '-' for descending, e.g. '-Created')"New value: +"Row sort order. One of 'createdAt', 'natural' (the table's own order), or 'updatedAt'. The API does not sort by an arbitrary column."
  3. First observedv0.4.14

TDQS

A4.1/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the description only needs to add context — and it does: pagination via cursor, the default of column names over IDs, and the presence of column values in results. It doesn't state what happens on an invalid cursor/query or rate-limit behavior, but that is a minor gap against annotation coverage.

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?

Five short sentences, front-loaded with the core action and ending with the pagination mechanic; no filler. Slight redundancy in the query-parameter sentence, which largely echoes the schema, keeps it from being fully tight.

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 an 8-parameter read tool with no output schema, the description covers the essential call flows (filter, sort, paginate, column-name output) and the sibling handoff. It doesn't describe the shape of the returned rows beyond 'column values', but with no output schema that is a modest gap rather than a blocking one.

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 limit, query, cursor, sort_by, use_column_names, and response_format. The description restates the query-as-filter and column-names-by-default behaviors rather than adding syntax or format detail beyond the schema, so the baseline 3 applies.

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 rows in a Coda table') plus the supported modifiers (filtering, sorting), and explicitly names the sibling it is not (coda_get_row for a single row by ID). An agent can distinguish this from coda_insert_rows/coda_update_row/coda_delete_rows without opening a 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?

Gives clear context for the query parameter and routes the single-row case to coda_get_row, which is the one realistic ambiguity among siblings. It stops short of stating exclusions for the mutation siblings (insert/update/delete) or when to prefer list_tables/list_columns first, so it is clear but not exhaustive.

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

Deploy Server

Other Tools