Skip to main content
Glama

insert_doc_person_chip

Insert a person smart chip in Google Docs by specifying the email and position. The chip displays the person's name and contact card when the document is opened.

Instructions

Insert an @mention-style person chip at a specific position in a document.

Writes the person's email as linked text (href = mailto:<email>). When Google Docs renders the document, that linked-email pattern is auto-converted into a rich person chip — a small inline pill showing the person's name, avatar, and hover card. The chip is a "smart chip" and shows up in get_doc_smart_chips as type person.

Requires OAuth scope: https://www.googleapis.com/auth/documents (write). For a Drive-file chip instead, use insert_doc_file_chip. For a plain hyperlink, use insert_doc_link.

Note: The chip only renders correctly once a collaborator or the owner opens the doc in the Google Docs UI — Docs does the text-to-chip conversion client-side on render. The API always stores the raw linked email. Person resolution uses the email only; if the email doesn't match a Google account visible to the viewer, it falls back to plain linked text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
user_google_emailYes
document_idYesGoogle Docs document ID (from the URL after `/document/d/`).
emailYesEmail address of the person to @mention, e.g., `alice@example.com`. Must be a valid email; the Docs client uses it to look up the contact card at render time.
indexNo1-based character position in the document body where the chip is inserted. Default `1` = start of body. Use `inspect_doc_structure` to find exact indices for non-trivial placements. Ignored contextually when `tab_id` is set — index resolves within the specified tab's content.
tab_idNoOptional tab ID to target a specific tab. Get it from `list_doc_tabs`. Omit for single-body (legacy) documents.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

No annotations exist, so the description carries full burden. It discloses that the underlying representation is a linked email, the client-side conversion to a rich chip, fallback behavior, and how the chip appears in `get_doc_smart_chips`. It does not mention reversibility or idempotency, but overall is thorough.

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?

The description is moderately sized and well-structured: primary action first, then technical details, scope requirement, sibling references, and a note. It could be slightly more terse, but every sentence adds value.

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?

Given the moderate parameter count (5), presence of output schema, and lack of annotations, the description adequately covers behavior, requirements, and alternatives. It explains the rendering nuance that is critical for correct usage, and the existence of an output schema covers return values.

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 80%, so baseline is 3. The tool's main description does not add parameter-specific semantics beyond what the schema already provides. For example, the `index` parameter's default and use with `tab_id` is explained in the schema, not in the description.

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 clearly states the action ('Insert an @mention-style person chip'), the resource (person chip), and the context (specific position in a document). It immediately distinguishes from siblings by naming `insert_doc_file_chip` and `insert_doc_link` as alternatives.

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?

The description explicitly states the required OAuth write scope and provides clear guidance on when to use alternative tools (Drive-file chip, plain hyperlink). It also notes a behavioral quirk (chip only renders client-side) that affects usage decisions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HuntsDesk/ve-gws'

If you have feedback or need assistance with the MCP directory API, please join our Discord server