Resources & prompts¶
In short
- Four
parleml://resources: a browsable index, the playbook topics, AutoDoc model cards and workspace catalogs. Each has a tool equivalent. - Seven prompts scaffold common jobs, such as
audit_modelanddeliver_model. Hosts show them like slash commands. - 17
ui://parleml/…app templates render tool results as panels (Apps).
Beyond the tools, the server exposes four parleml:// resources and seven
prompts. Hosts surface these differently — a resource picker, a slash
command, an attachment menu — so they are worth knowing even though every one
has a tool equivalent.
Resources¶
parleml://index is the only listable resource: hosts that show a resource
browser show this one, and it links onward to everything else. The other three
are templates — the host (or the model) fills the {…} segment.
| URI | MIME | Same data as |
|---|---|---|
parleml://index |
text/markdown |
— (a browsable index of the rest) |
parleml://guide/{topic} |
text/markdown |
get_playbook(topic) |
parleml://autodoc/{experiment_id} |
text/markdown |
get_autodoc(experiment_id) |
parleml://catalog/{workspace_id} |
application/json |
describe_catalog(workspace_id) |
Valid {topic} values are the same set get_playbook accepts: overview,
workflow, api, errors, charts, explainability,
schema-{supervised,unsupervised,forecast,recommendation,association}, and
the builder workflow's deliver, iterate and byo, plus
type-supervised, type-forecast, type-unsupervised,
type-recommendation, type-association and type-text. An
unknown topic is a ResourceError, not a success payload carrying an error
sentence — so a client can tell "here is the guide" from "no such topic".
Resources go through the same auth, error mapping and per-tool telemetry as the
tools; a failed read surfaces as a ResourceError with the same actionable
hints (401 → mint a token, 404 → publish results first).
Prompts¶
Seven prompts scaffold the common jobs and expand to a short plan the model can follow or adapt. All seven are registered for prompt discovery; the first four guide analyst jobs (with compute required for optional probes), and the other three guide work whose tools need a builder token. Each names its STOP points (where the agent hands back to the user) and ends at a person's decision. Every prompt opens with the same rule: ParleML computes, the agent reasons — it never re-implements a number a tool provides.
Each prompt takes names as the user would say them; the scaffold starts by resolving them to ids.
| Prompt | Arguments | Scaffolds |
|---|---|---|
explore_workspace(workspace) |
workspace name | catalog → profile → first questions |
audit_model(experiment) |
experiment name | evaluation → trust / fairness / drift → rules |
investigate_anomalies(experiment) |
experiment name | score distribution → top-k → per-row drivers |
triage_dataset(dataset) |
dataset name | EDA → leakage → optional probe_dataset (signal, baseline floor) |
deliver_model(workspace, question) |
workspace, the business question | brief → frame (STOP) → recipe → prepare → plan (STOP) → launch → iterate → decide → register |
prepare_training_table(workspace, question) |
workspace, the business question | catalog → target and prediction moment (STOP if ambiguous) → recipe SQL → preview → materialise → roles → leakage triage → signal |
improve_experiment(experiment) |
the run to improve on | one lever per experiment (STOP before each launch) → compare vs parent and the model in production → register a winner for review |
MCP-App panels¶
When the frontend embed build has run, the server also serves seventeen
ui://parleml/<id> App templates — evaluation, eda, rules,
catalog, chart, insight, resource, run, signal, compare,
decision, what-if, plan, recipe, prepare, scoring and
model-card — hosting 51 panels. Each linked tool carries the standard
_meta.ui.resourceUri, so a host that supports MCP-Apps renders the app for
that tool's results automatically. An app with several panels picks one from
a field of the result (chart_kind, kind, resource_kind, view, probe,
section, compare_kind, simulation, action — see Apps).
Panels are sandboxed HTML with a strict CSP (default-src 'none',
connect-src 'none', form-action 'none'), and each ui:// resource declares
the MCP Apps CSP with no network origin at all — they render the payload the
tool already returned and make no network calls of their own. A build without
the embed step simply serves no panels; every tool still works.
Next¶
- Cookbook: the prompts as worked sessions.
- Tool catalog: every tool.