Skip to main content
Glama
Sign In
vish288

mcp-coda

by vish288
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Coda Get Mutation Status

coda_get_mutation_status
Read-onlyIdempotent

Poll the status of an asynchronous Coda write operation using its requestId to confirm completion, processing state, or failure and retrieve error details.

Instructions

Check the status of an asynchronous mutation (write operation).

Coda write operations return 202 with a requestId. Use this tool to poll whether the mutation has completed, is still processing, or failed. Returns a completed boolean and any error details. Poll every 2 seconds, up to 30 seconds maximum.

Input Schema

NameRequiredDescriptionDefault
request_idYesThe requestId returned by a write operation (202 response)

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, and the description is consistent with them. Beyond that it discloses the polling contract (2s interval, 30s ceiling), the failure states it distinguishes (completed / processing / failed) and the return shape ('completed boolean and any error details') that no output schema provides. It does not say what to do once the 30s budget is exhausted.

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 what the tool does, then the trigger, the return value and the polling budget. Every sentence carries distinct information and nothing is padded.

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?

For a single-parameter polling tool with no output schema, the description covers the trigger, the lifecycle states and the return value, which is close to everything an agent needs. The one gap is the post-timeout behavior, which is left for the caller to guess.

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% and the single request_id parameter is already documented in the schema as 'the requestId returned by a write operation (202 response)'. The description restates that same origin rather than adding format or sourcing detail, so the schema does the heavy lifting and the baseline of 3 applies.

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?

States a specific verb and resource ('Check the status of an asynchronous mutation') and scopes it to write operations, which distinguishes it in substance from the sibling polling tool coda_get_export_status. It stops short of naming that sibling explicitly, so the routing is inferable rather than stated.

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?

Gives clear triggering context ('Coda write operations return 202 with a requestId. Use this tool to poll...') plus concrete operational guidance (poll every 2 seconds, up to 30 seconds). It never states when not to use it or names the alternative status tool for exports, so it falls short of a full when/when-not/alternative treatment.

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