Skip to main content
Glama
Sign In
vish288

mcp-coda

by vish288
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Coda Create Page

coda_create_page

Create a new page in a Coda doc by providing a title and the doc ID. Optionally include content in HTML or markdown, a subtitle, or a parent page for nesting.

Instructions

Create a new page in a Coda doc.

Creates a page with optional initial content. Returns the new page's ID and metadata. The page is created at the top level unless parent_page_id is specified. Content can be HTML or markdown — specify the format via content_format. Pack formulas cannot be inserted via the API.

Input Schema

NameRequiredDescriptionDefault
nameYesName/title for the new page
doc_idYesThe doc ID to create the page in
contentNoInitial page content in HTML or markdown
subtitleNoSubtitle text for the page
content_formatNoFormat of the content parameter
parent_page_idNoParent page ID to nest under (omit for top-level)

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.2/5.0
Behavior4/5

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

Annotations cover the mutation profile (readOnlyHint=false, openWorldHint=true), so the bar is lower. The description still adds real behavioral context: default top-level placement, the returned ID/metadata, and the notable constraint that pack formulas cannot be inserted via the API. Auth/permission requirements are not stated, keeping it from a 5.

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?

Four short sentences, front-loaded with the primary action, and every sentence carries distinct information (purpose, return value, nesting default, format control, limitation). No filler.

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 helpfully states what is returned (ID and metadata), and it covers formats, nesting, and a key API limitation. It does not mention permissions or failure modes, but for a create tool against rich annotations and a fully documented schema, it is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds relational semantics the per-parameter schema does not: parent_page_id defaults to top-level nesting, and content format is controlled jointly by content and content_format. That interplay is genuinely useful beyond the individual field descriptions.

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+resource ('Create a new page in a Coda doc') and is immediately distinguishable from siblings like coda_update_page, coda_get_page, and coda_create_doc. An agent can select it without ambiguity.

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 create intent is self-evident, and it implies usage context (nesting via parent_page_id, format via content_format). However, it names no alternatives and gives no explicit when-to-use/when-not guidance against siblings such as coda_update_page or coda_create_doc.

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