Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
get_config_schemaA

Return the JSON Schema a climate processing config must satisfy.

Call this before process_climate_data to see the required and optional fields: input_csv, date_column, metrics, rolling_window_days, plot, summary.

list_sample_dataA

List CSV files available under data/, with their column names.

Use one of the returned "filename" values as input_csv in a config passed to process_climate_data.

validate_climate_configA

Validate a climate processing config against the schema, without running it.

Returns {"valid": true} or {"valid": false, "errors": [...]}.

process_climate_dataA

Run the climate processing pipeline on an inline config and return the results.

config must satisfy the schema returned by get_config_schema. input_csv is resolved against the server's data/ directory (see list_sample_data for available files); the output_path fields under plot and summary are treated as filenames only -- every run writes to its own directory, so a config cannot choose where on disk anything is written.

missing_policy is optional: omit it and each metric uses the pipeline's default (interpolate for temperature_c, zero_fill for precipitation_mm). Set it per metric to interpolate, zero_fill, drop or fail. The right choice depends on the question being asked, not on the data alone: temperature is averaged over the month, so an estimated day washes out, while precipitation is summed, so a zero-filled day lowers the total permanently.

Returns a text report (row count, per-metric data quality, monthly summary table) followed by the rendered plot image. The data-quality section gives the missing count, coverage and longest consecutive gap for each metric, so the effect of the chosen policy is visible in the result.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
get_config_schemaReturn the JSON Schema a climate processing config must satisfy. Call this before process_climate_data to see the required and optional fields: input_csv, date_column, metrics, rolling_window_days, plot, summary.

TDQS

A4.3/5.0

Scored across 4 tools

Disambiguation4/5

Each tool has a clearly distinct purpose: schema retrieval, sample data listing, config validation, and pipeline execution. The only potential overlap is between get_config_schema and validate_climate_config, but their descriptions clearly differentiate them (informational vs. validation). Workflow order is logical and unambiguous.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: get_config_schema, list_sample_data, validate_climate_config, process_climate_data. The convention is predictable and easy to parse.

Tool Count5/5

With only 4 tools, the set is tightly scoped to the climate data processing pipeline. Each tool is essential and serves a distinct purpose, and the count is appropriate for the narrow domain.

Completeness4/5

The tool set covers the core lifecycle: schema discovery, data listing, config validation, and execution. It lacks tools for inspecting results or managing stored data, but for a one-shot pipeline server, the surface is mostly complete.

Maintenance

ActivityMaintained
ResponsivenessNo issues