MCP Tool Reference¶

Cursus exposes a framework-neutral, JSON-in/JSON-out agent tool surface of 70 tools across 12 namespaces (with 163 worked examples). This page is generated from the live cursus.mcp.registry, so it always matches the installed toolset.

Invoke tools programmatically with cursus.mcp.registry.call_tool(name, args), over the MCP server (cursus-mcp / python -m cursus.mcp.server), or inspect them with cursus mcp help / the tools.help tool.

On an MCP host, each tool is exposed under a host-legal wire name (dots become __, e.g. catalog__list_steps) because host tool-calling APIs reject .; the dotted names below are the human-facing form, and both resolve to the same tool. The server is read-only by default — tools marked destructive / writes / exec_code below are exposed only when the operator opts in with CURSUS_MCP_ENABLE_DESTRUCTIVE=1 (filesystem writes + AWS upserts) or CURSUS_MCP_ALLOW_SCRIPT_EXEC=1 (running step scripts).

`author`¶

Guardrails + preflight checks for authoring a new step (rules, checklist, preflight).

`author.check_script`¶

MCP wire name: author__check_script

Check a step’s SCRIPT against its contract in BOTH directions: forward (main() signature + the script’s used keys are declared) AND reverse (every CLI arg the builder passes is parsed by the script’s argparse; every required env var is actually read). Catches the two empirical script↔builder bugs — a custom script missing the –job_type argparse the builder passes (crash), and a required env var declared but read-and-ignored — that validate.step_interface + author.preflight_step cannot. The Cat-4 arg check runs only for Processing steps (Estimators take args via JSON). Skips script-less steps (SDK-delegation / CreateModel / Transform). Offline, read-only.

When: Call this after writing/editing a step’s script to verify it aligns with its contract both ways — the builder’s CLI args are all parsed and every required env var is actually read.

Examples:

author.check_script {“step_name”: “TabularPreprocessing”} # forward + reverse script↔contract check
author.check_script {“step_name”: “XGBoostModel”} # script-less step returns status=skipped

(tags: validator)

Parameters

name	type	required	description
`step_name`	string	yes	Canonical step name whose script + contract to check (e.g. ‘TabularPreprocessing’).

`author.checklist`¶

MCP wire name: author__checklist

Return the ordered author→validate→integrate SOP for creating a new cursus step, as DATA naming the exact tool to call at each step (strategies.for_step_type → author.rules → write the 3 artifacts → validate.step_interface → author.preflight_step → compile). The routing branch (bound handler + exemplar) is derived from the live strategy_registry. Start here when authoring a step.

When: Call this first when you are about to author a brand-new cursus step and need the ordered author→validate→integrate SOP for its SageMaker step type.

Examples:

author.checklist {“sagemaker_step_type”: “Training”} # SOP for a new Estimator/Training step
author.checklist {“sagemaker_step_type”: “Processing”, “step_assembly”: “step_args”} # Processing step run via FrameworkProcessor step_args
author.checklist {“sagemaker_step_type”: “Processing”, “step_assembly”: “code”} # single-file ScriptProcessor Processing step

(tags: planner)

Parameters

name	type	required	description
`sagemaker_step_type`	string	yes	The step’s SageMaker verb (Processing / Training / Transform / CreateModel / a SAIS-delegation verb).
`step_assembly`	string	no	Processing sub-verb (code \| step_args \| delegation); omit for non-Processing types.

`author.config_constraints`¶

MCP wire name: author__config_constraints

List a step’s config-class fields WITH their legal VALUES — each field’s allowed_values (from a Literal/Enum type or a @field_validator allowed-set) + a case_sensitive flag, plus the required_no_default fields a value MUST be supplied for. Use this when authoring config VALUES: catalog.config_fields/config.requirements give only the field TYPE, which hid the enum/case constraints behind the largest empirical config-bug cluster. Sourced from the live config class so guidance == enforcement.

When: Call this before writing a step’s config VALUES to learn each field’s allowed_values / case_sensitivity and which required fields have no default.

Examples:

author.config_constraints {“step_name”: “TabularPreprocessing”} # allowed values + required_no_default fields
author.config_constraints {“step_name”: “XGBoostTraining”} # enum/case constraints for the training config

(tags: validator)

Parameters

name	type	required	description
`step_name`	string	yes	Canonical step name whose config class to introspect (e.g. ‘TabularPreprocessing’).

`author.help`¶

MCP wire name: author__help

Overview of the ‘author’ tools — Guardrails + preflight checks for authoring a new step (rules, checklist, preflight). Returns each author.* tool with its description, when to use it, and usage examples. Set include_schema for full JSON input schemas. Start here before using author tools.

When: You are about to work with author tools and want that namespace’s overview + examples.

Examples:

author.help {} # every author.* tool with when + examples
author.help {“include_schema”: true} # same, plus JSON input schemas

(tags: planner)

Parameters

name	type	required	description
`phase`	string	no	Restrict to one lifecycle phase.
`include_schema`	boolean	no	Attach each tool’s JSON input schema (default false).

`author.preflight_config`¶

MCP wire name: author__preflight_config

Validate a set of config VALUES against the step’s live config class (config_class.model_validate) — the gate that catches wrong enum case, invalid enum, wrong type, and missing required fields BEFORE a pipeline run. This is the value-level complement to author.preflight_step (which proves the step is constructible but never instantiates a config with user values). Returns per-field errors on failure.

When: Call this to validate a concrete {field: value} config set against the step’s live config class — catches wrong enum case, invalid enum, wrong type, and missing required fields before a run.

Examples:

author.preflight_config {“step_name”: “TabularPreprocessing”, “values”: {“job_type”: “training”, “label_name”: “label”}} # validate a config value set
author.preflight_config {“step_name”: “XGBoostTraining”, “values”: {}} # empty values surfaces the missing required fields

(tags: validator)

Parameters

name	type	required	description
`step_name`	string	yes	Canonical step name whose config class to validate against.
`values`	object	yes	The {field: value} config values to validate (the entry you would put in config.json for this step).

`author.preflight_step`¶

MCP wire name: author__preflight_step

Prove a step is CONSTRUCTIBLE (not merely parseable) before code review — a FLAT list of the four gates CI runs as its merge gate: interface validation, registry derivation/parity, RegistryBindingValidator B3 (handler binds + builder synthesizes + config-field coverage), and resolve_strategy routability. SDK-delegation / no-builder rows report skip-not-error offline. Pass ‘step_name’ for one step or ‘all’=true for the whole suite (the CI gate).

When: Call this after writing a step’s .step.yaml + config + script to prove it is CONSTRUCTIBLE (binds + synthesizes), or with ‘all’ to run the whole CI merge gate.

Examples:

author.preflight_step {“step_name”: “TabularPreprocessing”} # the four CI gates for one step
author.preflight_step {“all”: true} # preflight every step (CI merge-gate mode)
author.preflight_step {“step_name”: “XGBoostTraining”, “job_type”: “training”} # preflight a job_type variant

(tags: validator)

Parameters

name	type	required	description
`step_name`	string	no	Canonical step name to preflight. Omit when ‘all’ is true.
`all`	boolean	no	Preflight every step (the CI merge-gate mode).
`job_type`	string	no	Optional job_type variant for the interface gate.
`workspace_dirs`	array	no	Optional workspace directories to widen discovery.

`author.rules`¶

MCP wire name: author__rules

Return the authoring restriction set for one topic — naming (PascalCase / Config / StepBuilder / the valid sagemaker_step_type set), packaging (source_dir + SAIS preamble), sdk_carveout (the two distinct requires enums), reuse_class (shared / model_dependent / user_template), or closure (registry-by-construction + contract↔spec alignment). Values are read off the LIVE enforcement objects, so guidance can’t drift from what the build enforces.

When: Call this when you need the authoring restriction set for a specific topic (naming, packaging, SDK carve-out, reuse class, or triangle-closure) before writing a step’s artifacts.

Examples:

author.rules {“topic”: “naming”} # PascalCase step name / Config / StepBuilder + valid sagemaker_step_type set
author.rules {“topic”: “packaging”} # source_dir + output_path_token + SAIS preamble facts
author.rules {“topic”: “closure”} # registry-by-construction + contract↔spec alignment rules

(tags: validator)

Parameters

name	type	required	description
`topic`	string	yes	Which restriction set to return.

`catalog`¶

Discover/search steps, configs, and builders (step_catalog + registry).

`catalog.config_fields`¶

MCP wire name: catalog__config_fields

List the configuration fields (name, type, required, default, description) of a step’s config class. Use to learn what config a step expects.

When: Call when you need to know which configuration fields a step expects (names, types, required flags, defaults) before writing its config.

Examples:

catalog.config_fields {“step_name”: “XGBoostTraining”} # config schema for the training step
catalog.config_fields {“step_name”: “TabularPreprocessing”} # fields of the preprocessing config class

(tags: planner, programmer)

Parameters

name	type	required	description
`step_name`	string	yes	Canonical step name whose config class fields to list.

`catalog.help`¶

MCP wire name: catalog__help

Overview of the ‘catalog’ tools — Discover/search steps, configs, and builders (step_catalog + registry). Returns each catalog.* tool with its description, when to use it, and usage examples. Set include_schema for full JSON input schemas. Start here before using catalog tools.

When: You are about to work with catalog tools and want that namespace’s overview + examples.

Examples:

catalog.help {} # every catalog.* tool with when + examples
catalog.help {“include_schema”: true} # same, plus JSON input schemas

(tags: planner)

Parameters

name	type	required	description
`phase`	string	no	Restrict to one lifecycle phase.
`include_schema`	boolean	no	Attach each tool’s JSON input schema (default false).

`catalog.list_builders`¶

MCP wire name: catalog__list_builders

List builder class names (no instantiation), optionally filtered by SageMaker step type (e.g. ‘Processing’, ‘Training’, ‘Transform’).

When: Call when you want the builder class names available, optionally narrowed to a single SageMaker step type (e.g. all Processing builders).

Examples:

catalog.list_builders {} # every builder class, grouped by step name
catalog.list_builders {“sagemaker_step_type”: “Processing”} # only Processing-step builders
catalog.list_builders {“sagemaker_step_type”: “Training”} # only Training-step builders

(tags: programmer)

Parameters

name	type	required	description
`sagemaker_step_type`	string	no	Optional SageMaker step type filter (Processing, Training, Transform, CreateModel, …).

`catalog.list_steps`¶

MCP wire name: catalog__list_steps

List the concrete pipeline step names known to cursus. Call this to discover what steps are available before planning or building a pipeline.

When: Call this first when you need to see what pipeline steps exist before planning a DAG or looking up a specific step.

Examples:

catalog.list_steps {} # every step known to cursus
catalog.list_steps {“job_type”: “training”} # only training-variant steps
catalog.list_steps {“workspace_id”: “core”, “job_type”: “calibration”} # scope to a workspace + job type

(tags: planner)

Parameters

name	type	required	description
`workspace_id`	string	no	Optional workspace filter; omit for package-scope steps.
`job_type`	string	no	Optional job-type filter (e.g. ‘training’, ‘validation’).

`catalog.resolve_step`¶

MCP wire name: catalog__resolve_step

Resolve a step name (canonical or file-style like ‘model_evaluation_xgb’) to its config class, builder class, spec type, and SageMaker step type.

When: Call when you have a step name (canonical or file-style) and need its concrete registered classes: config, builder, spec type, SageMaker type.

Examples:

catalog.resolve_step {“step_name”: “XGBoostTraining”} # resolve a canonical name to its classes
catalog.resolve_step {“step_name”: “model_evaluation_xgb”} # map a file-style name to XGBoostModelEval

(tags: programmer)

Parameters

name	type	required	description
`step_name`	string	yes	Canonical or file-style step name to resolve.

`catalog.search`¶

MCP wire name: catalog__search

Fuzzy-search steps by name and return scored matches with the component types available for each. Use when you have a partial/approximate step name.

When: Call when you only know a partial or approximate step name and need scored candidate matches to pick the exact canonical name.

Examples:

catalog.search {“query”: “xgboost”} # all steps whose name matches “xgboost”
catalog.search {“query”: “preprocess”} # find TabularPreprocessing and friends
catalog.search {“query”: “eval”, “job_type”: “training”} # matches scoped to training-variant steps

(tags: planner)

Parameters

name	type	required	description
`query`	string	yes	Search substring to match against step names.
`job_type`	string	no	Optional job-type filter (e.g. ‘training’).

`catalog.step_info`¶

MCP wire name: catalog__step_info

Get full details for one step: registry data, config/builder names, SageMaker step type, detected framework, and which components exist.

When: Call when you have an exact step name and need its naming metadata (config/builder names, SageMaker type, framework, available components).

Examples:

catalog.step_info {“step_name”: “XGBoostTraining”} # full metadata for one step
catalog.step_info {“step_name”: “TabularPreprocessing”, “job_type”: “training”} # info for a job-type variant

(tags: planner)

Parameters

name	type	required	description
`step_name`	string	yes	Canonical step name (PascalCase, e.g. ‘XGBoostTraining’).
`job_type`	string	no	Optional job-type variant (e.g. ‘training’).

`catalog.step_spec`¶

MCP wire name: catalog__step_spec

Get a step’s full specification — its declared dependencies (input ports, with compatible sources + semantic keywords) and outputs (output ports, with property paths). Use this to understand a step’s I/O contract before wiring it into a DAG. (catalog.step_info gives naming/components; this gives ports.)

When: Call before wiring a step into a DAG, when you need its I/O contract — the declared dependency (input) ports and output ports, not just its names.

Examples:

catalog.step_spec {“step_name”: “XGBoostTraining”} # dependencies + outputs for wiring edges
catalog.step_spec {“step_name”: “XGBoostModelEval”} # ports of the eval step to connect its inputs

(tags: planner)

Parameters

name	type	required	description
`step_name`	string	yes	Canonical step name (PascalCase, e.g. ‘XGBoostTraining’).

`compile`¶

Compile/validate/preview a DAG into a SageMaker pipeline (core.compiler).

`compile.dag`¶

MCP wire name: compile__dag

Compile a DAG + config file into a SageMaker pipeline definition and return its name and step count. Build-only by default; set upsert=true (requires role) to push the pipeline to SageMaker (mutates external state).

When: Call this once validation/preview look good to build the SageMaker pipeline definition; only set upsert=true when you intend to push it to SageMaker.

Examples:

compile.dag {“config_file”: “config/pipeline_config.json”, “dag_file”: “config/dag.json”} # build-only: compile the pipeline definition, no upsert
compile.dag {“config_file”: “config/pipeline_config.json”, “dag_file”: “config/dag.json”, “pipeline_name”: “xgboost-training”} # build-only with a name override
compile.dag {“config_file”: “config/pipeline_config.json”, “dag_file”: “config/dag.json”, “role”: “arn:aws:iam::123456789012:role/SageMakerRole”, “upsert”: true} # DESTRUCTIVE: upserts the pipeline into SageMaker (needs role)

(destructive · network · tags: programmer)

Parameters

name	type	required	description
`dag`	object	no	Pipeline DAG topology. Either the flat form {‘nodes’: […], ‘edges’: [[src, dst], …]} or the serializer form {‘dag’: {‘nodes’: […], ‘edges’: […]}}. Provide this OR ‘dag_file’, not both.
`dag_file`	string	no	Path to a serialized DAG JSON file (loaded via import_dag_from_json). Provide this OR ‘dag’.
`config_file`	string	yes	Path to the pipeline configuration JSON file.
`role`	string	no	Optional IAM role ARN for the SageMaker pipeline.
`pipeline_name`	string	no	Optional pipeline name override.
`upsert`	boolean	no	If true, upsert the compiled pipeline to SageMaker (destructive). Requires ‘role’. Default false (build only).

`compile.help`¶

MCP wire name: compile__help

Overview of the ‘compile’ tools — Compile/validate/preview a DAG into a SageMaker pipeline (core.compiler). Returns each compile.* tool with its description, when to use it, and usage examples. Set include_schema for full JSON input schemas. Start here before using compile tools.

When: You are about to work with compile tools and want that namespace’s overview + examples.

Examples:

compile.help {} # every compile.* tool with when + examples
compile.help {“include_schema”: true} # same, plus JSON input schemas

(tags: planner)

Parameters

name	type	required	description
`phase`	string	no	Restrict to one lifecycle phase.
`include_schema`	boolean	no	Attach each tool’s JSON input schema (default false).

`compile.name`¶

MCP wire name: compile__name

Pure string helper for SageMaker pipeline names. Pass ‘base’ to generate a valid name (’--pipeline’, sanitized) and/or ‘sanitize’ to clean an arbitrary string. Returns the result(s) plus validity flags.

When: Call this to generate a SageMaker-valid pipeline name from a base string, or to sanitize/validate an arbitrary name before using it as pipeline_name.

Examples:

compile.name {“base”: “xgboost-training”} # generate “xgboost-training-1.0-pipeline”
compile.name {“base”: “xgboost training”, “version”: “2.1”} # generate with a specific version segment
compile.name {“sanitize”: “My Pipeline!! v3”} # clean an arbitrary string into a valid name

(tags: programmer)

Parameters

name	type	required	description
`base`	string	no	Base name to generate a pipeline name from.
`version`	string	no	Version segment for the generated name (default ‘1.0’).
`sanitize`	string	no	An arbitrary name to sanitize to SageMaker constraints.

`compile.preview`¶

MCP wire name: compile__preview

Preview how each DAG node will resolve to a config type and step builder, including per-node confidence scores, ambiguities, and recommendations. Non-destructive; use to inspect resolution before compiling.

When: Call this to inspect the node->config->builder mapping, confidence scores, and ambiguities before compiling — especially when compile.validate reported unresolved nodes.

Examples:

compile.preview {“config_file”: “config/pipeline_config.json”, “dag”: {“nodes”: [“TabularPreprocessing”, “XGBoostTraining”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”]]}} # preview resolution of an inline DAG
compile.preview {“config_file”: “config/pipeline_config.json”, “dag_file”: “config/dag.json”} # preview resolution of a DAG from file

(tags: planner, validator)

Parameters

name	type	required	description
`dag`	object	no	Pipeline DAG topology. Either the flat form {‘nodes’: […], ‘edges’: [[src, dst], …]} or the serializer form {‘dag’: {‘nodes’: […], ‘edges’: […]}}. Provide this OR ‘dag_file’, not both.
`dag_file`	string	no	Path to a serialized DAG JSON file (loaded via import_dag_from_json). Provide this OR ‘dag’.
`config_file`	string	yes	Path to the pipeline configuration JSON file.
`role`	string	no	Optional IAM role ARN for the SageMaker pipeline.

`compile.single_node`¶

MCP wire name: compile__single_node

Compile an isolated, single-node pipeline for one DAG node using manual S3 input overrides — useful to re-run one failed step without rerunning upstream steps. Build-only (does not start/upsert).

When: Call this to re-run a single failed DAG node in isolation by supplying its upstream S3 inputs manually, instead of recompiling the whole pipeline.

Examples:

compile.single_node {“config_file”: “config/pipeline_config.json”, “dag_file”: “config/dag.json”, “target_node”: “XGBoostTraining”, “manual_inputs”: {“input_path”: “s3://my-bucket/run-1/preprocessing/output/”}} # isolate XGBoostTraining with a manual S3 input
compile.single_node {“config_file”: “config/pipeline_config.json”, “dag_file”: “config/dag.json”, “target_node”: “TabularPreprocessing”, “manual_inputs”: {“data_input”: “s3://my-bucket/raw/”}, “pipeline_name”: “tab-preproc-isolated”, “validate_inputs”: false} # isolate a node, skip input validation, custom name

(tags: programmer)

Parameters

name	type	required	description
`dag`	object	no	Pipeline DAG topology. Either the flat form {‘nodes’: […], ‘edges’: [[src, dst], …]} or the serializer form {‘dag’: {‘nodes’: […], ‘edges’: […]}}. Provide this OR ‘dag_file’, not both.
`dag_file`	string	no	Path to a serialized DAG JSON file (loaded via import_dag_from_json). Provide this OR ‘dag’.
`config_file`	string	yes	Path to the pipeline configuration JSON file.
`role`	string	no	Optional IAM role ARN for the SageMaker pipeline.
`target_node`	string	yes	Name of the DAG node to compile in isolation.
`manual_inputs`	object	yes	Map of logical input name -> S3 URI (e.g. {“input_path”: “s3://bucket/run-1/output/”}).
`pipeline_name`	string	no	Optional pipeline name (default ‘-isolated’).
`validate_inputs`	boolean	no	Validate node existence + S3 URIs first. Default true.

`compile.validate`¶

MCP wire name: compile__validate

Validate that a DAG’s nodes can be resolved to configs and step builders for a given config file. Call before compiling to catch missing configs or unresolvable builders. Returns is_valid, missing_configs, unresolvable_builders, config_errors, dependency_issues, warnings.

When: Call this before compiling to confirm every DAG node resolves to a config and a step builder for the given config_file.

Examples:

compile.validate {“config_file”: “config/pipeline_config.json”, “dag”: {“nodes”: [“TabularPreprocessing”, “XGBoostTraining”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”]]}} # validate an inline DAG
compile.validate {“config_file”: “config/pipeline_config.json”, “dag_file”: “config/dag.json”} # validate a DAG loaded from a JSON file
compile.validate {“config_file”: “config/pipeline_config.json”, “dag_file”: “config/dag.json”, “role”: “arn:aws:iam::123456789012:role/SageMakerRole”} # validate with an explicit IAM role

(tags: validator)

Parameters

name	type	required	description
`dag`	object	no	Pipeline DAG topology. Either the flat form {‘nodes’: […], ‘edges’: [[src, dst], …]} or the serializer form {‘dag’: {‘nodes’: […], ‘edges’: […]}}. Provide this OR ‘dag_file’, not both.
`dag_file`	string	no	Path to a serialized DAG JSON file (loaded via import_dag_from_json). Provide this OR ‘dag’.
`config_file`	string	yes	Path to the pipeline configuration JSON file.
`role`	string	no	Optional IAM role ARN for the SageMaker pipeline.

`compile.with_report`¶

MCP wire name: compile__with_report

Compile a DAG + config file into a pipeline and return a detailed ConversionReport: pipeline_name, steps, avg_confidence, resolution_details, and warnings. Non-destructive (builds the definition, never upserts).

When: Call this instead of compile.dag when you want a detailed ConversionReport (per-node resolution_details, avg_confidence, warnings) without any risk of upserting.

Examples:

compile.with_report {“config_file”: “config/pipeline_config.json”, “dag_file”: “config/dag.json”} # compile and return the full ConversionReport
compile.with_report {“config_file”: “config/pipeline_config.json”, “dag”: {“nodes”: [“TabularPreprocessing”, “XGBoostTraining”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”]]}, “pipeline_name”: “xgboost-training”} # report for an inline DAG with a name override

(tags: programmer)

Parameters

name	type	required	description
`dag`	object	no	Pipeline DAG topology. Either the flat form {‘nodes’: […], ‘edges’: [[src, dst], …]} or the serializer form {‘dag’: {‘nodes’: […], ‘edges’: […]}}. Provide this OR ‘dag_file’, not both.
`dag_file`	string	no	Path to a serialized DAG JSON file (loaded via import_dag_from_json). Provide this OR ‘dag’.
`config_file`	string	yes	Path to the pipeline configuration JSON file.
`role`	string	no	Optional IAM role ARN for the SageMaker pipeline.
`pipeline_name`	string	no	Optional pipeline name override.

`config`¶

Schema-driven config generation and loading (api.factory + core.config_fields).

`config.field_info`¶

MCP wire name: config__field_info

Return the field requirements (name, type, description, required, default) for a single named config class, e.g. ‘TabularPreprocessingConfig’. Pass categorized=true to split into required vs optional. Use to inspect one step’s config in detail.

When: Call this when you know a specific config class name and want its full field list (types, defaults, required flags) without resolving a whole DAG.

Examples:

config.field_info {“config_class”: “XGBoostTrainingConfig”} # all fields for XGBoost training config
config.field_info {“config_class”: “TabularPreprocessingConfig”, “categorized”: true} # split into required vs optional

(tags: planner)

Parameters

name	type	required	description
`config_class`	string	yes	Config class name to introspect (e.g. ‘XGBoostTrainingConfig’).
`categorized`	boolean	no	If true, return separate ‘required’ and ‘optional’ field lists.

`config.help`¶

MCP wire name: config__help

Overview of the ‘config’ tools — Schema-driven config generation and loading (api.factory + core.config_fields). Returns each config.* tool with its description, when to use it, and usage examples. Set include_schema for full JSON input schemas. Start here before using config tools.

When: You are about to work with config tools and want that namespace’s overview + examples.

Examples:

config.help {} # every config.* tool with when + examples
config.help {“include_schema”: true} # same, plus JSON input schemas

(tags: planner)

Parameters

name	type	required	description
`phase`	string	no	Restrict to one lifecycle phase.
`include_schema`	boolean	no	Attach each tool’s JSON input schema (default false).

`config.load`¶

MCP wire name: config__load

Load a saved merged-config JSON file and return a JSON-safe summary: shared field names and per-step field names/counts. Use to inspect what a previously saved config file contains without loading full values.

When: Call this when you have a saved merged-config JSON file on disk and want to inspect which shared and per-step fields it holds without loading full values.

Examples:

config.load {“path”: “config/config_xgboost.json”} # summarize a saved merged-config file
config.load {“path”: “/tmp/pipeline/configs.json”} # absolute path to a merge_and_save_configs output

(tags: planner)

Parameters

name	type	required	description
`path`	string	yes	Filesystem path to a merged-config JSON file produced by merge_and_save_configs.

`config.merge_save`¶

MCP wire name: config__merge_save

Reports that merging and saving configs is NOT available over the JSON tool boundary because merge_and_save_configs needs live in-process Pydantic config objects. Returns an explanatory error pointing at the in-process engine API.

When: Call this only to confirm that saving merged configs is unsupported over the JSON boundary; it always returns an explanatory error pointing at the in-process API.

Examples:

config.merge_save {} # returns the ‘unsupported’ error explaining the in-process path
config.merge_save {“output_file”: “config/config.json”} # output_file is informational only; still returns unsupported

Parameters

name	type	required	description
`output_file`	string	no	Intended output path (informational only; the operation is not supported here).

`config.requirements`¶

MCP wire name: config__requirements

Given a pipeline DAG, return the configuration field requirements for it: base pipeline config fields, base processing config fields (if any step needs them), and per-step (non-inherited) fields, plus the node->config-class map and which steps still need user input. Primary planning tool for building configs.

When: Call this when you have a pipeline DAG and need to know which config fields (base, processing, per-step) must be filled in before compiling.

Examples:

config.requirements {“dag”: {“nodes”: [“TabularPreprocessing”, “XGBoostTraining”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”]]}} # fields a 2-step DAG needs
config.requirements {“dag”: {“dag”: {“nodes”: [“TabularPreprocessing”], “edges”: []}}} # wrapped serializer form, single node

(tags: planner)

Parameters

name	type	required	description
`dag`	object	yes	Pipeline DAG topology. Either a flat object with ‘nodes’ and ‘edges’, or the serializer form {‘dag’: {‘nodes’: […], ‘edges’: […]}}.

`dag`¶

Construct, validate, and serialize pipeline DAGs (api.dag).

`dag.construct`¶

MCP wire name: dag__construct

Build a pipeline DAG from nodes and [src, dst] edges and return its serialized JSON (nodes, edges, statistics). Use this to create a round-trippable DAG the other dag.* tools accept.

When: Call this when you have a set of step names and their dependency edges and need a serialized, round-trippable DAG the other dag.* tools accept.

Examples:

dag.construct {“nodes”: [“TabularPreprocessing”, “XGBoostTraining”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”]]} # minimal two-step DAG
dag.construct {“nodes”: [“TabularPreprocessing”, “XGBoostTraining”, “XGBoostModelEval”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”], [“XGBoostTraining”, “XGBoostModelEval”]], “metadata”: {“pipeline”: “xgboost-training”, “author”: “me”}} # with embedded metadata

(tags: planner)

Parameters

name	type	required	description
`nodes`	array	yes	Step names (nodes) of the pipeline DAG, e.g. [‘preprocess’, ‘train’].
`edges`	array	no	Directed dependency edges as [src, dst] pairs; src runs before dst. Endpoints not listed in ‘nodes’ are added automatically.
`metadata`	object	no	Optional free-form metadata embedded in the serialized DAG.

`dag.dependencies`¶

MCP wire name: dag__dependencies

For a single step in the DAG, return its immediate upstream dependencies (steps that must run before) and downstream dependents (steps that run after).

When: Call this when you need the immediate upstream (must-run-before) and downstream (run-after) neighbors of one specific step in the DAG.

Examples:

dag.dependencies {“step”: “XGBoostTraining”, “nodes”: [“TabularPreprocessing”, “XGBoostTraining”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”]]} # dependencies=[TabularPreprocessing]
dag.dependencies {“step”: “XGBoostTraining”, “nodes”: [“TabularPreprocessing”, “XGBoostTraining”, “XGBoostModelEval”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”], [“XGBoostTraining”, “XGBoostModelEval”]]} # also dependents=[XGBoostModelEval]

(tags: planner)

Parameters

name	type	required	description
`step`	string	yes	Step name to inspect; must be a node in the DAG.
`nodes`	array	yes	Step names (nodes) of the pipeline DAG, e.g. [‘preprocess’, ‘train’].
`edges`	array	no	Directed dependency edges as [src, dst] pairs; src runs before dst. Endpoints not listed in ‘nodes’ are added automatically.

`dag.deserialize`¶

MCP wire name: dag__deserialize

Load a DAG from a JSON file written by dag.serialize and return its nodes, edges, statistics, and metadata.

When: Call this to load a DAG back from a JSON file previously written by dag.serialize, recovering its nodes, edges, statistics, and metadata.

Examples:

dag.deserialize {“path”: “/tmp/xgb_dag.json”} # read a DAG file written by dag.serialize

(tags: planner)

Parameters

name	type	required	description
`path`	string	yes	Path to a DAG JSON file to read.

`dag.help`¶

MCP wire name: dag__help

Overview of the ‘dag’ tools — Construct, validate, and serialize pipeline DAGs (api.dag). Returns each dag.* tool with its description, when to use it, and usage examples. Set include_schema for full JSON input schemas. Start here before using dag tools.

When: You are about to work with dag tools and want that namespace’s overview + examples.

Examples:

dag.help {} # every dag.* tool with when + examples
dag.help {“include_schema”: true} # same, plus JSON input schemas

(tags: planner)

Parameters

name	type	required	description
`phase`	string	no	Restrict to one lifecycle phase.
`include_schema`	boolean	no	Attach each tool’s JSON input schema (default false).

`dag.resolve_plan`¶

MCP wire name: dag__resolve_plan

Compute a topologically sorted execution plan for a DAG: the execution order plus per-step dependencies and data-flow map. Fails if the DAG has a cycle.

When: Call this when you need the topological execution order of a validated DAG plus each step’s dependencies and data-flow map before running it.

Examples:

dag.resolve_plan {“nodes”: [“TabularPreprocessing”, “XGBoostTraining”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”]]} # execution_order = preprocess then train
dag.resolve_plan {“nodes”: [“TabularPreprocessing”, “XGBoostTraining”, “XGBoostModelEval”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”], [“XGBoostTraining”, “XGBoostModelEval”]]} # three-step ordered plan

(tags: planner)

Parameters

name	type	required	description
`nodes`	array	yes	Step names (nodes) of the pipeline DAG, e.g. [‘preprocess’, ‘train’].
`edges`	array	no	Directed dependency edges as [src, dst] pairs; src runs before dst. Endpoints not listed in ‘nodes’ are added automatically.

`dag.serialize`¶

MCP wire name: dag__serialize

Serialize a DAG to JSON. If ‘path’ is given, write the JSON file and return the path; otherwise return the JSON string. Validates the DAG before writing to a file.

When: Call this to persist a DAG to a JSON file (pass ‘path’) or to get its JSON string inline (omit ‘path’); it validates the DAG before writing a file.

Examples:

dag.serialize {“nodes”: [“TabularPreprocessing”, “XGBoostTraining”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”]]} # returns pretty JSON inline
dag.serialize {“nodes”: [“TabularPreprocessing”, “XGBoostTraining”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”]], “path”: “/tmp/xgb_dag.json”, “pretty”: true} # writes file, returns the path

(writes · tags: planner)

Parameters

name	type	required	description
`nodes`	array	yes	Step names (nodes) of the pipeline DAG, e.g. [‘preprocess’, ‘train’].
`edges`	array	no	Directed dependency edges as [src, dst] pairs; src runs before dst. Endpoints not listed in ‘nodes’ are added automatically.
`metadata`	object	no	Optional free-form metadata embedded in the serialized DAG.
`path`	string	no	Optional output file path. If omitted, the JSON is returned inline.
`pretty`	boolean	no	Pretty-print the JSON with indentation (default true).

`dag.validate_integrity`¶

MCP wire name: dag__validate_integrity

Validate a DAG’s integrity (cycles, dangling edges, isolated nodes, undeclared_edge_nodes — edge endpoints not in nodes, i.e. a likely edge-name typo that would become a phantom unconfigured node — and, when the step catalog is available, missing steps/components). Returns {is_valid, issues}. Call before compiling a DAG into a pipeline.

When: Call this before compiling a DAG into a pipeline to check for cycles, dangling edges, isolated nodes, and edge endpoints not declared in nodes.

Examples:

dag.validate_integrity {“nodes”: [“TabularPreprocessing”, “XGBoostTraining”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”]]} # expect is_valid true
dag.validate_integrity {“nodes”: [“TabularPreprocessing”, “XGBoostTraining”], “edges”: [[“TabularPreprocessing”, “XGBoostTrainng”]]} # typo endpoint surfaces as undeclared_edge_nodes

(tags: validator)

Parameters

name	type	required	description
`nodes`	array	yes	Step names (nodes) of the pipeline DAG, e.g. [‘preprocess’, ‘train’].
`edges`	array	no	Directed dependency edges as [src, dst] pairs; src runs before dst. Endpoints not listed in ‘nodes’ are added automatically.

`execdoc`¶

MODS execution-document generation and validation (mods.exe_doc).

`execdoc.generate`¶

MCP wire name: execdoc__generate

Fill a MODS execution document from a pipeline DAG and a config file. Provide the DAG via ‘dag_file’ (serialized JSON path) or inline ‘dag’ (nodes+edges), plus ‘config_path’. Returns the filled execution document. Call when you need a runnable execution doc for a compiled pipeline.

When: Call when you have a compiled pipeline (DAG + config file) and need to produce a runnable MODS execution document to fill its PIPELINE_STEP_CONFIGS.

Examples:

execdoc.generate {“config_path”: “config.json”, “dag_file”: “pipeline_dag.json”} # fill from a serialized DAG
execdoc.generate {“config_path”: “config.json”, “dag”: {“nodes”: [“TabularPreprocessing”, “XGBoostTraining”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”]]}} # inline DAG
execdoc.generate {“config_path”: “config.json”, “dag_file”: “pipeline_dag.json”, “role”: “arn:aws:iam::123456789012:role/SageMakerRole”} # supply IAM role for full step configs

(network · tags: programmer)

Parameters

name	type	required	description
`config_path`	string	yes	Path to the pipeline configuration JSON file to load configs from.
`dag_file`	string	no	Path to a serialized DAG JSON file (used if ‘dag’ is not given).
`dag`	object	no	Inline DAG: {‘nodes’: [step names], ‘edges’: [[src, dst], …]}. Used if ‘dag_file’ is not given.
`execution_document`	object	no	Optional base execution document to fill. If omitted, a template is auto-generated from the DAG node names.
`role`	string	no	Optional IAM role ARN for AWS operations. Without it (and a SageMaker session), some helpers may produce limited step configs.
`project_root`	string	no	Optional project folder used to anchor step source_dir resolution (the caller hook, Strategy 0). When omitted, inferred from ‘config_path’.
`anchor_file`	string	no	Optional file inside the project folder (e.g. the template module); its parent directory is used as the project root. Alternative to ‘project_root’.

`execdoc.help`¶

MCP wire name: execdoc__help

Overview of the ‘execdoc’ tools — MODS execution-document generation and validation (mods.exe_doc). Returns each execdoc.* tool with its description, when to use it, and usage examples. Set include_schema for full JSON input schemas. Start here before using execdoc tools.

When: You are about to work with execdoc tools and want that namespace’s overview + examples.

Examples:

execdoc.help {} # every execdoc.* tool with when + examples
execdoc.help {“include_schema”: true} # same, plus JSON input schemas

(tags: planner)

Parameters

name	type	required	description
`phase`	string	no	Restrict to one lifecycle phase.
`include_schema`	boolean	no	Attach each tool’s JSON input schema (default false).

`execdoc.merge`¶

MCP wire name: execdoc__merge

Merge two execution documents, with ‘additional_doc’ taking precedence over ‘base_doc’ (STEP_CONFIG dicts are merged per step). Returns the merged document. Call to combine a base template with generated/overriding step configs.

When: Call to combine a base execution document with generated or overriding step configs, letting ‘additional_doc’ win on conflicts.

Examples:

execdoc.merge {“base_doc”: {“PIPELINE_STEP_CONFIGS”: {“XGBoostTraining”: {“STEP_TYPE”: “TrainingStep”, “STEP_CONFIG”: {}}}}, “additional_doc”: {“PIPELINE_STEP_CONFIGS”: {“XGBoostTraining”: {“STEP_TYPE”: “TrainingStep”, “STEP_CONFIG”: {“InstanceType”: “ml.m5.xlarge”}}}}} # additional_doc overrides STEP_CONFIG
execdoc.merge {“base_doc”: {“PIPELINE_STEP_CONFIGS”: {“TabularPreprocessing”: {“STEP_TYPE”: “ProcessingStep”, “STEP_CONFIG”: {}}}}, “additional_doc”: {“PIPELINE_STEP_CONFIGS”: {“XGBoostTraining”: {“STEP_TYPE”: “TrainingStep”, “STEP_CONFIG”: {}}}}} # add a new step

(tags: programmer)

Parameters

name	type	required	description
`base_doc`	object	yes	The base execution document.
`additional_doc`	object	yes	The execution document whose values take precedence on merge.

`execdoc.template`¶

MCP wire name: execdoc__template

Create an empty MODS execution-document template for a list of step names. Each step gets a default STEP_TYPE and empty STEP_CONFIG. Call to scaffold a document before filling or merging.

When: Call to scaffold an empty execution document from a list of step names before filling or merging it.

Examples:

execdoc.template {“step_names”: [“TabularPreprocessing”, “XGBoostTraining”]} # scaffold two step configs
execdoc.template {“step_names”: [“XGBoostTraining”]} # single-step template

(tags: programmer)

Parameters

name	type	required	description
`step_names`	array	yes	Step names to include as PIPELINE_STEP_CONFIGS entries.

`execdoc.validate`¶

MCP wire name: execdoc__validate

Validate the structure of an execution document. Returns {valid, issues}. Call to check a document has a well-formed PIPELINE_STEP_CONFIGS before generating or merging.

When: Call to check that an execution document is well-formed (has a valid PIPELINE_STEP_CONFIGS mapping) before generating or merging.

Examples:

execdoc.validate {“execution_document”: {“PIPELINE_STEP_CONFIGS”: {“XGBoostTraining”: {“STEP_TYPE”: “TrainingStep”, “STEP_CONFIG”: {}}}}} # valid document
execdoc.validate {“execution_document”: {“PIPELINE_STEP_CONFIGS”: {}}} # empty-but-valid mapping

(tags: validator)

Parameters

name	type	required	description
`execution_document`	object	yes	The execution document to validate.

`pipeline_catalog`¶

Recommend/select/load pre-built shared DAGs (pipeline_catalog).

`pipeline_catalog.auto_select`¶

MCP wire name: pipeline_catalog__auto_select

Auto-select the single best-matching shared DAG for a framework/features/task-type, or return null if no DAG meets the score threshold. Call when you want one decisive pick rather than a ranked list.

When: Call when you want one decisive best-match DAG (or null) instead of a ranked list — e.g. to auto-pick a pipeline for a known framework/task.

Examples:

pipeline_catalog.auto_select {“framework”: “xgboost”} # single best XGBoost DAG at default 0.6 threshold
pipeline_catalog.auto_select {“framework”: “pytorch”, “features”: [“training”, “bedrock_realtime_processing”, “edx_uploading”], “task_type”: “incremental”} # target the incremental EDX DAG
pipeline_catalog.auto_select {“framework”: “lightgbm”, “min_score”: 0.8} # stricter threshold

(tags: planner)

Parameters

name	type	required	description
`framework`	string	no	Required framework; omit to not filter.
`features`	array	no	Required features (e.g. [‘training’,’bedrock’,’edx_uploading’]).
`task_type`	string	no	Task-type keyword (e.g. ‘incremental’, ‘end_to_end’).
`min_score`	number	no	Minimum match score in 0-1 to accept a pick (default 0.6).

`pipeline_catalog.config_guidance`¶

MCP wire name: pipeline_catalog__config_guidance

Get configuration guidance for one shared DAG — prerequisites, required vs default config values, common pitfalls, and a decision tree. Call before building a config for a chosen DAG.

When: Call before authoring a config for a chosen DAG to learn its prerequisites, required vs default config fields, and common pitfalls.

Examples:

pipeline_catalog.config_guidance {“dag_id”: “bedrock_pytorch_incremental_edx”} # config prerequisites for the incremental EDX DAG
pipeline_catalog.config_guidance {“dag_id”: “lightgbmmt_complete_e2e”} # config guidance for a multi-task LightGBM DAG

(tags: planner)

Parameters

name	type	required	description
`dag_id`	string	yes	DAG identifier to fetch configuration guidance for.

`pipeline_catalog.get_dag`¶

MCP wire name: pipeline_catalog__get_dag

Get full details of one shared DAG — nodes, edges, input requirements, constraints, cost, and agent context. Call after choosing a dag_id from recommend/list to inspect its structure.

When: Call after picking a dag_id from recommend/list to inspect that DAG’s nodes, edges, input requirements, and constraints.

Examples:

pipeline_catalog.get_dag {“dag_id”: “bedrock_pytorch_incremental_edx”} # inspect an incremental LLM-scoring DAG
pipeline_catalog.get_dag {“dag_id”: “lightgbm_complete_e2e”} # inspect an end-to-end LightGBM DAG

(tags: planner)

Parameters

name	type	required	description
`dag_id`	string	yes	DAG identifier (e.g. ‘bedrock_pytorch_incremental_edx’).

`pipeline_catalog.help`¶

MCP wire name: pipeline_catalog__help

Overview of the ‘pipeline_catalog’ tools — Recommend/select/load pre-built shared DAGs (pipeline_catalog). Returns each pipeline_catalog.* tool with its description, when to use it, and usage examples. Set include_schema for full JSON input schemas. Start here before using pipeline_catalog tools.

When: You are about to work with pipeline_catalog tools and want that namespace’s overview + examples.

Examples:

pipeline_catalog.help {} # every pipeline_catalog.* tool with when + examples
pipeline_catalog.help {“include_schema”: true} # same, plus JSON input schemas

(tags: planner)

Parameters

name	type	required	description
`phase`	string	no	Restrict to one lifecycle phase.
`include_schema`	boolean	no	Attach each tool’s JSON input schema (default false).

`pipeline_catalog.list`¶

MCP wire name: pipeline_catalog__list

List every available shared DAG id with its metadata (framework, description, task type, complexity, features). Call to browse the catalog.

When: Call to browse the whole catalog when you don’t yet know which dag_id exists — returns every shared DAG id with its metadata.

Examples:

pipeline_catalog.list {} # list every available shared DAG with metadata

(tags: planner)

`pipeline_catalog.load_dag`¶

MCP wire name: pipeline_catalog__load_dag

Load a shared DAG by id and return its nodes and edges in JSON-safe form. Call to retrieve the concrete graph structure for compilation or display.

When: Call to retrieve the concrete node/edge graph of a chosen DAG for compilation or display (lighter than get_dag, no requirements/constraints).

Examples:

pipeline_catalog.load_dag {“dag_id”: “bedrock_pytorch_incremental_edx”} # load nodes+edges for compilation
pipeline_catalog.load_dag {“dag_id”: “lightgbm_complete_e2e”} # load the end-to-end LightGBM graph

(tags: planner)

Parameters

name	type	required	description
`dag_id`	string	yes	DAG identifier to load from the shared catalog.

`pipeline_catalog.recommend`¶

MCP wire name: pipeline_catalog__recommend

Recommend pre-built shared DAGs ranked by how well they match semantic requirements (data type, labels, LLM need, framework, GPU). Call when the user describes an ML problem and you need candidate pipeline DAGs.

When: Call when the user describes an ML problem and you need a ranked list of candidate shared-DAG pipelines to choose from.

Examples:

pipeline_catalog.recommend {} # rank all DAGs against defaults (labeled tabular, GPU on)
pipeline_catalog.recommend {“data_type”: “tabular”, “framework”: “xgboost”} # tabular XGBoost candidates
pipeline_catalog.recommend {“data_type”: “text”, “needs_llm”: true, “framework”: “pytorch”} # LLM-enriched PyTorch text pipelines

(tags: planner)

Parameters

name	type	required	description
`data_type`	string	no	Primary data type to train on.
`has_labels`	boolean	no	Whether labeled training data already exists (default true).
`needs_llm`	boolean	no	Whether an LLM (Bedrock) is needed for labeling/enrichment (default false).
`multi_task`	boolean	no	Whether multiple output tasks are required (default false).
`incremental`	boolean	no	Whether this is incremental retraining rather than first-time (default false).
`framework`	string	no	Preferred ML framework; ‘any’ or omit to not filter.
`gpu_available`	boolean	no	Whether GPU instances are available (default true).

`project`¶

Scaffold a new Cursus pipeline project (phase-0 skeleton + action-item ledger).

`project.bring_up`¶

MCP wire name: project__bring_up

Return the invocation for the cursus-new-project auto-chain orchestrator, which composes scaffold -> DAG (catalog-seeded or human-authored) -> config generation end-to-end. Bring-up is a multi-phase workflow, not a single stateless call, so this validates the inputs and hands back the exact workflow + args to run.

When: Call when you want the whole project brought up end-to-end (skeleton + DAG + config), not just the phase-0 skeleton — it returns the orchestrator workflow to run.

Examples:

project.bring_up {“name”: “secure_delivery”, “framework”: “xgboost”} # catalog DAG, full chain
project.bring_up {“name”: “new_model”, “framework”: “pytorch”, “dag_source”: “manual”} # scaffold, then human authors the DAG
project.bring_up {“name”: “eu_risk”, “framework”: “bedrock”, “region”: “EU”} # EU config target

(tags: planner)

Parameters

name	type	required	description
`name`	string	yes	Project base name (snake_case).
`framework`	string	yes	Model framework.
`target_dir`	string	no	Where the project folder is created (default ‘projects’).
`region`	string	no	Region alias for the generated config (default ‘NA’).
`dag_source`	string	no	‘catalog’ seeds a shared DAG and chains fully; ‘manual’ stops after scaffold for a human to author the DAG.

`project.help`¶

MCP wire name: project__help

Overview of the ‘project’ tools — Scaffold a new Cursus pipeline project (phase-0 skeleton + action-item ledger). Returns each project.* tool with its description, when to use it, and usage examples. Set include_schema for full JSON input schemas. Start here before using project tools.

When: You are about to work with project tools and want that namespace’s overview + examples.

Examples:

project.help {} # every project.* tool with when + examples
project.help {“include_schema”: true} # same, plus JSON input schemas

(tags: planner)

Parameters

name	type	required	description
`phase`	string	no	Restrict to one lifecycle phase.
`include_schema`	boolean	no	Attach each tool’s JSON input schema (default false).

`project.init`¶

MCP wire name: project__init

Scaffold a NEW Cursus pipeline project (phase-0). Writes the fixed skeleton — a region-agnostic run_pipeline.py, the @MODSTemplate deployment class (loads pipeline_config/dag.json), a shared generate_config.py skeleton with project_root_folder filled + a TODO per-node value-init, an empty dag.json stub, the folder tree + per-folder READMEs — and a root README action-item ledger handing every context-dependent piece (author the DAG, copy scripts/handlers, fill config) to its owning downstream workflow. Deterministic and offline; generates only what is knowable before a DAG exists.

When: Call at the very start of a new pipeline project, before any DAG or config exists, to lay down the standard package skeleton + the checklist of what to do next.

Examples:

project.init {“name”: “secure_delivery”, “framework”: “xgboost”} # -> projects/secure_delivery_xgboost/
project.init {“name”: “abuse_polygraph”, “framework”: “pytorch”, “target_dir”: “src/buyer_abuse_mods_template”} # BAMT deploy target (sets import prefix)
project.init {“name”: “fraud_scan”, “framework”: “lightgbmmt”, “overwrite”: true} # write into an existing folder

(destructive · writes · tags: planner)

Parameters

name	type	required	description
`name`	string	yes	Project base name (snake_case), e.g. ‘secure_delivery’. The framework is appended as a suffix.
`framework`	string	yes	Model framework; becomes the project-name suffix and selects the handler/hyperparameter template.
`target_dir`	string	no	Directory to create _/ under. Default ‘projects’ (AmazonCursus dev); pass ‘src/buyer_abuse_mods_template’ for a BAMT deploy (also sets the import prefix).
`overwrite`	boolean	no	Write into an existing target directory instead of failing. Default false.

`steps`¶

Per-step connection/I-O view: container paths, property refs, channels.

`steps.help`¶

MCP wire name: steps__help

Overview of the ‘steps’ tools — Per-step connection/I-O view: container paths, property refs, channels. Returns each steps.* tool with its description, when to use it, and usage examples. Set include_schema for full JSON input schemas. Start here before using steps tools.

When: You are about to work with steps tools and want that namespace’s overview + examples.

Examples:

steps.help {} # every steps.* tool with when + examples
steps.help {“include_schema”: true} # same, plus JSON input schemas

(tags: planner)

Parameters

name	type	required	description
`phase`	string	no	Restrict to one lifecycle phase.
`include_schema`	boolean	no	Attach each tool’s JSON input schema (default false).

`steps.io`¶

MCP wire name: steps__io

Return a step’s connection / I-O view: for each dependency the container path, required flag, type, compatible_sources, and the SageMaker training channel(s) it fans into (e.g. input_path -> train/val/test); for each output the container path and the runtime property_path reference a downstream step resolves against. This is the path/wiring view the Facade hides from a readable builder class — the complement to catalog.step_spec. Use to wire a step or understand where its data lands.

When: Call this when wiring a step or figuring out where its data lands — you need each dependency’s container path + training channel fan-out and each output’s container path + runtime property_path.

Examples:

steps.io {“step_name”: “XGBoostTraining”} # container paths + channel fan-out + property_paths
steps.io {“step_name”: “BatchTransform”} # I/O wiring for the batch transform step
steps.io {“step_name”: “TabularPreprocessing”, “job_type”: “training”} # resolve the training variant

(tags: planner)

Parameters

name	type	required	description
`step_name`	string	yes	Canonical step name, e.g. ‘XGBoostTraining’, ‘BatchTransform’.
`job_type`	string	no	Optional job_type variant (training \| validation \| testing \| calibration \| …) — resolves the variant’s spec.

`steps.patterns`¶

MCP wire name: steps__patterns

Return a step’s construction PATTERNS — the ‘plugins’ the TemplateStepBuilder composes for each axis: the bound create_step handler (from sagemaker_step_type + step_assembly), and the env-var / job-argument / input / output / compute patterns (all derived from the step’s .step.yaml contract DATA + registry binding, so the view cannot drift from behavior). Each axis carries ‘custom_override’: true where the builder still hand-overrides that method (a genuine per-step deviation). A top-level ‘dependencies’ rollup reports the step’s 3rd-party footprint (build_time {axis: pkg} for mods_workflow_core / SAIS-SDK vs runtime script deps vs native sagemaker-only). Use to see how a step is assembled — and what it costs to import — without reading a builder class.

When: Call this when you want to see how a step is assembled (its per-axis create_step / env-var / job-arg / input / output / compute patterns and its 3rd-party import footprint) without reading a builder class.

Examples:

steps.patterns {“step_name”: “XGBoostTraining”} # assembly axes for the XGBoost training step
steps.patterns {“step_name”: “TabularPreprocessing”, “job_type”: “calibration”} # resolve the calibration variant
steps.patterns {“step_name”: “ModelCalibration”, “job_type”: “training”} # patterns for a specific job_type variant

(tags: planner)

Parameters

name	type	required	description
`step_name`	string	yes	Canonical step name, e.g. ‘XGBoostTraining’, ‘TabularPreprocessing’.
`job_type`	string	no	Optional job_type variant (training \| validation \| testing \| calibration \| …) — resolves the variant’s spec.

`strategies`¶

Inspect the builder strategy library — axes and knobs (registry.strategy_registry).

`strategies.for_step_type`¶

MCP wire name: strategies__for_step_type

Given a sagemaker_step_type (and, for Processing, a step_assembly: code | step_args | delegation), return the strategy the builder facade would bind — handler, verb, preset knobs, and available knobs. This is the replacement for ‘read the builder class’: it tells an agent which strategy + knobs compose a step of this type.

When: Call this when authoring a step and you need the strategy + knobs the facade would bind for a given sagemaker_step_type — the replacement for reading the builder class.

Examples:

strategies.for_step_type {“sagemaker_step_type”: “Training”} # strategy the facade binds for a Training step
strategies.for_step_type {“sagemaker_step_type”: “Processing”, “step_assembly”: “code”} # Processing via the “code” assembly (script-driven)
strategies.for_step_type {“sagemaker_step_type”: “Processing”, “step_assembly”: “step_args”} # Processing via the “step_args” assembly

(tags: planner)

Parameters

name	type	required	description
`sagemaker_step_type`	string	yes	The step’s SageMaker step type, e.g. ‘Training’, ‘Processing’.
`step_assembly`	string	no	Processing sub-discriminator (code \| step_args \| delegation); ignored for non-Processing types. Defaults to ‘code’.

`strategies.help`¶

MCP wire name: strategies__help

Overview of the ‘strategies’ tools — Inspect the builder strategy library — axes and knobs (registry.strategy_registry). Returns each strategies.* tool with its description, when to use it, and usage examples. Set include_schema for full JSON input schemas. Start here before using strategies tools.

When: You are about to work with strategies tools and want that namespace’s overview + examples.

Examples:

strategies.help {} # every strategies.* tool with when + examples
strategies.help {“include_schema”: true} # same, plus JSON input schemas

(tags: planner)

Parameters

name	type	required	description
`phase`	string	no	Restrict to one lifecycle phase.
`include_schema`	boolean	no	Attach each tool’s JSON input schema (default false).

`strategies.knobs`¶

MCP wire name: strategies__knobs

List just the declarative knobs a strategy accepts, identified by (axis, name). Use to learn which knobs a step’s .step.yaml registry block can set.

When: Call this when you already know the (axis, name) of a strategy and just want the declarative knobs its .step.yaml registry block can set.

Examples:

strategies.knobs {“axis”: “sagemaker_step_type”, “name”: “Training”} # knobs the Training strategy accepts
strategies.knobs {“axis”: “step_assembly”, “name”: “code”} # knobs for the Processing “code” assembly strategy

(tags: planner)

Parameters

name	type	required	description
`axis`	string	yes	Routing axis of the strategy.
`name`	string	yes	Strategy name on that axis.

`strategies.list`¶

MCP wire name: strategies__list

List the registered builder strategies (construction-verb handlers + their knobs), optionally filtered to one routing axis. Each entry is a full strategy descriptor.

When: Call this when you want to enumerate the registered strategies (all axes, or one axis) with their full descriptors.

Examples:

strategies.list {} # every registered strategy across all axes
strategies.list {“axis”: “sagemaker_step_type”} # only the step-type strategies (Training, Transform, …)
strategies.list {“axis”: “step_assembly”} # only the Processing assembly strategies (code, step_args, delegation)

(tags: planner)

Parameters

name	type	required	description
`axis`	string	no	Filter to one axis (e.g. ‘sagemaker_step_type’, ‘step_assembly’).

`strategies.list_axes`¶

MCP wire name: strategies__list_axes

List the builder strategy library’s routing axes (sagemaker_step_type, step_assembly) and how many strategies each carries. Start here to understand the strategy space.

When: Call this first when you want an overview of the strategy space — which routing axes exist and how many strategies each carries.

Examples:

strategies.list_axes {} # the routing axes + strategy counts

(tags: planner)

`strategies.show`¶

MCP wire name: strategies__show

Return one strategy’s full descriptor: verb, handler class, every knob (name/type/default/required/doc), and preset knobs. Pass ‘axis’ to disambiguate a name that exists on more than one axis.

When: Call this when you know a strategy name and want its full descriptor — verb, handler class, and every knob (name/type/default/required/doc).

Examples:

strategies.show {“name”: “Training”} # full descriptor for the Training strategy
strategies.show {“name”: “code”, “axis”: “step_assembly”} # disambiguate the Processing “code” assembly strategy by axis
strategies.show {“name”: “Transform”} # the batch-Transform strategy descriptor

(tags: planner)

Parameters

name	type	required	description
`name`	string	yes	Strategy name, e.g. ‘Training’, ‘code’.
`axis`	string	no	Disambiguating axis (optional).

`tools`¶

Meta/discovery over the tool registry itself (help, by_phase, describe_tool).

`tools.by_phase`¶

MCP wire name: tools__by_phase

List the cursus MCP tools tagged for a lifecycle phase — ‘planner’ (discover/select/assemble), ‘validator’ (check before building), or ‘programmer’ (compile/generate). Use this to pick the right tool for the step you are on instead of scanning every tool.

When: You know the lifecycle phase you are on and want its tools without the full overview.

Examples:

tools.by_phase {“phase”: “planner”} # discover/select/assemble tools
tools.by_phase {“phase”: “validator”} # pre-build checks
tools.by_phase {“phase”: “programmer”} # compile/generate tools

(tags: planner)

Parameters

name	type	required	description
`phase`	string	yes	Lifecycle phase to filter by.

`tools.describe_tool`¶

MCP wire name: tools__describe_tool

Return the full descriptor for one cursus MCP tool by name: its description, when-to-use cue, usage examples, JSON input schema, phase tags, and whether it is destructive. Use to learn exactly how to call a tool you found via tools.help, a .help, or tools.by_phase.

When: You have a specific tool name and need its exact arguments before calling it.

Examples:

tools.describe_tool {“name”: “compile.dag”} # schema + examples for compile.dag
tools.describe_tool {“name”: “catalog.list_steps”}

(tags: planner)

Parameters

name	type	required	description
`name`	string	yes	Dotted tool name, e.g. ‘compile.dag’.

`tools.help`¶

MCP wire name: tools__help

START HERE. Introduce the entire cursus toolset in one call: a short overview, the lifecycle phases (planner/validator/programmer), and every tool grouped by namespace with its one-line description. Optional ‘namespace’ or ‘phase’ filters narrow the listing; set ‘include_schema’ to also get each tool’s JSON input schema. Use this to orient before picking a tool, then tools.describe_tool for exact args.

When: At the start of any task, or whenever you are unsure which cursus tool to use.

Examples:

tools.help {} # full overview of every namespace and tool
tools.help {“namespace”: “compile”} # just the compile.* tools
tools.help {“phase”: “validator”} # every validator-phase tool
tools.help {“namespace”: “dag”, “include_schema”: true} # dag tools + input schemas

(tags: planner)

Parameters

name	type	required	description
`namespace`	string	no	Restrict to one namespace (e.g. ‘catalog’, ‘compile’). Omit to list all namespaces.
`phase`	string	no	Restrict to one lifecycle phase.
`include_schema`	boolean	no	Attach each tool’s JSON input schema (default false).

`validate`¶

Alignment, dependency, and script-execution checks (validation, core.deps).

`validate.alignment`¶

MCP wire name: validate__alignment

Run configuration-driven alignment validation across all levels and return summary metrics (pass/fail/excluded counts, pass rate, step-type breakdown) plus critical issues. Pass ‘target_scripts’ to validate only specific steps.

When: Call this before compiling to prove steps are constructible — run all levels and get pass/fail counts and critical issues, optionally scoped to a subset.

Examples:

validate.alignment {} # validate every discovered step
validate.alignment {“target_scripts”: [“TabularPreprocessing”, “XGBoostTraining”]} # only these two steps
validate.alignment {“target_scripts”: [“XGBoostTraining”], “workspace_dirs”: [“/path/to/project”]} # widen discovery to a project dir

(tags: validator)

Parameters

name	type	required	description
`target_scripts`	array	no	Optional subset of step names to validate; omit to validate all discovered steps.
`workspace_dirs`	array	no	Optional workspace directories to widen step discovery beyond the installed package.

`validate.builder`¶

MCP wire name: validate__builder

Run the universal builder test suite for one step’s builder — builder↔config alignment, integration, step-creation, and (by default) quality scoring — and return the structured result. Use to validate a builder before registration.

When: Call this to test one step’s builder (builder<->config alignment, integration, step-creation, quality score) before registering or trusting that builder.

Examples:

validate.builder {“step_name”: “XGBoostTraining”} # full builder suite with scoring
validate.builder {“step_name”: “TabularPreprocessing”, “enable_scoring”: false} # skip the quality score
validate.builder {“step_name”: “XGBoostTraining”, “workspace_dirs”: [“/path/to/project”]} # widen discovery to a project dir

(tags: validator)

Parameters

name	type	required	description
`step_name`	string	yes	Canonical step name whose builder to test (e.g. ‘XGBoostTraining’).
`enable_scoring`	boolean	no	Include quality scoring in the result (default true).
`workspace_dirs`	array	no	Optional workspace directories to widen step discovery beyond the installed package.

`validate.deps_explain`¶

MCP wire name: validate__deps_explain

Explain the semantic similarity between two names: overall score plus the per-component breakdown (string / token / synonym / substring) the dependency resolver uses. Use to debug why two step or port names did or did not match.

When: Call this to debug a dependency match: get the overall + per-component semantic similarity score for two names when a deps_resolve match looks wrong or missing.

Examples:

validate.deps_explain {“name1”: “processed_data”, “name2”: “input_data”} # why two port names did/did not match
validate.deps_explain {“name1”: “TabularPreprocessing”, “name2”: “XGBoostTraining”} # compare two step names

(tags: validator)

Parameters

name	type	required	description
`name1`	string	yes	First name to compare.
`name2`	string	yes	Second name to compare.

`validate.deps_resolve`¶

MCP wire name: validate__deps_resolve

Resolve declarative dependencies among a set of steps using their catalog specifications: reports which required/optional dependencies match compatible outputs of the other steps, plus an overall resolution rate. Omit ‘step_names’ to use every catalog step that has a specification.

When: Call this to check whether a set of steps wires up — which required/optional dependencies match compatible outputs of the others — before assembling a DAG.

Examples:

validate.deps_resolve {} # resolve across every catalog step with a spec
validate.deps_resolve {“step_names”: [“TabularPreprocessing”, “XGBoostTraining”, “XGBoostModelEval”]} # just this pipeline
validate.deps_resolve {“step_names”: [“XGBoostTraining”], “workspace_dirs”: [“/path/to/project”]} # widen discovery to a project dir

(tags: validator)

Parameters

name	type	required	description
`step_names`	array	no	Steps to include in the resolution graph; omit to use all steps with specifications.
`workspace_dirs`	array	no	Optional workspace directories to widen step discovery beyond the installed package.

`validate.help`¶

MCP wire name: validate__help

Overview of the ‘validate’ tools — Alignment, dependency, and script-execution checks (validation, core.deps). Returns each validate.* tool with its description, when to use it, and usage examples. Set include_schema for full JSON input schemas. Start here before using validate tools.

When: You are about to work with validate tools and want that namespace’s overview + examples.

Examples:

validate.help {} # every validate.* tool with when + examples
validate.help {“include_schema”: true} # same, plus JSON input schemas

(tags: planner)

Parameters

name	type	required	description
`phase`	string	no	Restrict to one lifecycle phase.
`include_schema`	boolean	no	Attach each tool’s JSON input schema (default false).

`validate.info`¶

MCP wire name: validate__info

Return capability metadata for the validation and script-testing frameworks (available components, supported user stories, key features).

When: Call this to discover what the validation and script-testing frameworks can do (available components, supported user stories, key features) before using them.

Examples:

validate.info {} # capability metadata for the validation frameworks

(tags: validator)

`validate.run_scripts`¶

MCP wire name: validate__run_scripts

Execute a DAG’s step scripts locally against a pipeline config file and return per-script success/error and execution order. Heavy and SIDE-EFFECTING: it imports and RUNS each step script as local code and may pip-install their imports, so it can read/write local files and reach the network. On a public MCP server it is disabled unless CURSUS_MCP_ALLOW_SCRIPT_EXEC=1.

When: Call this to actually run a DAG’s step scripts locally against a config file (a heavier end-to-end check) once the DAG and configs are ready.

Examples:

validate.run_scripts {“nodes”: [“TabularPreprocessing”], “config_path”: “pipeline_config/config.json”} # run one script
validate.run_scripts {“nodes”: [“TabularPreprocessing”, “XGBoostTraining”], “edges”: [[“TabularPreprocessing”, “XGBoostTraining”]], “config_path”: “pipeline_config/config.json”} # run a two-step chain
validate.run_scripts {“nodes”: [“XGBoostTraining”], “config_path”: “pipeline_config/config.json”, “use_dependency_resolution”: false} # skip two-phase dependency resolution

(exec_code · network · tags: validator)

Parameters

name	type	required	description
`nodes`	array	yes	Step names that make up the DAG (at least one).
`config_path`	string	yes	Path to the pipeline configuration JSON used to resolve and validate each step’s script.
`edges`	array	no	Optional directed edges as [from_step, to_step] pairs.
`test_workspace_dir`	string	no	Directory for the test workspace (default ‘test/integration/script_testing’).
`use_dependency_resolution`	boolean	no	Whether to use two-phase dependency resolution (default true).

`validate.step`¶

MCP wire name: validate__step

Run alignment validation for a single named step and return its per-level result (status + any errors per validation level).

When: Call this to drill into one step’s per-level result after a full validate.alignment run flagged it, or when iterating on a single step.

Examples:

validate.step {“step_name”: “TabularPreprocessing”} # per-level result for one step
validate.step {“step_name”: “XGBoostTraining”, “workspace_dirs”: [“/path/to/project”]} # widen discovery to a project dir

(tags: validator)

Parameters

name	type	required	description
`step_name`	string	yes	Canonical step name to validate (e.g. ‘TabularPreprocessing’).
`workspace_dirs`	array	no	Optional workspace directories to widen step discovery beyond the installed package.

`validate.step_interface`¶

MCP wire name: validate__step_interface

Validate a step’s .step.yaml interface at AUTHOR time — the agent-callable form of cursus validate step-interface. Loads the interface through the production StepInterface.from_yaml path (Pydantic field errors + contract<->spec alignment) and flags compatible_sources case-typos. Pass ‘step_name’ (optionally ‘job_type’) for one step, or ‘all’=true to validate every interface (the CI gate). This is the author-time gate before author.preflight_step / validate.alignment.

When: Call this at AUTHOR time right after writing/editing a .step.yaml — the first gate before author.preflight_step and validate.alignment; or ‘all’=true in CI.

Examples:

validate.step_interface {“step_name”: “XGBoostTraining”} # validate one step interface
validate.step_interface {“step_name”: “TabularPreprocessing”, “job_type”: “calibration”} # a specific job_type variant
validate.step_interface {“all”: true} # CI mode: validate every .step.yaml

(tags: validator)

Parameters

name	type	required	description
`step_name`	string	no	Canonical step name to validate (e.g. ‘XGBoostTraining’). Omit when ‘all’ is true.
`all`	boolean	no	Validate every .step.yaml interface (CI mode). When true, ‘step_name’ is ignored.
`job_type`	string	no	Optional job_type variant to resolve (e.g. ‘validation’, ‘calibration’).

MCP Tool Reference¶

author¶

author.check_script¶

author.checklist¶

author.config_constraints¶

author.help¶

author.preflight_config¶

author.preflight_step¶

author.rules¶

catalog¶

catalog.config_fields¶

catalog.help¶

catalog.list_builders¶

catalog.list_steps¶

catalog.resolve_step¶

catalog.search¶

catalog.step_info¶

catalog.step_spec¶

compile¶

compile.dag¶

compile.help¶

compile.name¶

compile.preview¶

compile.single_node¶

compile.validate¶

compile.with_report¶

config¶

config.field_info¶

config.help¶

config.load¶

config.merge_save¶

config.requirements¶

dag¶

dag.construct¶

dag.dependencies¶

dag.deserialize¶

dag.help¶

dag.resolve_plan¶

dag.serialize¶

dag.validate_integrity¶

execdoc¶

execdoc.generate¶

execdoc.help¶

execdoc.merge¶

execdoc.template¶

execdoc.validate¶

pipeline_catalog¶

pipeline_catalog.auto_select¶

pipeline_catalog.config_guidance¶

pipeline_catalog.get_dag¶

pipeline_catalog.help¶

pipeline_catalog.list¶

pipeline_catalog.load_dag¶

pipeline_catalog.recommend¶

project¶

project.bring_up¶

project.help¶

project.init¶

steps¶

steps.help¶

steps.io¶

steps.patterns¶

strategies¶

strategies.for_step_type¶

strategies.help¶

strategies.knobs¶

strategies.list¶

strategies.list_axes¶

strategies.show¶

tools¶

tools.by_phase¶

tools.describe_tool¶

tools.help¶

validate¶

validate.alignment¶

validate.builder¶

validate.deps_explain¶

validate.deps_resolve¶

validate.help¶

validate.info¶

`author`¶

`author.check_script`¶

`author.checklist`¶

`author.config_constraints`¶

`author.help`¶

`author.preflight_config`¶

`author.preflight_step`¶

`author.rules`¶

`catalog`¶

`catalog.config_fields`¶

`catalog.help`¶

`catalog.list_builders`¶

`catalog.list_steps`¶

`catalog.resolve_step`¶

`catalog.search`¶

`catalog.step_info`¶

`catalog.step_spec`¶

`compile`¶

`compile.dag`¶

`compile.help`¶

`compile.name`¶

`compile.preview`¶

`compile.single_node`¶

`compile.validate`¶

`compile.with_report`¶

`config`¶

`config.field_info`¶

`config.help`¶

`config.load`¶

`config.merge_save`¶

`config.requirements`¶

`dag`¶

`dag.construct`¶

`dag.dependencies`¶

`dag.deserialize`¶

`dag.help`¶

`dag.resolve_plan`¶

`dag.serialize`¶

`dag.validate_integrity`¶

`execdoc`¶

`execdoc.generate`¶

`execdoc.help`¶

`execdoc.merge`¶

`execdoc.template`¶

`execdoc.validate`¶

`pipeline_catalog`¶

`pipeline_catalog.auto_select`¶

`pipeline_catalog.config_guidance`¶

`pipeline_catalog.get_dag`¶

`pipeline_catalog.help`¶

`pipeline_catalog.list`¶

`pipeline_catalog.load_dag`¶

`pipeline_catalog.recommend`¶

`project`¶

`project.bring_up`¶

`project.help`¶

`project.init`¶

`steps`¶

`steps.help`¶

`steps.io`¶

`steps.patterns`¶

`strategies`¶

`strategies.for_step_type`¶

`strategies.help`¶

`strategies.knobs`¶

`strategies.list`¶

`strategies.list_axes`¶

`strategies.show`¶

`tools`¶

`tools.by_phase`¶

`tools.describe_tool`¶

`tools.help`¶

`validate`¶

`validate.alignment`¶

`validate.builder`¶

`validate.deps_explain`¶

`validate.deps_resolve`¶

`validate.help`¶

`validate.info`¶

`validate.run_scripts`¶