Skip to main content
Glama
Sign In
vish288

mcp-coda

by vish288
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Coda Add Permission

coda_add_permission

Grant a Coda doc permission to a user by email or domain, setting access to readonly, write, comment, or none. Use it to manage sharing or remove implicit access.

Instructions

Add a permission entry to a Coda doc.

Grants access to a user by email or to an entire domain. Specify either principal_email or principal_domain (not both). The access level controls what the principal can do: readonly, write, comment, or none (removes implicit access). Returns the created permission entry.

Input Schema

NameRequiredDescriptionDefault
accessYesAccess level to grant
doc_idYesThe doc ID to add permission to
principal_emailNoEmail address of the user to grant access to
principal_domainNoDomain to grant access to (e.g. 'example.com')
suppress_notificationNoIf True, don't send an email notification

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

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

Annotations only supply readOnlyHint=false and openWorldHint=true, so the description carries most of the burden and does add real context: it discloses the side effect that access 'none' removes existing implicit access rather than merely setting a level, and that a permission entry is returned. It omits auth/permission prerequisites (who may grant access) and the default notification behavior is left to the schema, so it is strong but not complete.

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 action, then constraints, then enum semantics, then the return value. No sentence is filler and none restates the schema verbatim.

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, explaining that the created permission entry is returned is the right call, and the mutation's side effects are covered. Missing only operational context an agent might want — required permission level to grant access and whether notifications fire by default (implied only through the schema).

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 description coverage is 100%, so the baseline is 3, but the description genuinely adds meaning the schema does not: it declares principal_email and principal_domain mutually exclusive, and it glosses the 'none' enum value as removing implicit access. That is value beyond the structured fields.

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 and resource ('Add a permission entry to a Coda doc') and immediately scopes what the operation does — grants access to a user or domain. This is clearly distinguishable from sibling tools like coda_list_permissions and coda_delete_permission without opening any schema.

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 the operative selection rule for the two principal parameters — 'Specify either principal_email or principal_domain (not both)' — which is genuine when-to-use guidance. It does not explicitly route the agent away from siblings (e.g. use coda_delete_permission to revoke, coda_search_principals to find a user first), so it stops short of full alternative coverage.

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