Skip to main content
Glama
informatics-isi-edu

Deriva MCP Server

Official

rag_search

Search Deriva documentation, catalog schema, and data semantically to locate tables, features, vocabularies, datasets, and API guidance.

Instructions

Search Deriva documentation, catalog schema, and catalog data using semantic similarity.

Searches across three categories of indexed content:

  1. Catalog schema (doc_type="catalog-schema"): The connected catalog's structure, including:

    • Tables with columns, types, nullability, and comments

    • Foreign key relationships between tables

    • Feature definitions with term columns, asset columns, and value columns

    • Vocabulary terms with names, descriptions, and synonyms Use this to understand what data exists, how tables relate, what features are defined, and what vocabulary values are available.

  2. Catalog data (doc_type="catalog-data"): User-specific records from the connected catalog, including:

    • Datasets with types, versions, and descriptions

    • Executions with workflow names, status, and inputs Use this to find specific datasets by purpose or trace experiment provenance.

  3. Documentation (doc_type="user-guide", "api-reference", "sdk-reference"): Indexed docs from Deriva ecosystem repositories (deriva-ml, ermrest, chaise, deriva-py). Use this for API usage questions and how-to guidance.

Prefer this tool over reading raw resources for catalog exploration. Use doc_type to focus results on the category you need.

Args: query: Natural language search query (e.g., "how to create a dataset") limit: Maximum number of results to return (default 10) source: Filter by source name (e.g., "deriva-ml-docs", "ermrest-docs") doc_type: Filter by document type. Key values: - "catalog-schema": Tables, columns, FKs, features, vocab terms - "catalog-data": Datasets and executions in the catalog - "user-guide": DerivaML and Chaise documentation - "api-reference": ERMrest API documentation - "sdk-reference": deriva-py SDK documentation include_schema: If True (default), include catalog schema results when connected. Set to False to search only documentation. include_data: If True (default), include per-user data index results (datasets, executions) when connected. Set to False to exclude user data from search results.

Returns: Dict with search results including text snippets, relevance scores, source metadata, and GitHub URLs.

Examples: # Explore catalog structure — tables, columns, relationships rag_search("Image tables and features", doc_type="catalog-schema")

# Find vocabulary terms by meaning
rag_search("classification categories", doc_type="catalog-schema")

# Find feature definitions and their columns
rag_search("diagnosis label confidence", doc_type="catalog-schema")

# Find datasets by description, type, or purpose
rag_search("training split labeled", doc_type="catalog-data")

# Find executions by workflow or status
rag_search("training experiment results", doc_type="catalog-data")

# Search Deriva API documentation
rag_search("how to create a dataset", include_schema=False, include_data=False)

# Search everything (docs + schema + data) — the default
rag_search("how are images classified")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
sourceNo
doc_typeNo
include_dataNo
include_schemaNo
Behavior4/5

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

With no annotations, the description carries the full burden. It explains the default behavior of include_schema and include_data, the semantic similarity mechanism, and the return format (text snippets, relevance scores, source metadata, GitHub URLs). It does not disclose rate limits or auth requirements, but those are less critical for a search tool; overall it is quite transparent.

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?

Although long, the description is well-structured with headings, bullet points, and examples. Every section contributes value: purpose, category breakdown, usage guidance, parameter details, return format, and examples. It is appropriately sized for the tool's complexity.

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 is remarkably complete given no output schema and 6 parameters. It covers all aspects: what content is searched, how to narrow results, parameter semantics, defaults, return values, and practical examples. It fully equips an agent to invoke the tool correctly.

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 fully explain parameters. It does so in the Args section, detailing each of the six parameters, providing key values for doc_type, defaults, and even examples. This adds significant meaning beyond the raw 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 clearly states the tool's verb and resource: 'Search Deriva documentation, catalog schema, and catalog data using semantic similarity.' It explicitly lists three distinct categories of content, distinguishing it from sibling rag_* tools. The purpose is specific and actionable.

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 advises 'Prefer this tool over reading raw resources for catalog exploration' and explains how to use doc_type to focus results. It provides concrete usage examples for different scenarios. However, it does not explicitly contrast with other rag_* tools (e.g., rag_update) or state when not to use this tool, so a small gap remains.

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