Skip to main content
Glama
Sign In
vish288

mcp-coda

by vish288
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Coda Create Doc

coda_create_doc

Create a new Coda doc as blank or copy an existing doc as a template, place it in a chosen folder, and return its ID, name, and URL.

Instructions

Create a new Coda doc.

Creates a blank doc or a copy of an existing doc. Returns the new doc's ID, name, and browser URL. The doc is created in the specified folder, or the user's root if no folder is given. Use source_doc to clone an existing doc as a template.

Input Schema

NameRequiredDescriptionDefault
titleYesTitle for the new doc
folder_idNoFolder ID to create the doc in (omit for root)
source_docNoDoc ID to copy as a starting point

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 declare a write operation (readOnlyHint=false, openWorldHint=true); the description adds value beyond them by stating the return payload (doc ID, name, browser URL), the default destination when folder_id is omitted, and the cloning behavior. It omits permission/auth requirements and any rate limits, which keeps it short of 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the core action before the modes and defaults. Slight redundancy between the opening two sentences ('Create a new Coda doc' / 'Creates a blank doc or a copy'), but no padding.

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 write tool with no output schema, the description covers the essentials: what is created, the two creation modes, destination defaults, and what is returned. Nothing an agent needs to call it correctly is missing.

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 all three parameters are already documented. The description's 'omit for root' and 'clone as a template' framings largely restate the schema wording rather than adding new syntax or constraints. 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+resource (create a new Coda doc) and clarifies the two modes (blank vs. clone from source_doc). An agent can distinguish this from coda_create_page, coda_create_folder, and coda_update_doc without opening schemas.

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?

Explains when to use source_doc (cloning an existing doc as a template) and where the doc lands (specified folder, else user root). No explicit when-not guidance or sibling routing (e.g., 'if you want a page, use coda_create_page'), but context is clear.

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