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.2/5.0

Scored across 4 tools

Disambiguation4/5

Each tool has a distinct role: get_config_schema returns the schema, validate_climate_config checks a config, list_sample_data enumerates inputs, and process_climate_data runs the pipeline. The schema/validate/process trio shares the same config object, which creates mild potential for confusion, but the descriptions clearly delimit each step.

Naming Consistency5/5

All four names follow a consistent verb_noun snake_case pattern (get_config_schema, list_sample_data, validate_climate_config, process_climate_data). No mixing of conventions or vague verbs.

Tool Count4/5

Four focused tools cover the discover-validate-run workflow cleanly with no redundancy or bloat. It is slightly thin, but each tool earns its place for a scoped climate-processing server.

Completeness4/5

The surface covers the full workflow of discovering the schema, finding input data, validating, and executing the pipeline with inline results. There is no way to retrieve or revisit past outputs, but that is a minor gap given the stateless inline-return design.

Maintenance

ActivityMaintained
ResponsivenessNo issues