PCQ
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| resolve_projectA | Resolve cq.yaml + CQ_CONFIG_JSON env into a single ResolvedConfig view. Returns project_root, cq_yaml_path, name, cmd, cfg, declared_metrics, output_dir. Read-only — does not create directories or mutate state. |
| inspect_projectA | Return project structure, entrypoint kind, contract state, and output evidence. Read-only. |
| validate_projectB | Run static and contract validation before execution. Optional inline ExperimentPlan / ExperimentPlanSet validation. Read-only. |
| validate_runB | Run post-run validation gates (manifest / metrics / run_summary) on a completed output directory. Read-only. |
| describe_runA | Return a compact, decision-facts oriented summary of a RunRecord. Includes best/last metrics, validation status, lineage, artifact counts, decision_facts. Read-only. |
| compare_runsA | Diff two RunRecords (or output dirs). Returns metric deltas, config changes, lineage relation, decision_facts. Read-only. |
| lineage_chainC | Walk a RunRecord's parent chain. Returns ordered nodes from this run back to its earliest reachable ancestor. Read-only. |
| apply_planA | Apply ExperimentPlan to project (modifies cq.yaml.configs only — never train.py). Provenance recorded under .pcq/plans/.json. Returns rejected envelope with reason='schema_invalid'|'validation_failed' on bad input. |
| apply_plansetA | Expand ExperimentPlanSet members into N output directories, each with its own cq.yaml + plan provenance. Returns rejected envelope with reason='schema_invalid'|'validation_failed' on bad input. |
| init_experimentB | Scaffold a CQ-runnable experiment (cq.yaml + train.py contract script, optionally pyproject.toml + agent runtime assets). |
| finalize_runB | Generate run_record.json + validation_report.json for an output directory. Walks ancestors to find project root if not provided. Writes to output_dir. |
| agent_installB | Install pcq agent runtime assets (AGENTS.md / CLAUDE.md managed block, .agents|.claude/skills/pcq/SKILL.md). Optionally write .mcp.json to wire pcq MCP server. |
| agent_statusA | Inspect pcq agent runtime asset status (installed / missing / stale / divergent / unmanaged) without writing. Read-only. |
| run_experimentA | Execute cq.yaml.cmd with auto-wired CQ_CONFIG_JSON env. Captures stdout/stderr to .pcq/run_*.log. For long-running GPU training, prefer the CQ service queue. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Each tool targets a distinct phase or action: plan application, scaffolding, execution, finalization/validation, and run analysis. The read-only analysis tools (describe_run, compare_runs, lineage_chain) and project inspection tools (resolve_project, inspect_project, validate_project) are separated by clear semantic boundaries. There are no pairs that appear to do the same thing.
Most tools follow an imperative verb_noun pattern (run_experiment, validate_project, describe_run). A few deviate: agent_install and agent_status are noun-first, lineage_chain is a noun phrase, and apply_planset compresses plan_set into one word. These are minor and do not prevent readability.
At 14 tools, the surface is within the well-scoped range and each tool covers a discrete step in the CQ lifecycle. The grouping of scaffold/configure/run/finalize/validate/analyze plus agent asset helpers feels intentional, with no obvious dead weight.
The main lifecycle is well covered: init, plan application, run, finalize, validate, and analyze. Minor gaps exist around explicit discovery/cleanup (e.g., listing or removing plans/runs), but agents can work around these using inspect_project, finalize_run artifacts, or output directories.