Skip to main content
Glama
Sign In
vish288

mcp-coda

by vish288
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Coda List Folders

coda_list_folders
Read-onlyIdempotent

List folders accessible to the current Coda API token, one page at a time, to retrieve folder IDs for organizing or placing docs.

Instructions

List folders accessible to the current API token, one page at a time.

Returns folder metadata (name, ID, parent folder) with pagination — the API defaults to 25 per page, so pass cursor to fetch the rest. Folders organize docs in the Coda workspace. Use the returned folder IDs with coda_create_doc to place new docs in specific folders.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of folders to return (1-200)
cursorNoPagination cursor from a previous response
workspace_idNoLimit results to folders in this workspace (e.g. 'ws-AbCdEf')

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. Changed3 schema fields changedv0.9.0
    • addedInput schema / properties / cursor
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Pagination cursor from a previous response"
+}
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 50,
+  "description": "Maximum number of folders to return (1-200)",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / workspace_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Limit results to folders in this workspace (e.g. 'ws-AbCdEf')"
+}
  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 already declare readOnlyHint/idempotentHint/openWorldHint, but the description adds real value beyond them: pagination behavior, the per-page default, the cursor mechanism, and the shape of returned metadata. Minor flaw: it claims the API "defaults to 25 per page" while the schema's limit default is 50, an inconsistency worth resolving.

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-loads the core action and scope, then layers pagination and downstream usage. Every sentence is relevant, though the workspace-organizing aside is slightly tangential.

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 no output schema, the description correctly compensates by describing returned fields (name, ID, parent folder) and pagination handling. A low-complexity list tool is adequately covered; only the page-size inconsistency detracts.

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 limit/cursor/workspace_id are already documented; baseline is 3. The description adds the cursor's usage purpose but also introduces a page-size default (25) that conflicts with the schema's limit default of 50, so it doesn't clearly improve on the schema.

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 folders accessible to the current API token") with an explicit access scope, which separates it from siblings like coda_list_docs and coda_get_folder at a glance.

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 concrete downstream guidance ("Use the returned folder IDs with coda_create_doc to place new docs in specific folders") and explains the cursor workflow. It doesn't clarify when to prefer coda_get_folder or coda_search over listing, so it's clear context without explicit exclusions.

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