Skip to main content
Glama
cmssy-io

@cmssy/mcp-server

Official
by cmssy-io

import_records

Bulk-import up to 1000 records into a data model, creating each row or updating existing matches using an upsert key to prevent duplicates. Returns per-row results and errors.

Instructions

Bulk-import records into a data model (up to 1000 rows). Without upsertKey each row CREATES a record; with upsertKey (a unique field or the product SKU field) a row matching an existing record UPDATES it instead, so a repeated sync does not duplicate. A translatable field takes a language map ({ title: { en: '...', no: '...' } }); a language the workspace has not enabled is rejected. Returns importedCount (created), updatedCount, per-row errors, and per-row record ids with CREATED / UPDATED / UNCHANGED.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsNoArray of plain objects keyed by the model's field keys. A translatable field (localized: true on the model) takes a language map, e.g. { title: { en: 'Ball bearing', no: 'Kulelager' } }. Without upsertKey each row creates a record, so every language the row should have must be in it. A row matched through upsertKey is merged into the existing record: only the keys the row carries change.
upsertKeyNoA key from the model's uniqueFields, or its product skuField. A row whose value matches an existing record updates that record; any other row is created, so re-running the same file does not duplicate it. Every row must carry the key. Not allowed on member (auth) models.
modelIdOrSlugNoTarget model id or slug

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.73.1

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it does so thoroughly. It discloses the create/update side effects, upsert merge semantics, rejection of workspace-disabled languages, and the exact return payload including importedCount, updatedCount, per-row errors, and per-row statuses. This is rich behavioral disclosure beyond any structured annotations.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: one sentence for the core operation and limit, one for upsert semantics, one for translatable-field handling and return values. The most important information is front-loaded, and the content is organized logically from behavior to output.

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 a bulk mutation tool with no output schema, the description is complete: it covers input limits, create vs update behavior, duplicate avoidance, field-level language requirements, and the full return structure. An agent has enough information to invoke the tool and interpret its results correctly.

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 100%, and the schema descriptions already explain rows, upsertKey, and modelIdOrSlug in detail, including the language map example and merge behavior. The tool description reinforces these points and adds return-value context, but does not substantially go beyond what the schema already provides. Baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Bulk-import records into a data model'. It also specifies the 1000-row limit and distinguishes the tool's bulk upsert behavior from single-record siblings like create_record and update_record. This makes the tool's purpose unambiguous and differentiates it from related operations.

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 clearly explains when to use upsertKey versus not, and the repeated-sync scenario that motivates bulk import. It does not explicitly name alternative tools such as create_record or update_record, but the bulk vs single-record distinction is strongly implied. This is clear usage guidance with only a minor gap in explicit exclusions.

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