Skip to main content
Glama
informatics-isi-edu

Deriva MCP Server

Official

create_feature

Create feature definitions to link labels, scores, or derived assets to domain objects, enabling type-safe ML data engineering.

Instructions

Create a new feature definition to associate metadata with domain objects.

Features enable ML data engineering by linking labels, scores, or derived assets to domain objects. The feature definition specifies what types of values are valid.

What this creates:

  1. A new association table in the domain schema to store feature values

  2. A dynamically generated Pydantic model class for creating validated feature instances

The Pydantic model class (accessible via feature_record_class() in Python) provides type-safe construction of feature records with automatic validation against the feature's definition.

Feature types:

  • Term-based: Values come from controlled vocabularies (e.g., diagnosis labels)

  • Asset-based: Values reference asset files (e.g., segmentation masks)

  • Mixed: Can reference both terms and assets

The feature automatically tracks which Execution produced each value for provenance.

Args: table_name: Table to attach the feature to (e.g., "Image", "Subject"). feature_name: Unique name for the feature (e.g., "Diagnosis", "Quality_Score"). comment: Description of what this feature represents. terms: Vocabulary table names whose terms can be values (e.g., ["Diagnosis_Type"]). assets: Asset table names that can be referenced (e.g., ["Segmentation_Mask"]). metadata: Additional columns or table references to include in the feature. Each item can be: - A string: Treated as a table name (adds a foreign key reference) - A dict: Column definition with at minimum "name" and "type" keys. The "type" value should be a dict like {"typename": "float4"}. Valid type names: text, int2, int4, int8, float4, float8, boolean, date, timestamp, timestamptz, json, jsonb. Optional keys: "nullok" (bool), "default", "comment".

Returns: JSON with status, feature_name, target_table.

Examples: # Simple term-based feature create_feature("Image", "Diagnosis", "Clinical diagnosis label", terms=["Diagnosis_Type"])

# Feature with a confidence score column
create_feature("Image", "Diagnosis", "Diagnosis with confidence",
    terms=["Diagnosis_Type"],
    metadata=[{"name": "confidence", "type": {"typename": "float4"}}])

# Feature referencing another table
create_feature("Image", "Review", "Review annotations",
    terms=["Review_Status"],
    metadata=["Reviewer"])

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
termsNo
assetsNo
commentNo
metadataNo
table_nameYes
feature_nameYes

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. It discloses that creation results in a new association table and a generated Pydantic model, and that provenance tracking is automatic. This goes beyond a simple 'create' statement and gives the agent a clear picture of side effects, though it omits details like authorization requirements or failure conditions.

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 sections for purpose, created artifacts, feature types, args, return, and examples. Every sentence adds context—even the Pydantic model explanation is relevant to the tool's behavior. The front-loaded summary ensures the core purpose is immediately clear.

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 tool with six parameters and no annotations, the description covers all parameter semantics, return structure, and importantly clarifies the effects of the operation. The presence of an output schema doesn't reduce the need for the behavioral context supplied here, and the description provides ample examples to guide usage.

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?

The input schema only lists names and types; the description provides semantic depth: it explains which table the feature attaches to, what 'terms' and 'assets' refer to, and gives a detailed breakdown of the 'metadata' parameter including valid type names and dict keys. This fully compensates for the 0% schema coverage.

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 'Create a new feature definition to associate metadata with domain objects,' which clearly specifies the verb ('create') and the resource ('feature definition'). It distinguishes itself from siblings like 'delete_feature' and 'add_feature_value' by focusing on the initial creation act and describing the resulting artifacts.

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 explains the purpose of features in ML data engineering and describes three feature types, which helps the agent understand when to use this tool. However, it does not explicitly contrast with alternative approaches or state when not to use it, so it stops short of a 5.

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