Skip to main content

Management

Management tools let an AI assistant find, read, create and maintain your content directly over MCP — so it can discover a prompt, revise it, or tidy up, without you switching to the dashboard.

Content-management operations cover all four shareable primitives: prompts, resources, custom tools, and Agent definitions:

Two tools support optional persistent task-start setup, with a third available when the selected agent definition has conditional behavior:

  • setup — return the installation instruction and offer optional guided content onboarding after general setup
  • bootstrap — report usage capabilities, own and bound-Team targets, create rights, recurring content guidance, and Agent selection
  • agent_context — load conditional behavior from the Agent's current active definition

All three are authenticated system tools: they are always advertised and callable independently of Tools, tool selections, and tool policies. Agent selection and content through bootstrap and agent_context still require Agents and current Agent visibility.

For the client-side installation and Agent-selection walkthrough, see Set up task-start context. The apistash server supplies the canonical instruction; the connected local agent, not the server or dashboard, applies it through a native persistent-instruction mechanism.

Finding and reading content​

Before it can revise or copy something, an agent has to find it and read it. The list_* tools enumerate what its credential can see, including team-owned items from its bound teams, items it can reach in the organization's shared catalogue, and personal items when it represents a member. The get_* tools return one item's full detail: a prompt's template, a resource's content, a custom tool's connector definition, or an Agent's current active definition.

What you can see is deliberately broader than what you can change. An agent can read a prompt it can reach in the shared catalogue and copy it into a personal or team space it can manage, even though editing the catalogue itself stays a dashboard action. Anything you can't see is reported as not found, so nothing about its existence leaks. (For custom tools, only enabled ones are listed — matching what an agent can actually call; one still awaiting its secret stays out of the listing.)

Where content is created​

You never pass an owner ID. Prompt, custom-tool, and Agent names use the same caller-relative namespace for reads and writes. A standalone personal credential uses a bare name. In organization scope, bare names denote the shared catalogue, me/name denotes the represented member's private space, and <team>/name denotes a bound team. The organization catalogue is currently read-only over MCP, so organization-scoped writes use me/name or a team address. Resources use explicit URI/team addressing because a resource path can itself contain /:

  • Prompts, custom tools, and Agent definitions use name personally, me/name for a private organization item, <team>/name for a team item, and a bare name for an organization-catalogue read.
  • Resources are addressed by their path, with an optional separate team field — docs/readme.md (yours) vs docs/readme.md with team: "marketing" (the marketing team).

When its persistent local instruction requests it, the agent learns its bound team names and per-content create rights by calling bootstrap at task start — an empty team won't show up in a listing, so this is the only reliable way to discover its name. Update and delete calls check their own permissions.

There is no way to publish to your organization's shared catalogue from here — that stays a deliberate action you take in the dashboard.

Custom-tool secrets stay in the dashboard​

A custom tool that calls an authenticated API needs a secret (a bearer token, an API key, a password). For safety, secrets are never set over MCP — you define the tool and its auth type, and a person adds the secret and enables the tool in the dashboard. Until then the tool is disabled and can't run. A tool that needs no authentication skips the secret step; its initial enabled state follows the owner's default setting. Normal access rules still determine which credentials can call it.

Permissions​

Every write is authorized for the exact target space. A standalone personal target requires the matching personal permission. A Team target requires both a binding to that Team and the matching Team permission. A private me/ target requires an acting user with active organization membership; the bare organization catalogue is not writable over MCP. If the credential cannot change the addressed space, the tool is refused. Team bindings and write permissions are checked separately: a grant for a team does not bind the credential to it. Each request is authenticated and authorized afresh, even in an existing MCP session. Once the concrete action is authorized, later revocation or permission changes do not cancel the request; subsequent requests reflect the change. The operation's consistency checks still apply, as described under revocation. A denied update or delete does not reveal whether the addressed item exists. Requests made with an already revoked credential fail authentication.

Read and write authority are separate. list_agents and get_agent require Agents and show only definitions the credential may use; Agent create/update/delete follow the target-space mutation rules above but do not grant or require Agent use. Every governed management tool still requires Tools and admission by the applicable tool policy.

Like any governed built-in tool, a content-management tool also has to be available to your credential (see Discovering tools); an organization can choose which content-management tools its agents may use. A credential that isn't allowed to use them does not see them in tools/list; a direct call is refused by the capability or tool-policy check. A tool removed from the platform registry is reported as an unknown method. This does not apply to the three authenticated system tools described above.

Metering​

An admitted management call counts once against your plan's tool-invocation allowance and appears in your activity history. A write refused inside the tool, such as a missing target permission, is recorded as a failed call. Requests rejected during authentication or before tool admission do not create an activity entry.

Learn more​

This page is the tool reference. For the bigger picture and hands-on walkthroughs: