Skip to main content
Glama

bulk_create_rows

Append many rows to a workspace's table surface in ONE call — the bulk version of create_row. Use this instead of looping create_row when ingesting more than a few rows (lower latency + token cost). Pass rows as an array of { data: {...} } objects, each data a column-name → value map (same shape create_row takes). Up to 500 rows per call. WRITE AS YOU GO on long jobs (scraping, enrichment, any list you build over many steps): send each batch of about 25-50 rows as soon as it is ready, never one call at the end, so a hang, timeout or restart loses one batch at most. ALL-OR-NOTHING: if any row fails the whole batch is rolled back, so on error you can safely resend the entire batch. Targets one surface for the whole batch (surface_slug, or the workspace's primary table surface). auto_create_columns: true appends a text column for every unmapped key across the batch (one schema extension). Returns { created, rows, created_columns }. The response lists unmapped_fields (keys that match no column, stored but not shown in the table) with a warning, the same signal create_row gives; pass auto_create_columns: true to add those columns instead.

Input Schema

NameRequiredDescriptionDefault
rowsYesRows to create. Each item is an object with a `data` field: `{ "data": { "title": "...", "status": "drafted" } }`. 1-500 items.
slugYesThe workspace slug (bare or org-prefixed).
surface_slugNoOptional target table surface slug (use list_surfaces). Omit to use the workspace's primary table surface. The whole batch lands on this one surface.
auto_create_columnsNoWhen true, append a text column for every key (across all rows) that doesn't map to an existing column, in one schema extension. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Given the lack of annotations, the description performs critical behavioral disclosure, including the 500-row limit, the ALL-OR-NOTHING rollback on error, and the operational risks of batch processing. It also details how `auto_create_columns` modifies the schema in real-time.

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 lengthy but highly effective, logically chunking information into use case, strategy, error handling (ALL-OR-NOTHING), and specific feature details (`auto_create_columns`). It is efficiently written, with zero wasted space.

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?

It provides a comprehensive overview of the operational mechanics, explicitly stating the response payload structure and addressing the dual signaling of unmapped fields (warning vs. automated column creation).

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?

While the input schema covers most parameters, the description clarifies the structure of the `rows` array (array of objects with a `data` field) and explains the scope of `surface_slug` (optional, defaults to primary surface), adding necessary context beyond simple schema definition.

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 identifies the tool as the 'bulk version of create_row' used to append many rows to a workspace table surface in one call. It distinguishes its purpose by highlighting its use as a bulk operation to the user.

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?

It provides explicit usage instructions, telling users to use it instead of looping create_row for performance (latency + token cost). It further advises on workflow strategy for large jobs, recommending batches of 25-50 rows sent progressively.

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.