Skip to main content
Glama
Geyo33

mcp-data-summary

by Geyo33

build_subset_dataset

Apply categorical, numeric, and datetime filters to a source dataset and save the resulting subset as a new dataset.

Instructions

    Filter a dataset by categorical, numeric, and datetime criteria, then save the result.

    All filter types are applied independently and intersected to produce the final subset.

    Args:
        source_dataset_name: Name of the registered source dataset.
        categorical_filters: List of (column, value) tuples for exact value matching.
                            E.g. [("region", "South"), ("region", "North"), ("category", "Hardware")]
        numeric_filters: List of (column, value, operator) tuples for numeric comparison.
                        E.g. [("age", 30, ">="), ("salary", 50000, ">")]
        datetime_column: Column name to filter by date range. Leave empty to skip.
        datetime_from: Start of date range (inclusive). Leave empty for no lower bound.
        datetime_to: End of date range (inclusive). Leave empty for no upper bound.
        output_dataset_name: Name for the output subset. Auto-generated if empty.
        output_dataset_desc: Description of the subset. Auto-generated if empty.

    Returns:
        A JSON str with {"dataset_name":"...","dataset_path":"...","dataset_schema":"..."}
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
datetime_toNo
datetime_fromNo
datetime_columnNo
numeric_filtersNo
categorical_filtersNo
output_dataset_descNo
output_dataset_nameNo
source_dataset_nameYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the non-obvious intersection semantics ('All filter types are applied independently and intersected'), auto-generation behavior for output fields, and the exact return format. It does not explicitly say the source dataset is left unmodified, though 'save the result' implies a new output rather than in-place mutation.

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 front-loaded with a one-sentence action summary and a critical filtering-semantics note, then uses a structured Args/Returns layout. Given the 8-parameter surface, the length is justified and every sentence adds information; there is no tautology or filler.

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 an 8-parameter tool with no annotations, the description supplies a complete calling contract: all parameters are explained, the intersection behavior is spelled out, and the return shape is given as a JSON str with dataset_name, dataset_path, and dataset_schema. The only minor omission is the exact date string format, but both datetime params are strings with clear semantics, so this is a small gap.

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%, but the description fully compensates by documenting all 8 parameters with types, examples, and empty/default behavior. For example, categorical_filters is explained as 'List of (column, value) tuples for exact value matching' with concrete examples, and datetime bounds are marked as inclusive with 'Leave empty' instructions.

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 the specific verb-resource pair: 'Filter a dataset by categorical, numeric, and datetime criteria, then save the result.' It clearly scopes what the tool does and distinguishes it from sibling tools, which are all chart/report generators rather than dataset subsetting operations.

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 makes the usage context clear: it is the only tool among the siblings that filters and saves dataset subsets, so an agent can infer when to choose it over the visualization/report siblings. However, it does not explicitly name alternatives or state when-not-to-use it, so it falls 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.

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/Geyo33/mcp-learning-project'

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