Skip to main content
Glama

Add rows to a log sheet

well_append_rows_to_drive_sheet

Add rows at the end of a log sheet that Well keeps in the Well folder of the workspace's connected Google Drive. Call it when the user asks to log, record or add rows to a Google Sheet.

Well can write only to a sheet it created in its own Drive folder. sheet_name names that sheet: the first call with a new name creates it in the Well folder, and every next call with the same name adds rows to the same sheet. Well cannot write to a sheet the user made or picked: say so and offer a Well log sheet instead.

Pass rows: one array of cells per row, in column order. Every cell is stored as typed; a value that starts with "=" stays text. The user confirms on a card before the rows are added.

When each row carries an id that names it, such as a transaction id, pass key_column: the number of the column that holds the id, 1 for column A. Well then reads that column of the sheet and adds only the rows whose id is not in it yet, and a row whose id repeats an earlier row of the same call is added once. So a repeated call, or a call whose window overlaps an earlier one, adds each row once. Two calls at the same moment on the same sheet can both add a row with the same id. The result gives rows_appended and rows_skipped, the rows left out because their id was in the sheet or earlier in the call. outcome: "already_logged" means every row was already in the sheet: it is a success, and no row was added. outcome: "too_many_rows_to_check" means the sheet holds more than 20000 rows, empty rows included, so Well cannot check it: no row was added, so offer a sheet with a new name. Without key_column, each call adds its rows once more, so never repeat a call that returned appended.

Only the member who connected Google Drive can write to it; a call by another member returns outcome: "not_connection_owner". When the caller connected several Drive accounts, the call returns outcome: "connection_choice_needed" with workspace_connector_ids: ask which one, then call again with workspace_connector_id.

Tell the user the message the result carries and give web_view_link when present. On needs_reconnect, ask the user to reconnect Google Drive. On unconfirmed, ask the user to check the sheet before a new try.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Input Schema

NameRequiredDescriptionDefault
rowsYesThe rows to add, each an array of cells in column order.
key_columnNoThe column that holds the id of each row, 1 for column A. Only the rows whose id is not in that column of the sheet yet are added. Every row must carry a non-empty id in that column.
sheet_nameYesThe name of the Well log sheet in the Well Drive folder. A new name creates the sheet.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
idempotency_keyNoOptional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.
workspace_connector_idNoThe Google Drive connection to write to, only when several Drive accounts are connected.

Output Schema

NameRequiredDescriptionDefault
errorNo
messageNo
outcomeNo
successYes
rows_skippedNoWith key_column: the rows left out because their id was already in the sheet or earlier in the call.
rows_appendedNo
sheet_createdNo
web_view_linkNo
spreadsheet_idNo
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.
workspace_connector_idNo
workspace_connector_idsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedOutput schema / properties / resolved_workspace / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / resolved_workspace / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Changed1 schema field changed
    • changedOutput schema / properties / newly_connected / description
      Previous value: -"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. Start the reply with one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."New value: +"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."
  3. Changed3 schema fields changed
    • addedInput schema / properties / key_column
      Added value: +{
      +  "description": "The column that holds the id of each row, 1 for column A. Only the rows whose id is not in that column of the sheet yet are added. Every row must carry a non-empty id in that column.",
      +  "maximum": 50,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • changedOutput schema / properties / outcome / enum
      Previous value: -[
      -  "appended",
      -  "not_connected",
      -  "no_well_folder",
      -  "connection_choice_needed",
      -  "not_connection_owner",
      -  "needs_reconnect",
      -  "failed",
      -  "unconfirmed"
      -]New value: +[
      +  "appended",
      +  "already_logged",
      +  "too_many_rows_to_check",
      +  "not_connected",
      +  "no_well_folder",
      +  "connection_choice_needed",
      +  "not_connection_owner",
      +  "needs_reconnect",
      +  "failed",
      +  "unconfirmed"
      +]
    • addedOutput schema / properties / rows_skipped
      Added value: +{
      +  "description": "With key_column: the rows left out because their id was already in the sheet or earlier in the call.",
      +  "type": "number"
      +}
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes far beyond the annotations: user confirmation on a card before rows are added, a 20000-row scan ceiling, a race window when two calls hit the same sheet, connection-owner-only writes, and the full outcome vocabulary (already_logged, too_many_rows_to_check, not_connection_owner, connection_choice_needed, needs_reconnect, unconfirmed) with the follow-up action for each. This is exactly the kind of operational context annotations cannot carry.

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?

Purpose and the write-restriction caveat are front-loaded, and the dense paragraphs each carry non-obvious behavior. Some trimming is possible: rows_appended/rows_skipped and the outcome codes are partly restated despite an output schema, and the closing line says 'this read will not guess', which reads like it was copied from a read tool and briefly muddies the write framing.

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 an 8-parameter open-world write with an output schema, the description covers what an agent needs to call it correctly: creation semantics, dedup strategy, hard limits, authorization failures, retry guidance ('never repeat a call that returned appended'), and multi-workspace routing. Nothing material is missing.

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 baseline is 3, but the description adds real meaning: each cell is stored as typed and a leading '=' stays text, key_column deduplicates against the sheet column and within a single call, and sheet_name creates the sheet on first use with a new name. It also explains the workspace_id/workspace_connector_id branch, though conversation_id and idempotency_key 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?

States a specific verb and resource ('Add rows at the end of a log sheet'), plus the exact scope: a sheet Well keeps in the Well folder of the connected Drive. That distinguishes it from siblings like well_save_file_to_drive or well_export_rows_as_file without the agent needing to open a 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?

Gives an explicit trigger ('when the user asks to log, record or add rows to a Google Sheet') and an explicit exclusion with a fallback ('Well cannot write to a sheet the user made or picked: say so and offer a Well log sheet instead'). It also states when to pass key_column versus not, and that no workspace call is needed first when the token authorizes one workspace.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources