Skip to main content

Managing your content

Your prompts, resources, custom tools, and Agent definitions aren't fixed — they're yours to create, refine, and reorganise as your needs change. apistash gives you two ways to do it, and both go through the same domain rules:

  • In the dashboard — a person signs in at app.apistash.io and works with a full editing surface: create and organise content, review versions, publish to your organization's shared catalogue, and add the secrets a custom tool needs.
  • Through your agent, over MCP — a connected agent uses the management tools to discover, read, create, and revise content itself, in the middle of a task, without you switching tools.

The second way is what makes apistash self-managing: the same agent that uses a prompt or Agent definition can also improve it. Credential assignment, policy, and organization-catalog publication remain deliberate dashboard actions; authoring in personal and team spaces does not.

Choosing the content type​

Resources are the default home for durable facts, decisions, and reference knowledge. Prompts hold reusable task procedures and templates; Agent definitions hold recurring role identity and behavior. Custom Tools are callable integrations, not general memory. New knowledge should be verified and useful beyond the current task before an agent proposes persistence.

Guided setup offers a small, tailored starter set after an explicit setup request. The agent checks relevant existing content, shows concrete drafts or material changes with ownership targets, and writes only what you confirm or specifically authorize. Neither setup nor Bootstrap provisions records automatically.

What your agent can do​

Give a connected agent a credential with the right permissions and it can, over MCP:

  • Find and read what its credential can reach — including team-owned items from its bound teams, items it can reach in your organization's shared catalogue, and personal items when it represents a member — with the list_* and get_* tools.
  • Create new prompts, resources, custom tools, and Agent definitions with the create_* tools.
  • Revise and tidy them with the update_*, patch_resource, and delete_* tools.

Prompt, custom-tool, and Agent names are caller-relative. A standalone personal credential uses a bare name for its personal space. In organization scope, a bare name reads from the shared catalogue, me/name targets the represented member's private space, and <team>/name targets a bound team. The catalogue is currently read-only over MCP, so organization-scoped writes use me/name or a team address. Resources use their documented URI and separate team field instead. By calling bootstrap at the start of a task, the agent learns its available own space, bound team names, usage capabilities, and create rights. These are preflight context; later writes still check authorization. Resource storage and MCP readability are separate outcomes, as described in the management guide.

Three things stay deliberate, human actions in the dashboard:

  • Agent assignment. Select a definition for the API key or OAuth Connection separately from creating it.
  • Publishing to your organization's shared catalogue. An agent creates and refines in personal and team spaces; promotion into the organization catalogue is a decision a person makes.
  • Custom-tool secrets. A tool that calls an authenticated API needs a secret — a token, key, or password. Secrets are never set over MCP: the agent defines the tool and its auth type, and a person adds the secret and enables the tool in the dashboard. A tool that needs no authentication skips the secret step; its initial enabled state follows the owner's default setting.

The same rules, whichever way​

A management write obeys the authorization rules of its exact target space. A standalone personal target requires the matching personal permission. A Team target requires a binding to that Team and the matching Team permission. A private me/ target requires an acting user with active organization membership, while the bare organization catalogue remains read-only over MCP. If a credential cannot change the addressed space, the call is refused rather than silently doing nothing. Agent-definition reads independently require Agents and current Agent visibility; mutation authority does not make a definition usable.

What an agent can see is deliberately broader than what it can change. It 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 it can't see is reported as not found, so nothing about that content's existence leaks.

Closing the loop​

Because the agent both uses your content and can edit it, you can close a loop that's otherwise manual. When a prompt or Agent behavior underperforms in a session, you don't file the fix away for later — you ask the agent to revise it then and there. Changed Prompt content and Agent behavior append immutable versions, so retained history can still be inspected or restored in the dashboard.

This is the idea behind apistash's guides — using the AI to improve the very tools the AI relies on.

Next steps​

info

The management tools require a credential that is allowed to use them — see the access model. Connect an API key or OAuth token to reach them.