Skip to main content
Glama
SGromych

DataForge Semantic MCP Server

by SGromych

df_import_version_from_git

DestructiveIdempotent

Import a version from a Git repository into DataForge, creating a new version or replacing an existing one. Preview before importing to avoid permanent data deletion.

Instructions

PERMANENTLY DELETES DATA IN DATAFORGE. Import a version from Git. target.method=create makes a new version; target.method=replace OVERWRITES THE VERSION IN THE PATH entirely. Run df_preview_import first. conflict_strategy=overwrite also applies deletions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNo
branchYes
targetYes
optionsNo
project_idYesDataForge project id
version_idYesProject version id
commit_hashNo
connection_idNo
authenticationNoGit credentials, sent over TLS. Never logged, never returned.
repository_urlYes
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.
conflict_strategyNosmart_merge

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true IDs, but the description adds substantial behavioral detail beyond that flag: permanent deletion, full overwrite of the version in the path, and the fact that conflict_strategy=overwrite also applies deletions. It also conveys that replace is destructive while create is not, which is crucial for an agent deciding how to set target.method. This goes above and beyond the annotation signals.

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 compact and front-loaded with the most critical warning about permanent data loss, then proceeds to the main purpose and method semantics. Every sentence carries weight: the warning, the create vs. replace distinction, the prerequisite preview step, and the deletion implication of conflict_strategy. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex tool with 12 parameters, nested objects, and no output schema. The description covers the critical behavioral aspects (destructive nature, method semantics, preview prerequisite) but omits guidance on other important parameters like authentication, options, commit_hash, and connection_id. Given the schema's own low description coveragetemp, some gaps remain. It is adequate for the high-risk aspects but not fully complete for a complex import operation.

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 low at 33%, and many parameters (e.g., path, commit_hash, connection_id, all of the options) are undocumented in both schema and description. The description does add real meaning to target.method (create vs. replace) and conflict_strategy=overwrite, which is helpful, but it leaves the agent to infer the purpose of most parameters from names alone. It partially compensates for the schema gap but does not fully cover it.

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 stark warning, then clearly states the tool's function: 'Import a version from Git.' It goes further by distinguishing the two target.method behaviors (create vs. replace, where replace overwrites the version entirely) and explicitly notes that conflict_strategy=overwrite also applies deletions. This makes the tool's purpose and destructive consequences unmistakable, and differentiates it from related import/export tools among the siblings.

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 provides the key prerequisite 'Run df_preview_import first,' which tells the agent when to call this tool relative to a sibling. It also implicitly warns against use in non-destructive contexts by highlighting permanent deletion and overwrite behavior. However, it does not name alternatives (e.g., df_import_version_from_file) or state when to choose this tool over them, so it falls short of full guidance.

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