Skip to main content
Glama
SGromych

DataForge Semantic MCP Server

by SGromych

df_bulk_write_measures

Bulk create or update DataForge measures in one call. Items with an id update, items without create; each applied in its own transaction with partial results and failure details.

Instructions

WRITES TO DATAFORGE. Create and/or update many measures in one call. An item with id is updated, an item without one is created. Items are applied in order, each in its own transaction: a partial result comes back with status=partial and a failed[] array addressing rows by index.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
measuresYes
project_idYesDataForge project id
version_idYesProject version id
idempotency_keyNoOptional UUID v4. Reusing a key within 24 hours replays the original response instead of applying the change twice. One is generated automatically when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description reveals meaningful behavioral details: items are applied in order, each in its own transaction, and partial failures return status=partial with a failed[] array indexed by row. This is valuable operational context that an agent needs to interpret results correctly.

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?

Three short sentences with no filler. The mutation warning is front-loaded, the core behavior follows, and the failure semantics close the description efficiently. Every sentence earns its place.

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 a write operation with no output schema, the description does well to explain partial-failure behavior and per-item transactions. It could go further by describing the full success response shape, but the combination of schema descriptions and this behavioral summary gives an agent enough to invoke and interpret the call.

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 already high at 75%, so the baseline is 3. The description adds important semantic meaning by explaining that an item with `id` is updated and one without is created, plus ordering and transaction semantics that affect how the measures array is processed.

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 states a specific action: 'Create and/or update many measures in one call.' This clearly identifies the resource (measures) and scope (bulk), distinguishing it from siblings like df_write_measure (single measure) and df_bulk_write_dimensions/facts (different resource).

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 communicates that this is the bulk path for creating/updating measures, which implies use when multiple measures need writing at once. It does not explicitly name alternatives like df_write_measure or state when not to use it, but the 'many measures in one call' wording provides clear context.

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