Skip to main content
Glama

fill_ai_cells

Save up to 200 answers to an AI column, each with the row and basis next_ai_cells gave it. An answer outside the column's choices, or to a prompt that has since changed, comes back with a reason. Each value is saved as generated, with the instruction and model. Needs a token.

Input Schema

NameRequiredDescriptionDefault
slugYes
modelYesThe model that answered, like the one you are
columnYesThe AI column's id, from next_ai_cells
answersYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

Adds real context beyond the annotations: a hard 200-answer cap, per-answer partial failure with a returned reason (so the write is not all-or-nothing), values stored as generated along with the instruction and model, and an explicit token/auth requirement. Annotations already cover the mutation and open-world profile, so this is a strong supplement.

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?

Four short sentences, front-loaded with the action and the batch limit, then failure behavior, then persistence and auth. Dense and free of filler, though the final 'Needs a token' is abrupt enough to read as an afterthought.

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, the description carries the burden of return behavior and does so for the failure path (answers come back with a reason). It does not describe what a successful response looks like, and slug goes unexplained, leaving a small residual gap for a 4-parameter write tool.

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 only 50%, but the description compensates well for the key fields: it explains that row and basis originate from next_ai_cells, and that model records which model produced the value. The one gap is `slug`, which is not explained in either the description or 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 — 'Save up to 200 answers to an AI column' — and identifies the upstream source (next_ai_cells) that produces the payload. It is clearly distinct from the sibling fill_cells, which would fill ordinary cells rather than AI-generated answers.

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?

The description establishes the workflow ordering implicitly by requiring each answer to carry 'the row and basis next_ai_cells gave it', so the agent knows to call next_ai_cells first. It also states the failure conditions (answer outside the column's choices, prompt changed since). It stops short of an explicit 'use this instead of X' exclusion, so it's a 4 rather than a 5.

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.