gdocs-mcp

Share a doc (person or link)

share_doc

Grants access to a Google Doc by sharing it with a person via email as reader, commenter, or writer, or by setting anyone-with-link permissions; use role none to disable link sharing.

Instructions

Grant access to a Google Doc. With email, share with that person as reader/commenter/writer (optionally sending a notification). Without email, set anyone-with-link access to that role, or role "none" to disable link sharing. (To revoke a specific person’s access, use unshare_doc.)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "share_doc"
  }
}

Input Schema

Name	Required	Description
`path`	Yes	The doc: a Drive id or URL, or /folder/doc. A tab path names its doc.
`role`	No	access level; default writer. "none" (link only) disables link sharing.
`email`	No	person to share with; omit to set anyone-with-link access instead
`notify`	No	when sharing with a person, send a notification email (default true)
`account`	No	Google account email to use. Defaults to GDOCS_DEFAULT_ACCOUNT, or the sole account.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.0.0Oct 31, 2026

removedInput schema / properties / documentId
```
Removed value: -{
-  "type": "string"
-}
```

addedInput schema / properties / path

Added value: +{
+  "description": "The doc: a Drive id or URL, or /folder/doc. A tab path names its doc.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "documentId"
-]New value: +[
+  "path"
+]

First observedv0.1.1Aug 1, 2026

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral burden and does well by disclosing that this is an access-granting mutation, that person sharing can optionally send a notification, and that role "none" disables link sharing. It does not mention required account permissions, idempotence, or what the operation returns, but the core state-changing behavior is clear.

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?

The description is three tight sentences with no filler. The main action is front-loaded, followed by the person-sharing and link-sharing branches, with the alternative tool noted parenthetically at the end.

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 five-parameter tool with 100% schema description coverage and no output schema, the description supplies the missing behavioral context: the distinction between person and link sharing, notification behavior, and the meaning of role "none". Nothing essential for correct invocation is absent.

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 the baseline is 3, but the description adds meaningful semantics beyond the schema by explaining the `email` presence/absence branching and the effect of role "none" on link sharing. The `notify` behavior for person sharing is also clarified, though `path` and `account` semantics are left to the schema.

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?

The description states a specific verb and resource: "Grant access to a Google Doc." It clearly distinguishes the person-sharing mode (`email`) from the link-sharing mode (no `email`) and explicitly names the sibling tool for revocation, `unshare_doc`. An agent can identify the tool's function and boundaries without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is explicitly conditional: provide `email` to share with a person, omit `email` to set anyone-with-link access. It also states that role "none" disables link sharing and directs revocation of a specific person's access to `unshare_doc`, covering both when to use this tool and when to use an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.