Skip to main content
Glama
informatics-isi-edu

Deriva MCP Server

Official

increment_dataset_version

Increment a dataset's semantic version (major, minor, or patch) to capture a snapshot of catalog changes. Use after data or schema modifications to create a reproducible checkpoint with a description.

Instructions

Manually increment a dataset's semantic version (major.minor.patch).

Description Handling (follows generate-descriptions prompt guidelines):

  1. If user provides description: Use it, potentially improving for clarity

  2. If description is empty: Generate from conversation context:

    • What catalog operations were performed since last version?

    • What was the user's stated goal for these changes?

    • Summarize the changes made (e.g., "Added X, fixed Y, modified Z")

Description Generation Guidelines:

  • Include WHAT changed (added images, fixed labels, new features)

  • Include WHY if known (QA review, batch import, schema update)

  • Include IMPACT if relevant (affects N records, breaking change)

  • Use markdown for complex descriptions (lists, tables)

Use this tool when:

  • You've modified catalog data and want changes visible in a dataset

  • You need to capture a snapshot of the current catalog state

  • You want to create a reproducible checkpoint before making changes

Args: dataset_rid: The RID of the dataset. description: What changed in this version. If empty, LLM should generate from context. Good descriptions include: - What was added, modified, or fixed - Why the change was made (if known) - Impact on users of this dataset

    Examples of good descriptions:
    - "Added 500 new labeled training images from batch 3"
    - "Fixed incorrect labels on 23 images identified in QA review"
    - "Schema change: added 'quality_score' column to Image table"
    - "Captured snapshot before label correction workflow"

component: Which part to increment: "major", "minor", or "patch".
    - major: Breaking changes or schema modifications
    - minor: New data added or non-breaking changes (default)
    - patch: Bug fixes or label corrections

Returns: JSON with status, new_version, previous_version, dataset_rid, description.

Examples: increment_dataset_version("1-ABC", "Added quality labels to all images", "minor") increment_dataset_version("1-ABC", "Fixed mislabeled cat images", "patch") increment_dataset_version("1-ABC", "Schema change: new metadata columns", "major")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
componentNominor
dataset_ridYes
descriptionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

With no annotations, the description carries the full transparency burden. It discloses the mutation implied by 'increment', describes the return JSON structure, and explains how the description parameter is auto-generated if empty. It lacks explicit warnings about permissions or side effects, but provides substantial behavioral context.

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 long but well-structured with headers, bullets, and examples. Each section (purpose, when to use, args, returns, examples) earns its place and adds operational value. The main verb is front-loaded.

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?

The description covers purpose, usage criteria, parameter semantics, return format, and worked examples. Given the tool's moderate complexity and the presence of an output schema, this description is fully self-sufficient and leaves no major gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must document all parameters. It thoroughly explains dataset_rid, description (with examples of good descriptions), and component (with definitions of major/minor/patch). This fully compensates for the bare 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?

The description opens with 'Manually increment a dataset's semantic version (major.minor.patch)', providing a specific verb and resource. This clearly distinguishes it from sibling dataset tools, which focus on columns, schemas, or catalog operations, rather than versioning.

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 includes a 'Use this tool when' section listing three specific scenarios, such as modifying catalog data or wanting a reproducible checkpoint. It does not explicitly state when not to use it or mention alternatives, so it misses the top score.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/informatics-isi-edu/deriva-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server