The Coda MCP Server enables interaction with a Coda document through an MCP client, allowing for comprehensive page management:
List pages: Retrieve all pages within the configured document
Create page: Add new pages with optional markdown content
Get page content: Fetch markdown content from a specified page by ID or name
Update page content: Replace or append content to existing pages
Duplicate page: Create copies of pages with new names
Rename page: Change the name of existing pages
Allows interaction with a Coda document, providing tools to list, create, read, update, and duplicate pages, as well as manage page content in markdown format.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Coda MCP Server list all pages in our project planning document"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This project implements a Model Context Protocol (MCP) server that acts as a bridge to interact with the Coda API. It allows an MCP client (like an AI assistant) to perform actions on Coda pages, such as listing, creating, reading, updating, duplicating, and renaming.
This MCP server is not developed or maintained by Coda; it's a community-built project.
The server exposes the following tools to the MCP client:
coda_list_documents: Lists all documents available to the user.
coda_list_pages: Lists all pages within the configured Coda document with pagination support.
coda_create_page: Creates a new page in the document, optionally under a specified parent page (creating a subpage) and populating it with initial markdown content.
coda_get_page_content: Retrieves the content of a specified page (by ID or name) as markdown.
coda_replace_page_content: Replaces the content of a specified page with new markdown content.
coda_append_page_content: Appends new markdown content to the end of a specified page.
coda_duplicate_page: Creates a copy of an existing page with a new name.
coda_rename_page: Renames an existing page.
coda_peek_page: Peek into the beginning of a page and return a limited number of lines.
coda_resolve_link: Resolve metadata given a browser link to a Coda object.
coda_list_tables: List tables in a document.
coda_list_columns: List columns in a table.
coda_list_rows: List rows in a table with optional filtering and sorting.
coda_get_row: Get a single row from a table.
coda_upsert_rows: Insert or upsert rows into a table.
coda_update_row: Update a single row in a table.
coda_delete_row: Delete a single row from a table.
coda_delete_rows: Delete multiple rows from a table.
coda_push_button: Push a button column on a row in a table.
Related MCP server: Notion MCP Server
Add the MCP server to Cursor/Claude Desktop/etc. like so:
{
"mcpServers": {
"coda": {
"command": "npx",
"args": ["-y", "coda-mcp@latest"],
"env": {
"API_KEY": "..."
}
}
}
}Required environment variables:
API_KEY: Your Coda API key. You can generate one from your Coda account settings.
This MCP server is also available with Docker, like so:
{
"mcpServers": {
"coda": {
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "API_KEY", "reaperberri/coda-mcp:latest"],
"env": {
"API_KEY": "..."
}
}
}
}Prerequisites:
Node.js
pnpm
Clone the repository:
git clone <repository-url>
cd coda-mcpInstall dependencies:
pnpm installBuild the project:
pnpm buildThis compiles the TypeScript code to JavaScript in the dist/ directory.
The MCP server communicates over standard input/output (stdio). To run it, set the environment variables and run the compiled JavaScript file - dist/index.js.
Append new markdown content to the end of a page
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document that contains the page to append the content to | |
| pageIdOrName | Yes | The ID or name of the page to append the content to | |
| content | Yes | The markdown content to append to the page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It correctly states that content is appended to the end of a page, which is a minimal but accurate behavioral trait. However, it omits details like idempotency, required permissions, or behavior on duplicate content. The description is not misleading but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. Every word adds meaning: 'Append' (action), 'new markdown content' (what), 'to the end of a page' (where). It is appropriately sized for a simple tool with three straightforward parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no output schema, the description should explain what the caller can expect as a result (e.g., success indicator, updated page content). It also lacks context for selection among siblings: for instance, it does not mention that this tool is for adding content without altering existing content, unlike 'replace_page_content'. Error conditions (e.g., page not found, content size limits) are unaddressed. The description is incomplete for a practical agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: each parameter has a clear description. The tool description does not add any additional meaning beyond the schema. For example, it does not provide examples, formatting tips, or explain how 'pageIdOrName' should be formatted. Thus, it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('append'), the resource ('page'), and the content format ('markdown'). It effectively distinguishes from sibling tools like 'replace_page_content' which overwrites, and 'get_page_content' which reads, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not differentiate from 'coda_replace_page_content' or mention scenarios where appending is preferred over replacing or inserting. This lack of direction forces the agent to rely solely on tool names and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a page in the current document
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document to create the page in | |
| name | Yes | The name of the page to create | |
| content | No | The markdown content of the page to create - optional | |
| parentPageId | No | The ID of the parent page to create this page under - optional |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It implies mutation but does not disclose behavior on duplicate names, invalid parentPageId, content limits, or error handling. Minimal transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but incomplete. Lacks context needed for effective use, making it under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no annotations, and no output schema, the description is insufficient. Does not explain return values, prerequisites, or behavior of optional parameters. Agent lacks information to invoke correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). Description adds no additional meaning beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'create' and resource 'page', distinguishing it from sibling 'coda_duplicate_page'. However, phrase 'current document' is misleading since docId is a required parameter, implying a specific document, not necessarily the current one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like coda_duplicate_page, coda_rename_page, or coda_replace_page_content. Does not mention prerequisites or context for creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a single row from a table
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document | |
| tableIdOrName | Yes | The ID or name of the table | |
| rowIdOrName | Yes | The ID or name of the row to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action (delete) without disclosing any behavioral traits such as side effects, permissions, or reversibility. With no annotations provided, the description fails to add value beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is efficient but somewhat underspecified; however, it is concise for a simple deletion operation, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks details about what happens upon deletion (e.g., permanence, return value). There is no output schema, and the description does not cover prerequisites or results, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter documented. The description does not add any additional meaning beyond the schema, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool deletes a single row from a table, using a specific verb and resource. It distinguishes from the sibling tool 'coda_delete_rows' (plural) by specifying 'single row', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'coda_delete_rows'. The agent would need to infer from the name and the word 'single' in the description, but there is no explicit instruction or context about batch deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete multiple rows from a table
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document | |
| tableIdOrName | Yes | The ID or name of the table | |
| rowIds | Yes | JSON string of row IDs to delete, e.g. ["i-row1", "i-row2"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal and does not disclose whether the operation is irreversible, requires permissions, or has any rate limits or constraints on batch size. With no annotations, this is a significant gap for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no wasted words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too brief for a delete operation. It does not explain consequences (irreversibility), error handling (missing rows), or return value. Sibling context suggests more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions. The description adds useful formatting context for rowIds (JSON string example), but otherwise does not add meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and resource (multiple rows from a table). However, it does not differentiate itself from sibling tool coda_delete_row which deletes a single row.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling coda_delete_row or when it is appropriate to delete multiple rows. The description lacks context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate a page in the current document
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document that contains the page to duplicate | |
| pageIdOrName | Yes | The ID or name of the page to duplicate | |
| newName | Yes | The name of the new page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses the basic action ('duplicate') but omits critical behavioral traits such as whether subpages are duplicated, whether permissions are copied, or what the tool returns. For a mutation operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and efficient, though it could benefit from additional structured details without becoming verbose. It earns its place but is minimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters, no output schema, and no annotations, the description is too sparse. It does not explain return behavior (e.g., returns the new page ID?), constraints (e.g., cannot duplicate to another document), or relationship to sibling tools. The agent lacks crucial context to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The tool description does not add extra meaning beyond what the schema already provides (e.g., it does not explain how 'pageIdOrName' resolves ambiguity between ID and name). Baseline score of 3 is appropriate given schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Duplicate a page in the current document', specifying the action (duplicate) and resource (page). It is specific and distinct from creating a page, but does not explicitly differentiate from other page operations like coda_create_page, which is implied but not clarified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of when not to use it or any distinguishing factors from siblings like coda_create_page or coda_peek_page. The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the content of a page as markdown
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document that contains the page to get the content of | |
| pageIdOrName | Yes | The ID or name of the page to get the content of |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does state that the output is markdown, which is a useful behavioral trait. However, it omits details such as whether child pages are included, error handling, or how page names are resolved, leaving significant gaps for a tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose and format with minimal length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 parameters, no nested objects) and the schema covers parameters fully. However, the lack of an output schema, annotations, and usage guidance means the description must compensate. While it covers the basic behavior, it does not explain when to use it or provide expectations about the markdown output structure, so it is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters, so the schema already provides the necessary semantic meaning. The description adds no additional parameter context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('content of a page'), and the output format ('as markdown'), which distinguishes it from list-type siblings. However, it does not explicitly contrast with coda_peek_page, which might be similar, so it lacks full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like coda_peek_page or coda_get_row. There are no explicit exclusions or contextual cues, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single row from a table
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document | |
| tableIdOrName | Yes | The ID or name of the table | |
| rowIdOrName | Yes | The ID or name of the row | |
| useColumnNames | No | Use column names instead of column IDs in the output - defaults to true | |
| valueFormat | No | The format that cell values are returned as. 'rich' returns detailed objects for images, people, and references. 'simple' returns plain strings. Defaults to 'rich'. | rich |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. The description is minimal, only stating 'Get a single row', which implies a read operation. It does not explicitly state that it is read-only or disclose any side effects, but for a simple get operation, the transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise but could be slightly more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not mention what the tool returns. For a simple get operation, while the action is clear, the lack of return value information and any prerequisites or error conditions makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters. The description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single row from a table' clearly specifies the action (get), resource (single row), and context (from a table). It distinguishes from sibling tools like coda_list_rows (multiple rows) and coda_update_row (modification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., coda_list_rows for multiple rows, coda_update_row for editing). No prerequisites, when-not-to-use, or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List columns in a table
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document | |
| tableIdOrName | Yes | The ID or name of the table | |
| limit | No | The number of columns to return - optional | |
| nextPageToken | No | The token needed to get the next page of results, returned from a previous call to this tool - optional |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning pagination, read-only nature, or any side effects. The schema hints at nextPageToken for pagination, but the description does not elaborate, leaving key behavior undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is under-specified, essentially restating the tool name. It lacks useful context or guidance that would justify its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should compensate by explaining pagination, limits, or return behavior. It fails to do so, making the tool less complete for an agent that must rely solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all four parameters, so the schema already documents each parameter. The description adds no additional semantic meaning beyond the schema, meeting the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('columns in a table'), clearly distinguishing it from sibling tools that list documents, pages, tables, or rows. It is unambiguous and directly states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the resource name, but it does not explicitly state when to use this tool versus alternatives like coda_list_rows or coda_list_tables. There is no mention of prerequisites or exclusion contexts, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search available documents
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | The query to search for documents by - optional |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List or search' implies a read operation, but it does not disclose authentication needs, pagination, or what 'available' means. It also does not describe the return format, which is needed since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It economically conveys the core function and allows the schema to handle parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema), but the description omits what the returned documents look like or how 'available' is defined. Given the sibling list tools, more context would help the agent understand what distinguishes a document and when to use this tool first.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'query' has a clear description. The tool description adds no additional semantic information beyond implying that 'query' is used for searching, which is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('list' or 'search') and resource ('documents'). It distinguishes from sibling tools like coda_list_pages, coda_list_tables, and coda_list_rows by focusing on documents rather than pages/tables/rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling list tools, the description does not explain when to choose list_documents over list_pages or list_tables, or mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pages in the current document with pagination
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document to list pages from | |
| limit | No | The number of pages to return - optional, defaults to 25 | |
| nextPageToken | No | The token need to get the next page of results, returned from a previous call to this tool - optional |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether this is a read-only operation, what fields are returned, or any side effects. It only mentions pagination, which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler words. It's appropriately concise, though it sacrifices informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and sparse descriptions, the tool description fails to explain what page data is returned (e.g., titles, IDs, hierarchy). It also doesn't clarify pagination behavior beyond a token. An agent would lack sufficient context to predict the output or handle errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters (docId, limit, nextPageToken) with coverage at 100%. The description adds 'with pagination' which reinforces the limit/nextPageToken usage but adds no new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the action (list) and resource (pages), but refers to 'current document' despite the required docId parameter, creating slight ambiguity. It distinguishes from sibling tools like coda_list_documents by specifying pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives like coda_list_documents or coda_get_page_content. The description lacks any 'use this when...' or 'instead of...' language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List rows in a table with optional filtering and sorting
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document | |
| tableIdOrName | Yes | The ID or name of the table | |
| query | No | Filter rows by column value, e.g. "Column Name":"value" - optional | |
| sortBy | No | Sort order for returned rows - optional | |
| useColumnNames | No | Use column names instead of column IDs in the output - defaults to true | |
| valueFormat | No | The format that cell values are returned as. 'rich' returns detailed objects for images, people, and references. 'simple' returns plain strings. Defaults to 'rich'. | rich |
| limit | No | The number of rows to return - optional | |
| nextPageToken | No | The token needed to get the next page of results, returned from a previous call to this tool - optional |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It notes optional filtering and sorting but omits pagination (nextPageToken), read-only behavior, or authentication needs. Minimal behavioral context beyond the core operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient, front-loaded with core action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description is too brief. Lacks mention of pagination, return format, or row structure, which are essential for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds 'optional filtering and sorting' which hints at query and sortBy, but does not explain their semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List rows' and resource 'in a table', with optional filtering and sorting. It distinguishes from sibling tools like coda_list_columns and coda_get_row.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The description implies use for listing multiple rows with filters, but does not mention alternatives like get_row for single rows or upsert_rows for modification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tables in a document
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document to list tables from | |
| limit | No | The number of tables to return - optional, defaults to 25 | |
| nextPageToken | No | The token needed to get the next page of results, returned from a previous call to this tool - optional |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states 'List tables' and does not mention pagination (nextPageToken), default limit (25), or the nature of the returned data. The schema hints at these, but the description omits key behavioral context like whether all tables are returned or if there are any filtering capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded and contains no filler, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one required parameter and a simple purpose, the description is incomplete: it does not explain the return format, pagination behavior, or how to chain calls with nextPageToken. Given the absence of an output schema and annotations, the description should provide more context for successful use, but it falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters (docId, limit, nextPageToken) are already fully documented in the schema. The description adds no extra meaning beyond what the schema provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List tables in a document' clearly specifies the verb ('list'), the resource ('tables'), and the scope ('in a document'). It effectively distinguishes this tool from siblings like coda_list_documents and coda_list_columns, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios where another sibling tool would be more appropriate. Without explicit context, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Peek into the beginning of a page and return a limited number of lines
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document that contains the page to peek into | |
| pageIdOrName | Yes | The ID or name of the page to peek into | |
| numLines | Yes | The number of lines to return from the start of the page - usually 30 lines is enough |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It clearly indicates a non-mutating 'peek' operation and states that it returns a limited number of lines. However, it does not explicitly confirm read-only behavior, describe output format, or mention error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundancy. It front-loads the core purpose and every word contributes to understanding the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description conveys the essential action, but it lacks an explicit note about output format or return structure, especially since no output schema is provided. It is adequate for a minimal peek tool but leaves some gaps for an agent expecting clear return semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with clear descriptions (docId, pageIdOrName, numLines), so the schema provides the primary semantic detail. The description adds only marginal context (e.g., 'beginning' and 'limited'), but 100% schema coverage makes a baseline of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Peek') and resource ('page'), and clarifies the scope by saying 'beginning' and 'limited number of lines'. This distinguishes it from sibling tools like get_page_content, although it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for quickly inspecting a page without retrieving all content, but it does not explicitly state when to use it versus get_page_content or list_pages. There is no mention of exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Push a button column on a row in a table
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document | |
| tableIdOrName | Yes | The ID or name of the table | |
| rowIdOrName | Yes | The ID or name of the row | |
| columnIdOrName | Yes | The ID or name of the button column |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects, required permissions, or whether the action is asynchronous/destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, efficiently conveying the core action, though it could be slightly expanded for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 required parameters and no output schema, the description is insufficient. It fails to explain what 'pushing' entails, return behavior, or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond the schema, which warrants a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('push') and resource ('button column on a row in a table'), clearly distinguishing it from sibling tools like coda_update_row or coda_delete_row.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or post-conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a page in the current document
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document that contains the page to rename | |
| pageIdOrName | Yes | The ID or name of the page to rename | |
| newName | Yes | The new name of the page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral details beyond the action itself, such as whether renaming affects links, requires permissions, or has constraints. With no annotations, the description should provide more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename operation, the description is minimally adequate. However, it lacks behavioral context (e.g., effect on references) and no output schema is provided, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what's already in the schema, but it doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (rename) and the resource (page) within the current document, distinguishing it from related tools like coda_create_page or coda_duplicate_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to rename vs. duplicate or create a page. No preconditions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the content of a page with new markdown content
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document that contains the page to replace the content of | |
| pageIdOrName | Yes | The ID or name of the page to replace the content of | |
| content | Yes | The markdown content to replace the page with |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It correctly implies a destructive write operation (replacing content) but does not disclose details such as whether the operation is idempotent, reverting existing content, or any permission requirements. Basic transparency is present but insufficient for complex scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no extraneous words. Every word adds value, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter mutation tool with no output schema, the description covers the basic operation but lacks completeness. Missing details like whether the replacement is atomic, if partial updates are supported, or size limits. Adequate for straightforward use but not fully exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond the schema; it merely restates 'markdown content' already in the schema for the 'content' parameter. No clarification on formatting or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'replace' and resource 'content of a page', with the format 'markdown content'. It directly distinguishes from sibling tools like 'coda_append_page_content' which adds content rather than replaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., coda_append_page_content for appending, coda_peek_page for non-destructive view). The description lacks explicit context for when replacement is appropriate or prerequisites like document ownership.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve metadata given a browser link to a Coda object
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to resolve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states 'resolve metadata' without mentioning read-only guarantees, authentication needs, error handling, or what the returned metadata includes. This is a significant gap for an API tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. Every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's low complexity, the description is incomplete because it omits details about the returned metadata and has no output schema to compensate. An agent cannot reliably know whether this tool returns the needed information without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description merely says 'The URL to resolve', while the tool description adds 'browser link to a Coda object', clarifying the expected URL type. This adds meaningful context beyond the schema, though it stops short of specifying format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'resolve' and resource 'metadata given a browser link to a Coda object' clearly specify the action and scope. It distinguishes itself from sibling tools that list or get content by focusing on resolving a link to metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling tools. It does not mention alternatives, prerequisites, or situations where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a single row in a table
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document | |
| tableIdOrName | Yes | The ID or name of the table | |
| rowIdOrName | Yes | The ID or name of the row to update | |
| cells | Yes | JSON string of cells to update, e.g. [{"column": "Name", "value": "Bob"}, {"column": "Age", "value": 25}] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose whether the update is partial or full, or any side effects. Without annotations, the description carries full burden but only states the operation, missing significant behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no fluff. It could be slightly expanded, but it is appropriately concise for the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks context on return values, partial vs full update, and differentiation from sibling tools like coda_upsert_rows. It is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all parameters. The tool description adds nothing beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'a single row in a table', distinguishing it from siblings like coda_delete_row, coda_get_row, and coda_upsert_rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For instance, coda_upsert_rows could be more appropriate if a row may need to be created, but no such context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert or upsert rows into a table
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | The ID of the document | |
| tableIdOrName | Yes | The ID or name of the table | |
| rows | Yes | JSON string of rows to upsert, e.g. [{"cells": [{"column": "Name", "value": "Alice"}, {"column": "Age", "value": 30}]}] | |
| keyColumns | No | JSON string of column IDs or names to use as upsert keys, e.g. ["Name"] - optional |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action ('upsert'), but does not disclose behavioral details such as idempotency, conflict resolution, error handling, or required permissions. Since no annotations are provided, the description carries full burden but falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence—which is efficient for a straightforward operation. However, it may be too minimal for a complex tool with multiple optional parameters. The information is front-loaded but lacks necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is insufficient. It omits key behavioral details (e.g., how upsert keys work, when rows are inserted vs updated). For a data-modifying tool, more context is needed to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all parameters with descriptions (100% coverage). The description adds an example for 'rows' parameter, which is helpful but not essential. Baseline is 3 because schema already documents parameters adequately. The tool description does not provide additional parameter-level guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Insert or upsert rows into a table'. It uses a specific verb ('upsert') and resource ('rows into a table'), and it implies distinction from sibling tools like coda_update_row (singular row) and coda_insert_rows (if present). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not explain scenarios for choice between upsert and separate insert/update operations, nor does it mention prerequisites like keyColumns. Siblings include update and delete tools, but no comparative context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.7.1coda_append_page_content1 field changedInput schema / additionalPropertiesRemoved value: -falsecoda_create_page1 field changedInput schema / additionalPropertiesRemoved value: -falsecoda_delete_rowcoda_delete_rowscoda_duplicate_page1 field changedInput schema / additionalPropertiesRemoved value: -falsecoda_get_page_content1 field changedInput schema / additionalPropertiesRemoved value: -falsecoda_get_rowcoda_list_columnscoda_list_documents1 field changedInput schema / additionalPropertiesRemoved value: -falsecoda_list_pages2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / limit / maximumAdded value: +9007199254740991coda_list_rowscoda_list_tablescoda_peek_page2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / numLines / maximumAdded value: +9007199254740991coda_push_buttoncoda_rename_page1 field changedInput schema / additionalPropertiesRemoved value: -falsecoda_replace_page_content1 field changedInput schema / additionalPropertiesRemoved value: -falsecoda_resolve_link1 field changedInput schema / additionalPropertiesRemoved value: -falsecoda_update_rowcoda_upsert_rowsv1.0.0coda_append_page_contentcoda_create_pagecoda_duplicate_pagecoda_get_page_contentcoda_list_documentscoda_list_pagescoda_peek_pagecoda_rename_pagecoda_replace_page_contentcoda_resolve_linkScored across 19 tools
Every tool has a distinct action and target (e.g., create_page vs. duplicate_page vs. rename_page, delete_row vs. delete_rows vs. update_row). No two tools perform overlapping operations. Agents can clearly differentiate based on names and descriptions.
All tools follow the consistent pattern 'coda_verb_noun' using snake_case (e.g., 'coda_list_rows', 'coda_update_row'). Verbs are imperative and uniquely identify the action. The naming is predictable and uniform across the entire set.
With 19 tools, the server covers the main entities in Coda (documents, pages, tables, rows, columns) without being overwhelming. Each tool earns its place, providing both basic and advanced operations (e.g., upsert_rows, push_button). The count is well-scoped for a full-featured MCP server.
The tool set offers extensive CRUD coverage for pages and rows, including append, replace, peek, and upsert. Notable missing operations include deleting pages, creating tables/columns, and updating table structures, but the core workflows are well-supported. Minor gaps exist but do not severely impede common use cases.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
