Skip to main content
Glama
Sign In
vish288

mcp-coda

by vish288
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Coda Update Page

coda_update_page
Idempotent

Update a Coda page's name, subtitle, or content. Choose replace to overwrite the full page or append to add content, specifying HTML or markdown.

Instructions

Update a page's name, subtitle, or content in a Coda doc.

Updates page metadata and/or content. When updating content, 'replace' mode overwrites the entire page while 'append' adds to the end. There is no partial inline edit — draft full content locally first. Content format must match what you send (HTML or markdown). Returns the updated page metadata.

Input Schema

NameRequiredDescriptionDefault
nameNoNew name for the page
doc_idYesThe doc ID containing the page
contentNoNew page content (replaces existing content)
subtitleNoNew subtitle for the page
insert_modeNoHow to insert content: 'replace' overwrites, 'append' adds to end
content_formatNoFormat of the content parameter
page_id_or_nameYesPage ID or name to update

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

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and openWorldHint=true, and the description goes well beyond them: 'replace' overwrites the entire page, 'append' adds to the end, there is no partial inline edit, and content format must match what is sent. That is strong disclosure of destructive scope and failure modes. One caveat: append mode makes repeated identical calls accumulate content, which sits uneasily with idempotentHint=true, though the explicit description of both modes limits the risk to an agent.

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 action and followed by the behavioral constraints in a logical order. The only waste is near-duplication between 'Update a page's name, subtitle, or content' and 'Updates page metadata and/or content,' which say the same thing twice.

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?

No output schema exists, and the description usefully states the return value ('updated page metadata') and the mutation semantics. It is complete for calling the tool, with minor gaps around default resolution for insert_mode/content_format and no mention of auth or permission requirements.

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 both required IDs and all five optional fields are already documented in the schema; the description mostly restates the insert_mode enum rather than extending it. It does not clarify what the null defaults for insert_mode/content_format resolve to or that those params only matter when content is supplied, so the baseline 3 is 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?

'Update a page's name, subtitle, or content in a Coda doc' gives a specific verb (update), resource (page), and the fields touched. The page-vs-doc and page-vs-row distinction is implicit in the naming, but with ~35 siblings including coda_update_doc and coda_create_page, no explicit differentiation is offered, so it stops short of a 5.

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 gives operational guidance (draft full content locally first, choose replace vs append) but never states when to choose this tool over alternatives like coda_get_page_content or coda_create_page, nor any prerequisites. Usage is implied rather than directed.

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