Skip to main content
Glama
Sign In
vish288

mcp-coda

by vish288
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Coda List Doc Analytics

coda_list_doc_analytics
Read-onlyIdempotent

Retrieve per-doc views, copies, likes, and session metrics over a date range to track Coda document engagement.

Instructions

List analytics data for docs (views, copies, likes, sessions).

Returns usage metrics for docs over the specified date range. Includes total views, unique views, copies, and other engagement metrics. Only available to doc owners. Use coda_get_doc_analytics_summary for aggregated totals instead of per-doc breakdown.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of results (1-200)
cursorNoPagination cursor from a previous response
doc_idsNoFilter to specific doc IDs
since_dateNoStart date for analytics (ISO 8601, e.g. '2024-01-01')
until_dateNoEnd date for analytics (ISO 8601)
is_publishedNoFilter to published (True) or unpublished (False) docs

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. First observedv0.4.14

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the owner-only access restriction and the list of returned engagement metrics. It does not discuss pagination behavior, but the schema handles that.

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 front-loaded, tightly scoped, and every sentence earns its place: it states what is listed, what is returned, who can use it, and which sibling handles the alternative case. There is no redundant or vague language.

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?

For a read-only list tool with rich schema coverage, annotations covering safety, and no output schema, the description supplies what is missing: the metric types returned, the owner-only constraint, and the routing rule to the summary sibling. Nothing needed to select or invoke the tool correctly is absent.

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 all six parameters are already documented in the input schema. The description only implies date-range filtering and adds no syntax, format, or default details 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'List analytics data for docs (views, copies, likes, sessions).' It also names the sibling it is not: 'Use coda_get_doc_analytics_summary for aggregated totals instead of per-doc breakdown,' so an agent can distinguish it from related analytics tools.

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

Usage Guidelines5/5

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

It gives an explicit alternative and the condition that selects it: use this tool for per-doc breakdown, and use coda_get_doc_analytics_summary for aggregated totals. It also states the prerequisite 'Only available to doc owners,' which is essential for correct invocation.

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