Skip to main content
Glama
informatics-isi-edu

Deriva MCP Server

Official

add_feature_value

Add feature values (terms or asset RIDs) to domain records in one batch. Handles simple single-value features and records provenance for auditability.

Instructions

Add feature values to one or more domain objects.

Associates feature values (terms, assets, or other) with target records. Accepts a list of entries, each mapping a target RID to a value. All entries are inserted in a single batch for efficiency.

If an execution is active, it will be used for provenance. Otherwise, provide an execution_rid explicitly.

For simple features (single term or asset column): Use this tool — each entry needs only target_rid and value.

For complex features (multiple columns per record): Use add_feature_value_record instead, which accepts arbitrary field dicts.

Args: table_name: Table the target records belong to (e.g., "Image"). feature_name: Name of the feature (e.g., "Diagnosis"). entries: List of dicts, each with: - target_rid (str): RID of the target record to annotate. - value (str): The feature value — a term name or asset RID. execution_rid: Execution RID for provenance (uses active if not provided).

Returns: JSON with status, feature_name, count, execution_rid, rids.

Examples: # Single value add_feature_value("Image", "Diagnosis", [{"target_rid": "1-ABC", "value": "Normal"}])

# Batch values
add_feature_value("Image", "Diagnosis", [
    {"target_rid": "1-ABC", "value": "Normal"},
    {"target_rid": "1-DEF", "value": "Abnormal"},
    {"target_rid": "1-GHI", "value": "Normal"},
])

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
entriesYes
table_nameYes
feature_nameYes
execution_ridNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/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 well by disclosing batch behavior, provenance handling, accepted value types (term name or asset RID), and return format. It does not cover error conditions or idempotency, but the provided detail is substantial for a mutation tool.

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 well-organized with sections for Args, Returns, and Examples. It is slightly long but every section earns its place—the examples clarify usage, and the simple/complex distinction is essential. The structure aids comprehension without redundancy.

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?

Given no annotations and no visible output schema in the prompt, the description provides a complete picture: purpose, parameter semantics, return values, and two illustrative examples. It covers both single and batch usage and the provenance option, leaving 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 description coverage is 0%, so the description fully compensates. It explains table_name as the table the target records belong to, feature_name as the feature name, entries as a list of dicts with target_rid and value, and execution_rid with its default behavior. This adds significant meaning beyond 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 a specific verb and resource: 'Add feature values to one or more domain objects.' It further clarifies the action as associating feature values with target records, and explicitly distinguishes itself from the sibling tool add_feature_value_record by contrasting simple vs. complex features.

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?

Explicit guidance is provided on when to use this tool vs. the alternative: 'For simple features... Use this tool' and 'For complex features... Use add_feature_value_record instead.' It also explains the execution_rid provenance behavior (uses active execution when not provided) and batch insertion, giving clear context.

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