Adagio

Add a plugin to the user's library so pipelines using it can run. ASK THE USER FIRST AND WAIT FOR A CLEAR YES. A community plugin is published by its author and reviewed by nobody, and adding it means running their code on the user's machine, so the decision is theirs and not yours to infer from the fact that it would be convenient. Say which plugin, what tier it is, and who maintains it, then ask. Before any write, the server also requires the host to approve a form showing the current effective row. That row selects the publisher; approval covers this publisher's named plugin across releases and future updates until the user removes it.

add_plugin_to_library

Save a proposed pipeline to the user's workspace and return a link to open it. Does not start a run. Required parameters you deliberately left unset are reported back so you can tell the user what needs their judgement. Steps are optional: omitting them creates an empty pipeline, exactly as the New Pipeline button does, which is the right answer when the user has not said what to build. Generate one operationId UUID for this intended creation and reuse that exact UUID if its outcome is unknown.

create_pipeline

Which installed actions can consume (or produce) a given artifact type, decided by the same semantic-type rules the canvas uses to allow a connection. Use this to chain steps and to prove nothing downstream exists when it does not.

find_compatible_actions

Who you are acting as, which QIIME release the catalog is pinned to, which plugins are installed, what this deployment can do, and how much pipeline quota is left. Call this first.

get_adagio_context

Read an existing pipeline as steps and connections rather than raw spec JSON, with its current problems, unset required parameters, and where its latest run wrote its outputs.

get_pipeline

Exact signatures - every input, parameter and output with its type, whether it is required, and its default. Read this before setting any parameter.

get_action_specs

Every visible plugin row for the effective QIIME release with its tier and whether it is in the library. More than one row can have the same plugin name; all are returned, and effective identifies the one selected for authoring. Only that effective row exposes callable action identifiers. A plugin that is visible is not necessarily runnable: community plugins are opt-in, and a pipeline using one that is not in the library is refused at run time.

list_plugins

The caller's own pipelines, newest first, as summaries rather than graphs. Every other pipeline tool takes a UUID, and a user refers to their work by name, so this is how a name becomes an id. Call it before saying a named pipeline cannot be found, and before creating one that may already exist. Pass a name to filter; matching is case-insensitive on any part of the name, and an empty result means no pipeline of theirs matches, not that the name is wrong. Names are not unique, so a name can match several - ask which one rather than taking the first. Use get_pipeline for the steps of one.

list_pipelines

Find installed actions by keyword. Returns compact summaries; use get_action_specs for exact signatures. This is a keyword match, not a capability check: every query term has to appear, so an ordinary phrasing can miss an action that is installed. Zero hits means no keyword match - retry with the canonical term for the method, and confirm a real gap with find_compatible_actions, which decides by type rather than by wording.

search_actions

Edit an existing pipeline: add steps, connect them, change parameters, remove steps. Existing steps keep their identity and their position on the canvas, so this does not rearrange the user's layout or discard cached run state. Steps are named by the name get_pipeline reports.

update_pipeline