Skip to main content
Glama
HappyHackingOrange

pdml-agent

by HappyHackingOrange
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

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
list_experimentsA

List completed experiment runs, with optional filters.

Returns one entry per run with its experiment_id, the constraint, dataset,
seed and logic it used, and how many epochs it recorded. Call this first:
every other experiment tool takes an experiment_id that comes from here.
The constraint filter accepts either the class name (StandardRobustness)
or the folder name that appears in ids (standard-robustness).
get_experiment_configA

Recover the exact configuration a run was trained with.

Reads the command line the training script recorded in the run's own output, so this is what actually ran rather than what was intended. Use it before proposing a new run based on an existing one.

get_resultsA

Metrics for one epoch of a run, defaulting to the final epoch.

Constraint security is reported as Test-C-Sec-self and Test-C-Sec-common; predictive performance is Test-P-Metric. Metrics the run did not evaluate are returned as null rather than as the -1 sentinel the training script writes, so a missing measurement cannot be mistaken for a real one.

compare_runsA

Diff two runs on both configuration and final headline metrics.

Returns only the config keys that differ, plus deltas on predictive
performance and constraint security. Prefer this over calling get_results
twice when the question is what changed between two runs.
search_logic_definitionsA

Find differentiable logic implementations in the source.

Matches on class name, docstring and filename, returning the operators each logic implements and where it is defined. An empty query returns all of them. Use this to understand what a logic does before interpreting a result or proposing a run that uses it.

run_experimentA

Plan a training run, or execute one. The only tool that consumes compute.

With dry_run=true (the default) it validates every argument, returns the
exact command, and touches nothing. Do that first and show the plan.

With dry_run=false it executes, subject to two independent gates: the
operator must approve the exact call, and the server must have been
started with execution enabled. If either refuses, the result says
status refused or declined_by_operator. Do not retry a refused or
declined call; report it. A completed run returns the experiment_id to
pass to get_results. Training takes minutes even for one epoch;
oracle_steps and oracle_restarts control the adversarial attack cost.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct responsibility: listing experiments, retrieving configs, fetching metrics, comparing runs, searching logic definitions, and executing runs. There is no overlap in purpose, and run_experiment is the only side-effecting tool.

Naming Consistency5/5

All six tool names follow a consistent snake_case verb_noun pattern (list_experiments, get_results, compare_runs, etc.). The verbs are semantically appropriate and predictable.

Tool Count5/5

Six tools is well-scoped for an experiment management agent: discovery, configuration, results, comparison, domain search, and execution. Each tool earns its place without redundancy.

Completeness4/5

The tool surface covers the full core workflow: plan/execute a run, list runs, inspect configuration and metrics, and compare runs. Missing operations like deleting or cancelling runs are not obvious gaps for immutable experiment records.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources