meerkat-connect in the selected realm or through your application’s integrated Console. Application authors can also use the saved-request and connection-view APIs below.
Ordinary CLI and Console setup
The two product paths have different destinations:- CLI: choose the intended realm, follow the setup agent’s terminal questions and review the installation and requested access. After confirmed setup, use the integration from ordinary agents in that realm under current permissions.
- Console: begin with the original task. The integrated setup panel presents questions, protected human actions and exact reviews. Successful setup returns the capability to that same task through its native owner.
Advanced library and archive workflows
The current lower-level local setup tools can save exact requests, reopen them for readback, or propose their settings in a new setup. Use this section when operating the advanced library setup, whose host preparation and recovery are explicit responsibilities.Save setup work
In setup history, select each relevant job with Add to recovery file, then choose Save recovery file. The result istoolkit-recovery.json. An agent
can obtain the same file with setup_recovery_manifest:
text as UTF-8 unchanged and retain its sha256; the tool itself writes no
file. Jobs need a durably retained request. An already anchored running job can
be saved, so export does not prove completion or stop its worker.
Keep the original workspace and installed/acquired files at their existing
paths. The file contains request references, not software, credentials or the
original agent’s runtime. Review its contents before sharing it with another
person or setup agent.
Read saved work after process loss
A generated setup command owns a single-use workspace. Restarting that command against the same directory is refused. First establish that the old workers have stopped and retain exclusive custody of their files; recovery does not find or terminate those processes. Use the library host-preparation command with a new configuration output and future workspace, then add:prepare_host.py with an existing verified client, or bootstrap_host.py
with an additional new client directory. Keep the original library payload,
selected tool/profile bindings and required runtimes available. For configured
library requests, explicitly select the relevant families. Acquisition-only
readback can use --families '' without restoring acquisition tools.
Do not carry live acquisition, Compose execution or prior-configuration options
into this readback command. Optional source readers have their own archived
contracts and must be enabled separately.
The new output/workspace/client must be disjoint from old workspaces, manifests,
acquired staging paths and recipe data. Read the exact archive’s
selected/contracts/HOST-PREPARATION.md for mixed-request bindings. The
preparer checks each selected request; it does not search directories for a
plausible installation or migrate to another library version.
Start the new generated MCP connection. Use setup_jobs/setup_job to inspect
the selected requests, then call setup_reconcile for each relevant job.
Imported jobs remain unconfirmed with historical_outcome_unknown. A separate
matched observation confirms the checked retained files, not the original
operation’s result, account access or tool availability.
Readback restores no installation, retry, stop or business-task authority. To
use an intact installed connector, the host must validate and authorize its
existing launch and attach it through the native owner.
A fresh history readback alone does not restore connector processes.
Reuse saved settings in a new setup
To continue configuring an integration through this library path, create a fresh setup and add:prior-request.json; after successful
preparation, this new setup no longer needs the original workspace.
Choose current families and runtimes explicitly. Reuse prior configuration
or setup_successor proposes saved values against current help. Review
unapplied settings, select operations again and validate/install into a new
directory. The old selection cannot enable a family, authenticate an account,
change a running connection or grant new use.
Acquisition, selected-package and recipe-export requests cannot seed this
configured-library shortcut. An exact raw configured request remains supported
through --prior-request and --prior-request-sha256. Do not combine either
prior-selection form with readback recovery.
Restore software or update a connection
An installed environment and its absolute launch paths must stay in place. To restore software or adopt a new release, install the selected bytes into a new directory, review the current configuration and let the host switch its binding. Retain the old environment until the host has handled its dependants. This does not restore credentials, migrate provider data or replay a write. For interrupted preparation and ambiguous outputs, use troubleshooting.Service connections
For an application management view, compose the following information and controls with your existing account and policy services. A connection view should show the observed account, provider credential scope, effective operations/resources, assigned agent or task, grant lifetime and current diagnostics. A broad provider token can support a narrower local grant only where actual operation enforcement provides that restriction.1
Inspect the selected account
Match provider-observed identity with the intended host account. A friendly label is not an account verification receipt.
2
Inspect effective use
Review which agent or task can perform which operations on which resources. Keeping the account connected does not extend an expired task grant.
3
Choose the intended control
Reconnect repairs authentication. Change account creates an explicit selection change. Revoke access changes a grant. Disconnect affects the connection and any dependants named by the host.
