Alcoven

Add rows to a table

add_rows

Logs something that happened in a table the team keeps, like a reply or a call in an outreach log, or a row in a CSV. Adds rows at the end of a table the team keeps, without asking the person to confirm: a CSV or TSV file on the project, as one new version under this person's name, or a sheet in Google Sheets the project may add rows to, named by its .source.md, where Google's version history shows the project's Alcoven address and Alcoven's Changes show this person. For tables the team keeps as things happen: a message sent, a reply in, a post up, a week's numbers. Each row is an object keyed by the table's column names, in any letter case; a column left out stays empty, and a Days column left out gets today's date where the person is. Nothing already in the table changes. Takes 1 to 100 rows a call. Returns the new rows' numbers and what the widgets that read the table say now.

Input Schema

Name	Required	Description
`did`	No	What the person did themselves in this work, in a few words they agree with: what they chose or decided, what they corrected, rewrote or wrote, what they checked and against what. Start with the verb, in the past tense, in their language: "Chose the three-step plan; fixed the March totals; rewrote the opening". Say nothing of what you did, what they did not do, how long it took, or a share of the work. Pass no did when their part was the request and the yes. Everyone who sees the change reads it, people outside the team included. At most 300 characters.
`read`	No	The § addresses you read for this work, kept with asked. Alcoven adds what it saw you read on this project since you last wrote on it, going back two hours at most.
`rows`	Yes	The rows, 100 at most, each an object keyed by the table's column names, like {"date": "2026-10-20", "what": "reply"}.
`again`	No	True when the same thing happened again: rows identical to ones this person added to the table in the last 10 minutes are then added too.
`asked`	No	What the person asked for, in their own words, as they said it: their request only, never the rest of the conversation, and left out when they do not want it shared. It goes on the project with the change, so everyone who sees the change, and their AIs, see why it was made.
`table`	Yes	The table: a CSV or TSV file's path or § address, like acme/gtm/outreach.csv, or the .source.md of a sheet in Google Sheets, like acme/gtm/outreach.source.md.
`project`	No	The project's slug, from open_project, like acme. Not needed when a § address names the project, or when the person is on one project.
`asked_from`	No	Where the request came from, when the person says so, in a few words: "Tuesday's call with the bank", "Ines's email".

Output Schema

Name	Required	Description	Default
`added`	Yes
`sheet`	No
`address`	Yes
`last_row`	Yes
`readings`	Yes
`warnings`	Yes
`first_row`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

addedInput schema / properties / did

Added value: +{
+  "description": "What the person did themselves in this work, in a few words they agree with: what they chose or decided, what they corrected, rewrote or wrote, what they checked and against what. Start with the verb, in the past tense, in their language: \"Chose the three-step plan; fixed the March totals; rewrote the opening\". Say nothing of what you did, what they did not do, how long it took, or a share of the work. Pass no did when their part was the request and the yes. Everyone who sees the change reads it, people outside the team included. At most 300 characters.",
+  "maxLength": 300,
+  "type": "string"
+}

First observedOct 22, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Beyond the annotations, the description discloses important behavior: rows are appended at the end, no confirmation is requested, existing table contents are not changed, new versions are attributed to the person, and the call returns the new row numbers plus widget state. It also states a row-count limit, though that limit is inconsistent with the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long and repetitive, repeating the phrase 'a table the team keeps' and packing several ideas into run-on sentences. The important append-only and row-limit details are buried rather than front-loaded.

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 an 8-parameter mutation tool with rich schema descriptions, annotations, and an output schema, the description covers the main purpose, usage context, side effects, row semantics, and return behavior. Its main flaw is the conflicting row-count limit, which could mislead an agent about a key constraint.

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 coverage is 100%, so the schema already carries parameter meaning. The description adds useful semantics for rows, such as case-insensitive column keys, omitted columns staying empty, and a default Days value, but it also says '1 to 100 rows a call' while the schema allows up to 1000 items.

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?

The description states a specific verb and resource: it adds rows to a table, with concrete examples such as CSV/TSV files and Google Sheets. It is clearly separable from adjacent tools like add_note or add_document by its table-row focus, though it does not explicitly name those alternatives.

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?

It gives a clear usage context: for tables the team keeps as things happen, such as messages sent, replies received, or weekly numbers. It does not state when not to use it or explicitly name alternative tools, which keeps it short of a 5.

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

All Alcoven tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?